Steps

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.

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 control statement

An IF condition control statement directs a recipe to run an action or set of actions if the specified condition is met. For example, the recipe in the following image uses conditional steps to determine 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

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 control statements (loops)

A Repeat control statement allows you to repeat a set of steps based on different criteria. There are two types of Repeat control statements:

• A Repeat while loop repeats one or more actions while a condition is met. The loop ends automatically when the condition is no longer met. For example, you can retrieve the next page of Google Drive search results while there are pages left to retrieve.
• A Repeat for each loop repeats one or more actions for each item in a list. The loop ends automatically when the entire list has been processed. For example, you can download each Google Drive file in a list of search results.

REPEAT FOR EACH IN BATCHES

The Repeat for each control statement can be used to iterate through list items one at a time (by default) or in batches. To repeat in batches, refer to Repeat for each in batches.

The following diagrams show the difference between the two types of Repeat statements.

Repeat while loop:

flowchart TD Z(["Start"]) --> A["Execute action(s)"] A --> B{"Is condition met?"} B -- "Yes" --> C["Repeat action(s)"] B -- "No" --> D(["Exit loop"]) C --> B

Repeat for each loop:

flowchart TD A(["Start"]) --> B{"Any items in list?"} B -- "Yes" --> C["Take action on list item"] B -- "No" --> D(["Exit loop"]) C --> B

Combine Repeat while and Repeat for each

You can combine Repeat while and Repeat for each control statements in the same recipe. For example, a recipe can contain a Repeat for each loop inside a Repeat while loop. This supports use cases such as the following:

• REPEAT search for contacts using SOQL query in Salesforce WHILE pages of search results remain.
  • FOR EACH record in a page of search results, retrieve contact details.

---

Call Recipe Function control statement

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 control statement

The Stop control statement 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 statement can be configured to mark the job as a failed or a successful, depending on business logic.

Example: Stop control statement

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.

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

Any job run by this recipe can proceed through either one of the conditional steps, as the Zendesk organization must have either been found or not. If the organization is not found, the job stops at Step 4. If the organization is found, the job does not carry out actions within the conditional step (defined in steps 3 and 4), and instead updates 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.

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

---

Handle errors control statement

The Handle errors control statement 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 through email or error messages in the app, or to carry out a rollback (for example, you can reverse the job by deleting any created or half-created records).

This control statement consists of two blocks: the Monitor block and the Error block. Place the actions that you plan to monitor for errors within the Monitor block. If all actions are successful, Workato ignores the Error block. However, if any action in the Monitor block results in an error, the actions within the On error block are executed.

Example: Monitor errors block

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

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 are caught, and the recipe proceeds to carry out steps within the On 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 block, you can configure Workato to auto-retry the actions nested within the Monitor in instances where the actions fail. By default, Workato does not rerun failed actions within the Monitor block. You must manually set up auto-retry to rerun failed actions.

Error block defaults to the do-not-retry selection

You can configure Workato to retry failed actions one, two, or three times. You can also customize the time interval between retries; Workato supports retry intervals ranging from one to ten seconds.

Retry configuration fields

You can also define a condition that must be met before Workato auto-retries the Monitor block. 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: Monitor errors block with retry

If the actions in your Monitor block tend to fail for temporary reasons such as network or timeout issues, it makes sense to use auto-retry. This ensures that the recipe attempts to execute the steps again until it succeeds, for a maximum of three tries.

This example uses the same error monitor example recipe introduced in the preceding example. This recipe attempts to update the Zendesk organization right after the search step, regardless of whether any Zendesk organizations were found. In situations where no matching Zendesk organization is found, the Update organization action fails.

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 checks to see if the error message contains a 401 error code (unauthorized error). If the error is an unauthorized error message, we know that further attempts to retry the action will fail as this means we don't have the right permissions to update the Zendesk organization. This can happen when permissions within Zendesk change. If the error is not an unauthorized error message, we proceed to retry the update organization action again after the specified period of time, for example, every five seconds, up to a maximum of three times.

On error datapills

When you add a handle errors block to your recipe, Workato generates the following error-related datapills if an error occurs. This enables you to configure your recipe to handle recipe errors differently depending on the error type, message, source (recipe step, action, or app), and more.

Learn more about error handling best practices.

Datapill	Description
Error type	The type of error that occurred.
Error message	A message describing the error.
Retry count	The number of times Workato tried to rerun the actions in the handle errors block.
Error UUID	The Universally Unique Identifier (UUID) of the error. This is a 128-bit label used to identify the error.
Errored step number	The step on which the error occurred.
Errored app	The app that caused the error.
Errored action	The action on which the error occurred.