SUMMARY

• Recipes are made of steps that either perform actions like create, update, or search in a target app or control flow statements that manage business logic.
• Control flow steps include "IF Condition" for conditional actions, "Repeat" for handling list items, and "Repeat in Batches" for processing high-speed data transfers in smaller batches.
• "Call Recipe Function" step is used to trigger another recipe for reusing logic, while the "Stop" step ends a job prematurely in case of business logic errors.
• "Handle Errors" step is designed to monitor and manage errors in actions, similar to try/catch in programming languages.

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

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.

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.

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).

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

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.

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.

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.

The following displays the mapping from the Foreach datatree. 

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.

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

• 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.

• 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.

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

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.

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.

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.

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.

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.

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

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.

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.

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.