Tip #1100: Consider using parallel workflows instead of if-then statements

(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.