The workflow modeller is a powerful tool that can be used to design and automate any business process. But keeping your designs simple and robust is key to maintainability.
General Principles
Where you can, keep your designs as simple as possible. The strength of the process modeller is in handing transactions and coordinating user tasks. Other areas of the platform, like end points, the search engine, iCM objects, and your user tasks forms should perform any processing and integration elements, rather than script actions in your model.
Smaller, short-lived processes are easier to manage and support than long-lived ones. When a process has reached its end, use the terminate end event rather than just the path end event.
When you use the Data Retention Manager to set up retention policies for your history data, make sure you are also deleting any related process instances too.
The workflow engine should always be considered a transient data store. The data stored in process variables should be there to support the work of the process. Once the process has ended, any data you need to keep should have already been written to one of the other services provided by the platform. The Data Management section of the site has lots more information on where and how to store data.
Names and Descriptions
Always give your model and the activities in it meaningful names and descriptions.
- When fault finding, the activity name will appear in logs and tracing, rather than an ID
- Process names are used in the form designer's workflow start action field
- Names and descriptions are also logged to history
- User task names and descriptions, as well as the process description, will visible to users on your website (see Workflow and History Data In Assisted Service, Self Service and User Requests)
Remember that your process and activity descriptions can include tokens to display relevant information to users. There's a full description in Process Variable Tokens and Expressions.
Timers
Timers are a great way to add reminders to user tasks:

You can also use timers to set a short delay (no more than a minute) when retrying a task:

Error Handling
Any calls to external services should include error handing. There's no guarantee the service you are calling will be available.
When activities return an error, the error is stored in a process variable. The default name of the variable is APICALLERROR:

But because this name is the default for all activities, each activity should be renamed to something more meaningful:

Workflow Error Handling describes different ways you can catch and handle errors.
Process Variables
Process variables store values submitted by forms that interact with your process, store values returned from workflow activities (like end point calls), can be created in your process model using the script task, and hold standard values present in every process instance. The Process Variables section of the workflow knowledge base covers all of this in detail.
The values of process variables (especially those from form submission) may contain sensitive/personal information. Think about what data needs to be passed to your workflow, and what should be stored elsewhere. The Workflow - Start Action and Workflow - Complete Task Action form fields have a Process Variables Function you can use to remove form fields from the submission so they don't get created as variables, while still storing them in history.
In workflow script tasks, it's more efficient to access process variables directly, for example:
if (form_VARIABLE=="value") {
...do something
}
rather than using
Hidden Fields on Forms
Avoid using hidden fields on forms to pass values to your workflow process. Use the Process Variable Function in the workflow action fields instead.
Inter-branch Orchestration
When building workflows where you need one branch to talk to another use Signals with the process instance scope. See Messages and Signals for an example. Never use messages and the execution object to send messages to yourself.
Event Gateways
If you have multiple events that you need to add to your workflow consider using an Event Gateway, especially if you don't want concurrent updates to be processed.
Querying Workflow Data
The API Server's Workflow Worker has functions that can interact with processes, tasks and workflow data. The most efficient approach is to use the platform's search, as described in Process Instance Search Indexing. A key thing to remember is that form fields have to be marked as "searchable" if you want the process variables they create to be searchable too.
Interacting with Workflow Processes
The main way your users will interact with your workflow processes is by using forms, and the Self Service and User Request templates. How process instances appear on these templates is described in Workflow and History Data In Assisted Service, Self Service and User Requests.