Best Practices for Workflows

This topic provides best practices to apply when working with workflows.

For more information on working with workflows, see Workflows.

  • Avoid including more than 20 steps per workflow.

  • Instead of one large and complex workflow, create one main workflow that invokes sub-workflows. Those sub-workflows can often be reused. The main workflow can be made to wait until the sub-workflow ends.

  • If multiple transitions exit a workflow step, only one will be followed, so ensure that mutually exclusive conditions are applied to all transitions exiting a step. See Add a Condition to a Transition.

  • Ensure that a workflow (and all sub-workflows) end as expected when an interaction ends.

    Ideally, use the workflow's End methods to terminate all workflows as part of a reset mechanism.

    For unattended solutions, define timeouts for the main workflow and all sub-workflows. Defining timeouts for sub-workflows provides for more granular error handling and control.

    Prepare common timeout handling. When a timeout occurs, make sure to close the main workflow and sub-workflows after performing any necessary error handling.

    If a workflow does not terminate, it will not start the next time it is invoked. When you try to start a workflow that is already running, nothing happens, other than a record in the log notifying of an error.

  • For robotic automation workflows, it is recommended to set a timeout (that includes invoking the End workflow method), ensuring that the workflow terminates no matter what kind of unexpected error happens during execution. This ensures that in the event of either a logical or technical failure occurs, the workflow ends.

  • At the end of a robotic automation workflow, as well as during any workflow error handling, reset all the objects necessary to re-run the workflow, including the sub-workflows, business entities, and so on.

  • Do not apply a timeout to an attended automation that depends on user input.

  • Use of workflow loops to cycle through lists to search for an element or to perform an action on each element is not recommended for performance reasons. Preferably use a For-Each block within a single step.

  • When using workflow loops to cycle through a list to find a particular element, add a condition to exit the loop once the element has been found.

  • Ideally, retrying an action on a screen element until it succeeds should be avoided. For example, improving workflow transitions to ensure that a screen element exists before it is clicked can be effective. See Best Practices for Using Screen Elements in Workflows.

    However, in some cases retrying an action is the only way to ensure that the action is ultimately performed. If such a loop is used, always limit the number of attempts that will be performed by using a counter.

    An example workflow is shown below. In this application, the site does not always react to clicking the Search button. The workflow will try clicking search only four times, after which a failure message is displayed.

    The actions for each relevant step are shown below:

    The variable Attempt_Counter is incremented each time the Search button is clicked.

    This decision checks if an element on the search results page exists. If it does not, then continues to the second decision to decide whether to perform another attempt.

    This decision checks if the Search button has been clicked more than three times. If it has been, then directs the workflow to display a failure message. Otherwise allows another attempt.

  • Ensure that workflows are readable so that they can be understood and maintained by others.

  • Organize the steps and transitions in a clear and methodical way.

  • Align steps and actions neatly.

  • The recommended naming convention naming workflow steps is upper CamelCase, for example, GetCustomer and SendEmail.

  • Each step should have a single, clear purpose. The actions added to a step should achieve just one clear goal.

  • Note that if an action fails, all further actions on the same step are skipped and the transition exiting the step is run immediately.

  • Where action B is dependent on action A being completed, action B should be placed in a separate step.

  • When multiple actions are required to perform a single task in an external application, it is often advisable to group those actions in a single workflow step. Doing so makes it easier to use a single condition on the exiting transition to ensure that the desired outcome was achieved. It also makes retrying the sequence of actions easier to specify. This guideline applies in cases in which it is not necessary to wait for the application to respond between actions, for example, when populating multiple fields on a single form and clicking Submit.

  • Functions that invoke operations in external applications such as web sites, for example, Execute Script, may cause the workflow to hang as the external application may take time to respond. The workflow will not run the next action until a response is received.

    It is thus preferable to use the asynchronous version of such functions where available, for example, Execute Script Async. Workflows do not wait for async functions to be completed before continuing to the next action.

  • Avoid using delays in automation solutions to ensure that a step does not start too soon after a previous step. Setting the delay correctly is difficult, for example, a 3rd party application may run slowly and the delay will not be long enough. On the other hand, setting a longer delay than necessary introduces unnecessary performance degradation.

    Use delays only when necessary and only after consulting with an experienced Automation Studio developer.

  • Do not use the Sleep function to create a delay.

    The sleep function sleeps the entire CPU and therefore the entire Real-Time Client. Halting the Real-Time client is not advised, especially as it may not resume activity as expected.

  • To implement a delay where unavoidable, create a timer and make use of its Elapsed Time event.

  • The recommended naming convention for input and output parameters of an invoked workflow is lower camelCase, for example, customerName and zipCode.

For best practices for building workflows that interact with screen elements, see Best Practices for Use of Screen Elements in Workflows.