The Problem
When triggering workflows, there are seven options:
- When the record is created
- When the status of the record is changed
- When the record is assigned (ownership changes)
- When a field on the record changes
- When the record is deleted
- Manually (an on-demand workflow)
- As part of another workflow (child workflow)
This covers a wealth of scenarios. However, there are times when we need more. Recently I worked on a project where we needed to trigger off the initial population of a field. The company was, in essence, a courier company. Customers booked international deliveries and, while the bookings were entered into the system when taken, it was only later that my client knew which plane was taking the goods.
Once the details of the plane was entered in the system, escalation checks needed to be put in place to ensure a paperwork was completed on time, deliveries reached their destination on time etc.
The obvious choice was to trigger off a field change but, if the plane details changed prior to take-off, this would trigger two escalation workflows as it is not possible in a workflow to check what the value was prior to field population. If the details changed a number of times, suddenly users are receiving multiple notifications for the same delivery. This was undesirable.
The Solution
The first option in dealing with this scenario is to use a check box on the record. When the workflow is first triggered, the tickbox is ticked and future workflows, checking for the tickbox no longer fire. Another related option is to have a field keep a copy of the previous value, managed through workflows. I outline this approach here.
This would have worked but there were a number of date fields that I needed to trigger off (about ten in total) and the overhead of adding another ten checkbox fields or adding fields and workflows was a bit high for me.
In the end I settled for a different approach; instead of using the ‘field change’ event, which can be triggered multiple times, I used the ‘record creation’ event which will only ever trigger once. The screenshot below shows the trigger on the ‘Vessel ETD’ field; the plane’s estimated time of departure (ok, so the project is on a v4 system, but the approach also works 2011).
Here we are saying when the delivery contract is entered into the system, fire the workflow and then wait until the ‘Vessel ETD’ field is populated. When this happens, fire a number of ‘checks and measures’ workflows.
These child workflows then kick in. Here is one of them:
In this case, once populated, we check the contract is a parent contract (the system allows for subcontracts on the same flight contract), double check the field contains data (not really needed) and then it sets up a reminder a couple of weeks before departure.
The advantage of this approach is that we guarantee that the workflow will only trigger once and, if we have a number of checks and measures running off of the same field, it is quite easy to manage this through the use of child workflows stemming from the one trigger workflow.
The disadvantage of this approach is, if there is significant time between the creation of the record and the population of the trigger field, we have a workflow in a waiting state gobbling up processor cycles. This is more of an issue if we have a high volume of contracts, which I did not have in this case.
Conclusions
If you are needing to trigger off the initial population of a field but do not want to fire the same workflow when the field gets updated there are a few approaches with workflows before resorting to code. Using a check box can work but can be tricky to manage and adds the overhead of a bunch of fields which are just used for workflow management. Adding a mini-audit function can also work but requires additional workflow and fields to be added to the system, again adding to workflow management.
By triggering off of the creation of the record, and waiting for the field to be filled in before acting, we create an intuitive system with minimal overhead in terms of fields or workflows which can be easily adjusted as the processes of the business evolve.
1 comment:
Amendment: George Doubinski: Fellow MVP and a man of infinite wisdom and jest reliably informs me that waiting processes do NOT take up cycles after all meaning there is minimal disadvantage to this approach.
Thanks George :) (and yes it was a custom contract entity)
Post a Comment