Workflows rule. They can wait until there is $10,000,000 in your bank account or forever (whichever happens first), they can update records, send emails and synchronously move mountains (subject to the 2 minutes timeout, and only if the mountain is referenced by a DNS-resolvable name). They can be quite complicated and often won’t fit on a single screen.
Sometimes they depend on a specific entity record, e.g. queue, user, team, currency, etc. Consider this sample workflow, assigning account to a team if it’s not already assigned:
The main issue with this workflow is that the team is specified in multiple places:
- If action is more complicated than assignment, e.g. custom activity, record update, email, you won’t even see that the team is used – you’ll have to navigate to the second screen.
- If you deploy the workflow to another organization, workflow will be broken and explicit references to the team would have to be replaced before you can activate the workflow.
If only we could define variables, right? Custom actions, yet again, to the rescue.
Let’s create a global custom action, and add input and output parameters of EntityReference type (team entity):
and create only one step that simply copies input into output:
We can now rewrite our workflow to use this action to create a variable holding our team:
Final workflow has all dependencies isolated in the custom action step, we know there are no dependencies elsewhere and, when we deploy this workflow into another organization, there is only one place where we need to set our parameters. This custom action can be extended to cover all variables you need, except notorious Picklist, Entity and EntityCollection data types – using any of these will make your action invisible in the workflow.
If you want to make a movie instead, check out CANAL+ flowcharts.