Integration Service Blocks can be accessed via the “Services” tab on the Step Palette
You can search for integration services via the “search for services” tool
To add an Integration Service Block, just drag it into the workflow and connect it where desired.
Understand Integration Block settings
Once a step has been added, you can customize its settings by clicking on the block.
Standard settings example
Many Integration Service Blocks use the same standard settings, described below:
- Timeout (Checkbox)
- Should the request time out after a certain amount of time?
- Set this to true when long workflow processing time is a concern
- Off is a reasonable default
- If Timeout is checked - Timeout Duration
- You can set how long to give the step to complete before it times out
- Number of Retries
- If a step fails, how many times should it try again?
- Configure this based on factors like whether the integration charges for failed calls, if the service is unreliable, and more.
- Continue on Failure
- Should the workflow continue if the step fails? You can look at whether a workflow failed if you continue on failure, but it takes a bit more configuration.
- This is an important option - we don’t usually default it to “ON” - but it is important to consider whether it should be checked. If there is a lot of important logic downstream of a step that does not necessarily rely on the integration step’s results, it might be better to just go to the next step if it fails.
- Advanced Options “Manage Input Data Sources” See Checkpoints and Integrations
Nonstandard Settings Example
Some Integration Service Blocks have additional non-standard settings available. For example, Twilio has an option that lets you allow voice calls for this step.
It is important to read through the settings and understand their purpose in order to choose the correct option. See the example below from a Sift block: the Abuse Score Types is a very important option that can impact latency and billing.
Understanding Data Inputs
Integrations often require some data to be sent in order for them to run. This can be provided in a number of ways, which are discussed in detail:
If a checkpoint does not have the necessary data, it may fail or give responses that are not useful.
Generally speaking, the more relevant data you can provide, the better an Integration Service Block will perform.
You can view the inputs for an Integration Service Block at “Manage Input Data Sources.”
Alternatively, you can view a combined summary of all inputs across the checkpoint by clicking the “Expected Data” in the Trigger Block Settings
Understanding Data Outputs
Integration Service Blocks generally export certain data into the workflow context once they run. Once the step has been connected to the workflow, this data can be viewed in a number of ways detailed here: Checkpoints and Integrations