Before starting to work with the Workato extensions, it is important to understand basic concepts that are used for the provided extension. The following introduces essential terminology and also describes operations and workflows that are associated with the Workato extensions .
Recipes represent a set of steps that the extension follows to get required work done between your apps. Recipes have many advanced features, allowing them to handle all app integration and workflow automation scenarios, including complex data transformations, conditional triggers and actions, duplicate detection and more.
When recipes are started, they will run automatically in the background to look for trigger events and carry out recipe actions. When they are stopped, they will cease to look for trigger events. Note, however, that when a recipe is started again, it will pick up all the trigger events that occurred since the recipe was stopped. In other words, stop functions like pause.
You can set recipe visibility to be public or private. When they are set to be public, any user can see this recipe, and make a copy for their own use. All recipes also have a unique ID that identifies them and can be found in the recipe’s URL.
Learn more about recipes by following this course.
Triggers determine what event to listen to execute the actions described in a recipe.
Trigger events can be set off in apps (i.e., Connect and Zuora) when a certain event happens (new subscription is created or existing subscription information is updated), when a new line is added in a file, or according to a schedule (launches at a certain time or interval).
Depending on the available API, the extension can receive trigger events in real-time, or check for the occurrence of an event periodically by polling the app.
Read more about triggers and how to use them by following this link.
Recipe steps are executed every time the trigger event occurs. Recipes are required to have at least one step. The most basic step for a recipe is an action such as an action to create a new fulfillment request on Connect.
Steps can represent actions, conditional actions, list actions, actions that call other recipes, try/catch, etc.
You can learn more about recipe steps here and actions here.
Every step, including triggers, brings data into the recipe. For example, once a new usage report is accepted on the CloudBlue Connect platform, the extension brings in usage data. Such data is made available in the recipe via the datatree.
Datapills are output data from a trigger or an action step. They are variables that you can use to map business logic into recipe steps. You can use the datapills in subsequent steps.
The following example showcases the output datatree for the New Usage File trigger. This datatree contains specific variables that are available for use whenever a trigger event occurs.
For example, as seen in the screenshot, whenever a new usage report file is accepted on the Connect platform, the Workato extension is able to get corresponding value data for this particular usage report file:
| ID Name Status Vendor ID Vendor Name Contract ID Product Schema Events Environment etc. |
These values can be used in subsequent steps of the recipe by being passed into input fields, as covered next. Read more about datatrees and datapills by following this link.
Triggers and actions have input fields. Input fields are how triggers and actions are designed to carry out customized workflows, and they can take in variables (datapills) or constants.
When the user inserts variables (datapills) or constants into input fields, that is called fields mapping. You can read more about fields mapping here.
The following example displays two variables: Subscription number and Connect external UID. The first variable is mapped to the required input field that is called External ID. This value is required to manage subscription objects and generate fulfillment requests (e.g., generate cancel or update requests).
The Connect External UID variable is assigned to the corresponding input field. This is an optional variable that is assigned to a subscription by the external system. This value is used to identify a subscription that should be updated, suspended, canceled, etc.
For a recipe to communicate with apps via actions and triggers, it has to be authorized to interact with apps. This authorization is referred to as a connection.
Note that connections are not tied to a recipe. A single connection can be used by multiple recipes. You can read more about application connections by following this link.
Each time there is a trigger event, the actions in the recipe are executed. The entire flow of each trigger event through the recipe is called a job. Jobs can be successful (when actions are executed successfully), or have errors (when an action results in an error). When an error is encountered, subsequent actions are not executed. You can read more about jobs here.
The job report gives a high-level summary of the all the trigger events processed by the recipe. The entire flow of each trigger event through the recipe is called a job.
Information such as date, time processed and job IDs, can be found here. From this jobs history page, users can view more detailed information about a job by clicking on it.
Learn more about job reports by following this link.
The job details page provides step-by-step input/output details of a single trigger event as it is processed by the recipe. This page is useful for troubleshooting recipes as users are able to view the data passed into each step and the resultant output returned after each step was executed.
You can read more about job details here.
Additional content 
Contact us 
