These should be considered when using a workflow.
Patterns
- Always, always add a timer after the Begin activity.
- Avoid Switches because they don't update when their conditioned field changes.
- Avoid Email Activities, instead, opt for Event activities.
Here I have a diagram showing a timer added after the Begin activity. This timer returns makes the event queue process the work instead of the user's session. This is great for user experience. But, it makes your workflow dependent on the events queue. If that goes down, this is the least of your worries.
Next, I have a Diagram showing the Switch, if some changed the variable/field values of "Standard" to "Mechanical" the workflow activity won't know to use the new value until you check it out, then recreate the switch, and check it back in. Because of this, I use If activities. This will result in more activities but, because the If activities are scripted, they won't break when you change the variable. If activities used to allow you to create any number of "result" boxes below, one of them being an "else" but now If's are either yes or no for results. Below is an example Switch Workflow and it in the If pattern.
Because you should avoid checking out workflows, always use events in workflows if you need a workflow to generate a notification. Some extra steps are needed to do this but it's well worth it because now you can use the notification records how they are for the rest of the system, you can generate the notification without the workflow by running the following in a business rule or any server-side script;
gs.eventQueue('custom.notification', current, 'parm1', 'parm2');
Now if you were using variables and are not sure how to pass more than two parameters, don't fear. Make your first parm a JSON.stringify object. Sure you'll need to JSON.parse the object in the notification, but now you can pass everything in a way not dependent on the workflow.