Connector Action
Use the Connector Action step to send data through the connector to a third-party system.
In a flow, the Connector Action step creates an action, a job processes the action, and the data goes to the connector. The connector then processes this data according to the action path identified in the flow step details.
Step Inputs
In the Edit Step menu, you can add details about the step configuration as needed for your flow.
Step Detail
Connector
Select the connector (the third-party system) you want to post the data to. The list of connectors populates with all of the third-party systems involved in the integration.
Examples of connectors: ProjectSight v2, Viewpoint by Vista
Action Path
Choose what data you want to post, specific to the connector that you selected. This data is defined in an action path. Action paths are set up when the connector is built, and they are determined based on the capabilities of the connector.
Examples of action paths: Add a new cost code, Update an existing vendor
You can view the JSON schema definition and Swagger documentation for the action path by selecting the links below this field. For some actions, you can disable real-time processing, although in most cases you want to keep this enabled.
Enable Retry Policy
This option is off by default. Toggle this option on to set a schedule for retrying failed actions. In the Retry Policy section, you define the error and program the flow step to run again for a certain number of attempts, at a specific interval of time.
For example, if an action has a timeout and fails, you can enable the retry policy. In general, the retry policy is beneficial to enable if you expect potential errors to resolve themselves. If you expect the data may be bad or a more complex underlying issue causes the error, enabling the retry policy probably won’t help.
Retry Policy
This section displays only if you toggle on the Enable Retry Policy option. Retry policies run additional attempts in a 24-hour window. If this window passes and the action still fails, the flow will move on to the next step.
To set up the retry policy, enter values in the following fields:
Error Condition
These parameters must return as true for the retry policy to run. In this field, enter the values that cause the error you want to resolve with a retry.
Exponential Backoff
This option is off by default. Toggle this option on to double the interval between each attempt. For example, for an interval of one hour, exponential backoff will retry the action after one hour, two hours, four hours, eight hours, etc.
Interval
Define how frequently you want to retry the action. Choose an interval between 30 minutes and 24 hours.
Attempts
Enter the number of times you want to retry the action at the interval you defined. The maximum number of attempts for any time interval is five.
Configuration
Depending on the data you’re posting, you have the option to further refine and customize flow step properties.
Wait For Response
This option is on by default. In general, you want to keep Wait For Response enabled, as it pauses the flow and waits for the action to complete before continuing on to the next step.
Use Existing Body
This option is off by default. When toggled on, this lets you define properties in a previous flow step, and then point to that other step (typically a map step). In other words, you use the existing body of a previous step.
The Configuration section is also where you define action properties. The properties listed depend on the connector and action path you choose in the Step Detail section—the property values are mapped to the system you’re posting data to. For details about property values, see Common Code Examples.
Tip: Avoid adding hardcoded values when defining a property. If you need to translate data between connectors, use a Map JSON List or Object step before the Connector Action Step.
To include additional properties beyond the ones that are required, select the Include checkbox and enter a value to add the property to the configuration.
Step Status
You may see one of the following statuses after running the Connector Action step:
ACTION_HANDLED_SUCCESSFUL
Occurs when the action is handled successfully (only occurs when Wait For Response is on).
ACTION_HANDLED_FAILED
Occurs when:
Data is entered in the wrong type, which does not match the required schema for the action.
A string is improperly formatted.
A bad request is returned from the API.
The action is closed as Failed (only occurs when Wait For Response is on).
QUEUE_ACTION_SUCCESSFUL
Occurs when the action is queued successfully (only occurs when Wait For Response is off).
Step Outputs
The output of the Connector Action is the response from the third-party system: the data either posted successfully or it failed.
Use Case & Example
Use the Connector Action flow step to send data from one system in your integration to another. For example, if you were integrating ProjectSight and Vista and wanted to send data from one system to the other.
In the example below, job phase data from the current system (ProjectSight, in this instance) will either update in Vista if a job phase already exists, or it will be inserted in Vista if a job phase does not already exist.
