Application Steps

A Plugin application can add its own events and actions to automations. The developer defines the name, fields, configuration mode, and continuation options, so the available steps depend on the project's installed plugins and the current automation type.

Add a step

Open the step catalog. When the project has an active application with suitable published actions, an Applications group appears. Select the required action by its name, description, and icon.

A step is hidden when the application is not installed or is paused, the action is unpublished, or the developer did not enable it for For dialogs or Background automations. An action with an embedded form also requires the embedded page's main URL to be set; the main page itself does not have to be shown in the project menu.

Verify which application owns the step

At the top of the settings is an application and action card. Select it to open application information: its description, website, installation count, and developer documentation when published.

You can also open management for the installed application from this dialog. This is useful when you need to review its access, finish setup, or understand why an action is unavailable.

Configure an application event

An event starts a run, while an app action executes inside a run that has already started. See App event for event settings, its data variable, and repeated runs.

Configure the step

What appears below the card depends on the action's configuration mode. Senler renders the fields in builder mode. In embedded mode, the application renders the whole form; declared inputs and results are passed to that form as a contract and are not duplicated beside it.

Settings builder

Complete the Input data fields. They can accept text, a number, Yes / no, a date, an array, an object, or any JSON value. Required fields are marked with an asterisk, and a hint explains each value.

Text can contain variables from the current run, project, lead, or dialog, and a For dialogs automation can also use system lead data. For example, {{lead_data.email}} passes an email address and {{run.deal_id}} passes a value obtained by a previous step. When a required text input and a run variable have the same name, a new step prefills {{run.technical_name}}; you can replace it.

In Step result, map response fields to Run, Lead, Dialog, or Project variables. Lead and Dialog are unavailable in a Background automation. For example, save Deal ID to deal_id. The pencil next to a variable lets you enter a nested path. A mapping is optional: without it, the action still runs, but that response field is not stored in a variable.

Embedded page in the panel

The application UI appears directly in the step side panel. Complete it before selecting the common Save button. During save, the cabinet requests the current configuration and, when the action supports it, the branch list from the page. When the application reports its form size through Senler Bridge, the panel automatically adjusts to its content.

Embedded page in a dialog

In the application settings block, select Open step settings. Complete the form in the dialog and select Save. This mode is usually used for larger forms.

The embedded form belongs to the application, so its fields and validation may differ. If the developer declared inputs and results, the application form itself presents the required fields, saves their values, and lets you bind results to run variables. If the embedded form does not load or save, first check the installed application's state and documentation.

Update a previously added step

The developer can change the fields, configuration mode, or fixed outputs of an already published action. When you open a saved step, the Cabinet compares its settings with the action's current definition.

If the action no longer supports a particular parameter or result, a “The step contract has changed” warning appears above the settings. The same warning appears for a removed fixed output. Obsolete items are crossed out. Select Remove for each one: removing a parameter also removes its saved value, while removing a result removes its run-variable binding. After removing an old output, check how the graph should continue.

If the developer switches the action from the settings builder to an embedded page, previous parameters, values, and result bindings are not deleted. The separate Senler fields disappear, and the application form receives the saved data. Open it and verify that the values and variables are shown correctly.

Then complete any new fields, use the updated embedded form if necessary, select Save, and publish the automation again. Updating the application does not remove a saved node automatically.

Connect outputs

An action may have one Next output, developer-defined fixed branches, or branches created by the embedded form during configuration. Connect every output you use to a following step. If a required continuation remains disconnected, graph validation reports a warning or error according to the action contract.

Save and test

Select Save, publish the graph, and perform a test run. An application step can carry out a real external action even during a test run, so use safe test data.

If publication reports that the application or action is unavailable, check the installation, application state, and support for the current automation type. An action disabled by its developer disappears from the catalog for new graphs but is not automatically removed from a saved node.

The developer can make compatible updates to a published action. When you reopen its settings, the cabinet shows the current fields and retains compatible entered values. Review the changes and warnings about obsolete items before a production run.