of the
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.
Is there not a way to get an EntityReference (Lookup record reference) from a string value?
// pseudocode
if (Account.Name == “ABC Company, Inc.”){
Get the EntityReference/Lookup;
Pass EntityReference/Lookup back;
}
I’m not able to find anywhere on the web where this is possible from within an Action or Workflow.
IE: I have a simple Workflow that reacts on imports of Contacts into a staging entity. Special processing creates the Contact if it doesn’t already exist, and then acts on other data in the CSV.
There are “Company” and “Owner” columns in the CSV file. Why in Heaven, hell, or in between doesn’t Microsoft allow a simple way for me to add the Company name (string) to the Account Lookup field and have it resolve? Since Account is a Lookup, it’ll only allow Lookup values.
I have to do this because during data import, if a Lookup doesn’t resolve, the entire import fails. So I need to resolve string values to their matching Lookup/EntityReference values from within the Workflow or an Action.
Help?
Jason,
your pseudo code can be implemented as a custom workflow activity, I don’t see any problems with that.
Note that data import works just fine if your company name matches a single record. If it does not, e.g. no match or multiple matches, you’d have to deal with the same situation in your code.
HTH
George
Not able to launch an action in a workflow in CRM 2013. Is that to be expected ? I created the action to return an EntityReference, but there is no way I can call that action from the workflow.
Yes, this is expected. Ability to call actions from a workflow first appeared in 2015, I believe.
Hi George,
Is that only for for 2015 online, I cant see it in my 2015 on prem.?
Could be that update 1 is required.
At this risk of making a pedantic comment on an old (but still relevant) tip; it would more appropriate to refer to this approach as “constants” rather than “variables” since it is not possible to vary the value once it has been set via the Action. As you demonstrated, constants are useful for reducing maintenance burden, but not as useful as variables might have been.
Genuine variables would be very useful if your workflow needed to write to different fields under different conditions. Evaluating a condition and accessing a single variable would allow the workflow to re-converge to a single Create Record step, pulling values from all variables. Without variables we’re stuck with ever branching conditions (for each permutation) and semi-duplicated Create/Update Record steps. Now if there’s a solution for THAT, I’d be quite excited!
Hi Greg,
you’re quite right, from the workflow level they’re rather constant. You can use actions to change them though but that could quickly become curmbersome and messy.
Yes, time to get excited because Flow does offer the solution. It’s not a full parity yet but it’s getting there.
Cheers
George
You make a good point George. Flow is certainly the way forward and no mistake, however fragmentation of business logic is an ever increasing problem as the “CRM” toolkit expands so parity is an important consideration. Personally I find it hard to commit to Flow yet (beyond a last-resort) due to a poor development experience, worse packaging/deployment experience (how many times do I have to update variables and connections after each release??!!) and unreliability at run-time.
I’m sure Microsoft aren’t far off with the ALM side of Flow, but until then I’ll stay in the dark ages!