of the
(The chart fortnight by Ulrik “CRM Chart Guy” Carlsson is interrupted again. Well, we I did mess up the tipping sequence so you’ll see the same things reappearing during the week in case you went off the grid over the weekend. Back to you, Leon. – t.j.)
I am not a fan of the term ‘citizen developer’ when it is used as a synonym for ‘undisciplined developer’. There are plenty of ‘real developers’ who code for expediency, rather than for longevity. Whether we are using workflows, ‘real’ code or Flow, there are good habits we can adopt to make our work easier to manage and maintain.
This tip comes from discussions with my colleague Olena ‘disciplined developer’ Grischenko in regards to portal forms and workflows. Essentially, in this scenario, a form was submitted via the portal and then a workflow massaged the resulting record, as required. Initially we only had a few forms so it was tempting to have one workflow do the work.
If form is 'x' then do this If form is 'y' then do that If form is 'z' then do the other
If this, that, and the other were identical, we could call a child workflow or action, but this cannot be guaranteed.
The problem is there is a good chance we will be adding more forms in the future. It is easy to see that a few dozen forms later we have a really long workflow which we have to trawl through to find the steps which relate to our form. It will make debugging difficult and, if we are running an agile project with multiple developers working on different form stories, they could tread on each others’ toes as they all modify the same, long workflow.
The alternative is a workflow per form. Each ‘if’ becomes a different workflow. While this means dozens of workflows instead of dozens of ‘if’ conditions, we can manage this more easily through naming conventions and the search tools we have for views of records. It also means we can put a small change in a solution file instead of loading a huge workflow with only a tiny tweak (or multiple tweaks for multiple stories which we have to test en masse).
Using multiple, small workflows is easier to read, easier to manage, and we stop the developers from clashing with each other. A good, disciplined approach.
Interesting, but is there a performance difference in doing so?
For example, I do happen to have a synchronous workflow that tests the value of the category of a case upon creation.
Depending on the category, a number of actions are taken by the workflow.
There are 12 categories, i.e. 12 “ifs” within the workflow.
As you can imagine, it’s a fairly big workflow and it is indeed very cumbersome to update.
If I break this down into 12 individual synchronous workflow, I can see it would simplify maintenance and updates, what is the hit to performance?
Thanks, L-A
If you set the triggers right so only one of the 12 workflows run each time it should, in theory, improve performance.
Depending on what you’re doing you might be able to call an Action and pass through the category.
In our case we threw a little code at the problem. We set up a configuration entity which held a category and a lookup to the workflow we wanted to run. Then, instead of the if-then nest we called a custom workflow activity which found the right workflow and ran it.
Hi Leon, thanks for the reply.
All 12 workflows would trigger on change on Category so can’t avoid having all of them run to at least perform the Check Condition.
I found a potential solution similar to yours using Dynamics365WorkflowTools, specifically:
Get Record ID
Execute Workflow By ID
I added a lookup to Worfklow entity in the Category entity.
For each Category requiring a workflow, I create the workflow and link it to the Category.
I have a single workflow that says if Case’s Category.Workflow contains data, get the ID of the workflow and execute it.
Will test to see what kind of gains I can get.
I think this could be a good way of cutting down large if/else if/else statements, especially on value of a lookup.
Cheers,
L-A