This post summarizes a Product Hour session run by the Workato team. For more detail on any of the best practices described below, you can watch the full webinar here.
Recipes are automations for running a business process. They can be as simple as surfacing revenue opportunities by linking Salesforce to Slack, or as complicated as automating a multi-app employee onboarding process. To get maximum value from the automations you create with Workato, there’s a few important best practices to keep in mind.
Regardless of your level of technical knowledge, the most important best practice for recipe design is to understand the process you are trying to automate with a recipe. Before you begin, think about the following:
- What problem will the recipe solve?
- What business apps do you need?
- Is this process time-sensitive?
- What are the business rules/logic?
- What exceptions may occur?
Once understand your business process, here’s a few things to think about as you build your recipe in Workato.
Choosing the right trigger type
Triggers are the events that start the recipe, for example, a new or updated lead, record, or row in a database. Triggers come in a few forms, and the type of trigger you choose is informed by what you want to achieve with that recipe.
Real-Time triggers
Real-time triggers are used when a time-sensitive response to events is required, such as lead enrichment and routing. If you don’t follow up on a lead within 5 minutes, your chances of conversion drop dramatically. For example, in the recipe above, we are automating the process of enriching the details of a lead using ZoomInfo, then updating the lead in Salesforce and notifying the Sales team using Slack. In this space, it makes no sense to wait and process leads hourly, or daily.
If speed is essential, choose a real-time trigger.
Polled Triggers
Polled triggers are used to respond to less time-sensitive events, and check for new events at regular intervals. Take the example of deal management: closed opportunities require paperwork — invoices generated, accounts provisioned, etc. These tasks are less time-sensitive than working with unconverted leads, but still follow from a discrete event.
A neat feature of polled triggers is that you can manually select the trigger poll interval, giving you a lever to set an appropriate balance between speed and cost for each use case.
Batch Triggers
Batch triggers are polled triggers that process large volume requests, and return multiple records at the same time. They work best for processing large volumes of information that require little to no manipulation. In the above example, we’re syncing batches of new accounts created in Salesforce, to rows in a Snowflake database every 10 minutes. Choose a batch trigger when you need to work with high-volume data.
Custom Scheduled Triggers
This type of trigger is not event-based, but instead fires at a specified time. Workato allows you to run recipes on a customized schedule using Cron expressions, alongside a plain-English preview. Without an information-rich event trigger, the first step in a scheduled recipe is usually to run a query in a system of record.
Controlling Trigger Data
So far, we have been using new or updated accounts in Salesforce as an example trigger, but on its own, this is a pretty wide net to cast, and may capture a lot of updates that don’t fit our specific needs. To make sure only relevant events trigger your recipe, Workato gives you two methods for filtering your trigger events,
Filtering at the source
Poll and batch triggers work by querying an app, like Salesforce, for records. We can often use additional fields to narrow down the query, with our options varying depending on the trigger app. In our Salesforce example, we can modify the type of top-level object we want returned, choose which fields should be retrieved, or even use Salesforce Object Query Language. Some other apps, including ServiceNow, and Jira, also offer app-specific query languages. Wherever possible, use these options to make your trigger match your specific business needs.
Filtering by condition
After getting our responses from Salesforce, we can still filter further. Workato offers a granular filter that lets you create a conditional logic based on any data returned by the trigger. Unlike filtering at the source – which depends on the specific capabilities of the trigger app – filter conditions in Workato work for any app. For example, if I want to create an automation to trigger engagement from an executive sponsor, I can filter my trigger to capture only accounts with a rating of “warm” or “hot”.
Design for idempotence
In our context, idempotence is the ability to rerun a recipe on the same trigger event, without creating duplicate records. Unwanted duplicates can lead to a loss of data integrity and poor data quality. Let’s take a look at how to design our recipes to reprocess events without duplicates:
This example recipe shows a new/updated account in Salesforce triggering the creation of a customer record in NetSuite, so we can immediately create invoices and kick off any necessary business processes. As you can see, there is a difference between the trigger condition and the resulting action; the trigger is ‘new or updated’ while the action we perform is to ‘create a new customer’. If we run the recipe as is, any updates made to Salesforce accounts will create entirely new customer profile in NetSuite. How can we avoid this?
Where possible, you can choose an ‘Upsert’ action instead of ‘Create’. Upsert is a database action that updates a record if it already exists and creates a new record if it does not already exist. The limitation here is that you need to know a unique ID for each record, specific to the destination platform, in order to use upsert. Often the necessary ID will not be included in the trigger payload.
Alternatively, we can create our own version of upsert using a ‘Search’ action.
This example uses a unique Salesforce Account ID as the “external ID” in a NetSuite search, returning a list of all matches. If the search returns nothing, we create a new customer profile in NetSuite, knowing it is not a duplicate. If we do get a result, we simply update the existing customer in NetSuite. This recipe can run on the same Salesforce Account multiple times without ever creating duplicate records in Netsuite.
Avoid Infinite Loops
Design errors in event-driven recipes can cause infinite loops. This can happen when two recipes trigger each other, or a recipe triggers itself repeatedly. Infinite loops cause unwanted job runs, redundant API calls, and can cause single tasks to take over your entire bandwidth. However, they are easy to avoid by using trigger filters.
Avoid using your personal access credentials when making integrations. Instead, create a dedicated account, like “integration_user” that you can use to filter events and cross-reference identifiers across apps. This helps you to avoid loops by setting a trigger filter to disregard updates created by Workato, as opposed to a human operator, and prevent a recipe from triggering itself.
Modularity and Reuse
In order to maintain a uniform customer experience while maximizing efficiency, try to reuse automations instead of redoing the same work again and again, with small modifications. Developers handle this by writing functions that they can call as needed. This same functionality is available in Workato without any coding, in the form of callable recipes. This way, if you want to make a change to a larger process, all you have to do is update the original callable recipe to make the change effective everywhere you use it.
However, callable recipes only work within the same Workato workspace. To reuse recipes across multiple workspaces or even make your recipes available externally, you can build APIs from scratch. Workato features an API management platform and gateway, giving a lot of useful oversight for users. API’s in Workato are accessible by anyone with access to the API endpoint, and can be configured to include credential-based authentication policies.
However you approach it, reusing recipes can boost productivity, make your automations more readable, and lower maintenance costs.
Handling Errors and Exceptions
When automating traditionally manual processes like reconciling invoices, you can introduce risk by removing human judgement. Humans are able to identify exceptions or deviations, and decide how to handle them. You need to allow for this when creating an automation. Developers use “try/catch” patterns to monitor code for errors, and describe what to do if something goes wrong. Workato’s low-code/no-code version of this feature is the monitoring block. It searches for errors in a set of actions and specifies what to do if errors occur.
You can also create a callable recipe to modularize your error handling process across recipes. This is useful when you are handling errors across multiple recipes in the same way. With a callable recipe you can manage your whole error-handling process in one place.
For more detail on any of the best practices covered in this post, you can watch the full Product Hour webinar here.