The other day I was helping a colleague with a workflow that wasn’t working. He had a number of “Set Transition” MPRs that were behavingĂ‚Â as expectedĂ‚Â – except for one.
Eventually the penny dropped – it was because the transition set was based on a datetime attribute – a “Temporal Set”.
With temporal sets you define rules like “EmployeeStartDate after today” or “EmployeeEndDate prior to 14 days from today”, however these rules are only evaluated once per day – around 1am. This is the case even though you will see the object listedĂ‚Â in a Set preview.
So, as it turns out, with Set Tranisition MPRs, they only fire when the set re-evaluation is done: at 1am.
However with “Grant Permission” MPRs the workflow will in fact fire immediately, as it is part of the permissioning process to making the change.
So the moral is twofold:
- If you need to test a workflow then use a Grant Permission MPR, or a non-Temporal Set Transition MPR, to trigger at will; and
- Don’t be alarmed when datetime changes don’t trigger workflows immediately.
Objects join temporal sets if an attribute changes on the object that now makes it satisfy the criteria, or through the passage of time (which yes is typically evaluated at 1 AM by a SQL Agent job). You can run the job more frequently to cause it to reevaluate your temporal sets.
Hi Carol,
The SQL agent job ‘FIM_TemporalEventsJob’ schedule can always be changed to execute more frequently which can be useful during testing.
Cheers
Paul