Recipe Components

# Steps

Recipe steps can be actions, or control flow statements that help you describe business logic.

Available steps Various recipe steps available in recipe editor

# Action step

Actions carry out an operation in your target app, such as a create, update, or search operation. Each action requires a set of input fields and typically returns data i.e. output data tree.

Pro tip: reorder steps in your recipe with drag-and-drop (video)

# Example: Action step

The following step carries out a Search organizations action in a Zendesk integration. The input fields on the left shows the available fields to search for a Zendesk organization by:

Name
Tags
Notes
Details

In the following case, the Search organization action is carried out by name.

Searching Zendesk organizations by Salesforce account name. Example recipe (opens new window)

When the Search organizations action has been carried out, Zendesk returns data about the organizations found, if any. The output datatree displays available fields for mapping in subsequent steps.

In the following case, the Update organization action uses the ID field from the Search organizations action to identify which Zendesk organization to update (ID field as highlighted).

Updating Zendesk organization identified by ID. Example recipe (opens new window)

# IF Condition Step

An IF condition step directs a recipe to run an action or set of actions if the specified condition is met. For example, the recipe in the screenshot below uses conditional steps to decide whether to create or update a Zendesk organization.

For descriptions and examples of the conditions, see conditions.

# Example: Conditional Action Step

The following recipe has two conditional steps:

If Zendesk organization is found, update Zendesk organization
If Zendesk organization is not found, create new Zendesk organization

Conditional step examples Recipe that uses conditional steps to decide whether to create or update Zendesk organization. Example recipe (opens new window)

In this example, any job can only proceed through either one of the conditional steps, as the Zendesk organization must have either been found or not.

# Repeat Step

When working with a list of items (for example, a list of invoice line items), you may need to carry out a set of actions for every item in the list. The repeat step helps you do that. Actions indented within a repeat block will be carried out for all items in the list.

The input to the repeat step is a list. Actions within a repeat block should use data output from the Repeat step's datatree. This ensures that every item in the list is processed.

# Example: Repeat Step

Refer to the example scenario of syncing Salesforce accounts (using the batch trigger) to Zendesk as organizations.

Foreach step example scenario Recipe that uses the Repeat step to iterate through list of Salesforce accounts. Example recipe (opens new window)

In this example, the trigger returns a list of Salesforce accounts. Since Zendesk does not support batch actions, each Salesforce account must be added one at a time from Salesforce to Zendesk.

The list datapill has to be passed into the repeat step. When the input list field is selected, only list type datapills are usable in the datatree, as shown below. List type pills can be identified via their stack icon.

Map list data pill into the Repeat step Mapping a list data pill into the Repeat step's input list field. Example recipe (opens new window)

Datapills from the Foreach output datatree should be mapped to ensure that values from each list item are used when the action is repeated. For example, if two Salesforce accounts are fetched by the trigger, using pills from the Foreach datatree ensures that the Create organization action creates a Zendesk organization with the data from the first Salesforce account on its first iteration, then with the data from the second Salesforce account on its second iteration.

Use datapills from Repeat step Using datapills from the Repeat step's datatree. This ensures values from the list being iterated through are used. Example recipe (opens new window)

The following displays the mapping from the Foreach datatree.

Foreach step example Datapills are mapped from the Repeat step's datatree. Example recipe (opens new window)

For further Repeat step examples or more info about list processing, refer to the list management article (opens new window).

# Repeat in Batches

Occasionally, the rate at which an upstream app or system transmits the data is faster than the rate at which a downstream app or system can receive it. You can use the Repeat in Batches feature to process such a data movement by configuring the batch size. Large data sets are automatically parsed into smaller batches for transfer.

# How to use

Follow these steps to use the Repeat in Batch feature:

Select the Repeat Action step from our “What happens next” container in the Recipe Editor.

Select the repeat action step as action

Enter the Input List data pill in the Repeat Action step.

Input List

Invoke the Repeat in Batches feature by setting Repeat Mode to “Batch of items”. (The two options available are “One item at a time” and “Batch of items”.) Refer to figure below for more details.

Repeat in Batches invoke

Set the Batch size field. This defaults to 100 when the batch size is not specified or if the number specified is less than 1. Please note that a data pill can also be input here as a batch size.

Set Batch Size

You will see this reflected in the For each statement with the batch event tag.

Foreach loop batch size

Please see an example recipe (opens new window).

# Call Recipe Function Step

Using a Recipe Functions - Call Recipe Function action allows you to trigger another recipe. Called recipe functions, these types of recipes allow you to quickly and easily re-use recipe logic.

Refer to the Recipe Functions documentation for more info.

# Stop Step

The stop step ends a single job from being processed any further. It is usually used in cases when there is a an error in the business logic and further processing of the job is not required.

The stop step can be configured to mark the job as a failed or a successful, depending on business logic.

# Example: Stop Step

The following recipe expects all Salesforce accounts to be present in Zendesk as organizations. In cases where no corresponding Zendesk organization is found, the recipe will stop processing further actions.

Stop step example Recipe that utilizes the Stop step to send email and end job. Example recipe (opens new window)

Any job ran by this recipe can proceed through either one of the conditional step, as the Zendesk organization must have either been found or not. If not found, the job will stop at Step 4. If found, the job will not carry out actions within the conditional step (Steps 3 and 4), instead only updating the matching Zendesk organization.

This recipe marks the job as an error, so that the recipe owner will take notice of this job and attempt to rerun it.

Stop step with error Configuring the Step step's error message. Example recipe (opens new window)

# Handle Errors Step

This step allows you to monitor for errors in actions, similar to the try/catch concept in programming languages. When an error occurs, you have the chance to:

retry the sequence of actions again, in case it was a temporary error such as network issues, or
take remedial actions, such as notifying users of the error via email or error messages in the app, or to carry out a rollback (i.e. reversing the job by deleting any created or half-created records).

This step consists of 2 blocks: the Monitor block and the Error block. Actions to be monitored for errors should be within the Monitor block. If all actions are successful, the Error block will be ignored. However, if any action in the Monitor block results in an error, the actions within the Error block will be executed.

# Example: Error Monitor Step

The following recipe tries to update the Zendesk organization right after the search step, regardless of whether any Zendesk organizations were found. In cases where no matching Zendesk organization is found, the Update organization action will fail.

Error monitor step example Recipe that uses the error monitor to monitor failures in updating Zendesk organizations. Example recipe (opens new window)

As the recipe catches failed actions within the error monitor block, failed Update organization actions will be caught, and the recipe proceeds to carry out steps within the Error block immediately, as no auto-retry was configured. In this case, it seems that the only reason for the update failing is because no matching Zendesk organization was found. Hence the remedial step creates a new Zendesk organization.

# Auto-retry

When using the error monitor step, you can setup the actions within the Monitor block to be auto-retried by Workato in cases of action failures. By default, the Monitor block actions will not be reran.

Do not retry default configuration Error block defaults to the do-not-retry selection

You have the option of retrying up to 3 times, and of selecting the time interval to wait between each retry.

Retry configuration fields

You can also define a condition that has to be met before the Monitor block can be auto-retried. For more information on the available conditions you can use, refer to the IF condition article.

Configuring the retry condition field. In this example, the actions in the Monitor block will only be carried out again if the error message does not contain the 401 error code.

# Example: Error Monitor With Retry Step

If the actions in your Monitor block tends to fail for temporary reasons such as network issues or timeout issues, it would make sense to use auto-retry, such that the recipe will attempt to execute the steps again until it succeeds, for a maximum of 3 tries.

We will reuse the same error monitor example recipe from above, where we try to update the Zendesk organization right after the search step, regardless of whether any Zendesk organizations were found. In cases where no matching Zendesk organization is found, the Update organization action will fail.

Auto-retry example Recipe that uses the auto-retry to recover from action failures in updating Zendesk organizations. Example recipe (opens new window)

If updating the Zendesk organization fails, the recipe will check to see if the error message contains a 401 error code (i.e. unauthorized error). If the error is an unauthorized error message, we know that further attempts will still fail as this means we don't have the right permissions to update the Zendesk organization, perhaps because of changed permissions. If the error is not an unauthorized error message, we will proceed to retry the update organization action again after the specified period of time, for example, 5 seconds, up to a maximum of 3 tries.