As much as possible I like to keep my Workflows simple with a minimum number of steps. When updating attributes I prefer, wherever possible, to only update a single attribute per Workflow Definition. So for example I’ll have separate Workflows for “Set DisplayName” and “Set AccountName” rather than rolling the two together in a single “Set Attributes on Creation” Workflow.
There are a few advantages to this approach:
- When you look at the list of Workflows triggered by a MPR it is really easy to see what they’re doing without having to drill down into the Workflow Definitions themselves.
- The Workflows are re-usable: that “Set DisplayName’ workflow can be used both at object creation and when a name is changed.
- You’re less likely to inadvertently run two workflows at the same time that update the same attribute resulting in the dreaded “SQL insert duplicate” error and a failure of the activity.
Of course there are good reasons to run multiple steps in one Workflow Definition, in particular where you need to ensure a certain order. This best practice does not negate such requirements. However more often than not we pile extra steps into an existing Definition because it seems quicker and easier at the time, when for the sake of clarity, and long-term reusability, we’d be better off creating new Workflows for those extra steps.
Hi Carol
Agree 100% on the first bit, and it leads logically to the second idea about atomic updates. However in large systems I’ve found the cost is too high for this in terms of generated request activity, and I’ve found requests are far more readable and efficient if you can combine your updates in a single step. Therefore what I do is build up a single request update using WorkflowData as necessary, then commit all changes in a single action. I started out the way you have but changed pretty quickly shortly after …
Just my take, and why the 2 CRUD workflow activities I use are so valuable to me.
Cheers
Bob
I need to agree with Bob on this. The performance considerations outweigh the cleanliness. I do agree that the duplicate SQL insert is a pain.