2820380 - How Scheduled Workflows Work

This KBA describes the logic behind the Scheduled Workflows Future

Workflow Scheduling

Workflow rules can either be configured to be executed during the create of the object instance or on any save of it. But in scenarios where the execution is not required to happen at the time of modify but in future, we have a concept of workflow scheduling.

A workflow rule can be scheduled on/after/before a certain time frame based on a date/date-time type data field.

Consider a date-time field “XYZ” which is created for Tickets. Now a key user can configure a workflow rule stating that the rule should be triggered 10 minutes after the date-time in XYZ field whenever the conditions of the rules are met.

Now whenever the ticket instance will be changed and the conditions are met, the workflow engine will check the value of the field XYZ and add 10 minutes to it. If the result after the addition falls in future (ahead of the current time) then the instance of this ticket instance and the rule which is supposed to be executed and the time of execution will be added to the queue to be executed in future. If the time falls in past (from current time) then the rule will not be scheduled for this ticket instance and it will be canceled with the status “Activation in the past”.

To clarify it further consider an example where an end user is changing the Ticket at 10:00 AM.

1. If the value of the field XYZ is 9:55 AM. Then adding 10 minutes to it, brings the final execution time as 10:05 AM which is ahead of current time and this will be added to the queue.
2. If the value of the field XYZ is 9:49 AM then adding 10 minutes to it, bring the final execution time as 9:59 AM which is in past of current time and hence it will not be scheduled.

Now focusing on only case 1, the queue will look like this.

Now this queue can have several such instances of different objects and different rules with different time of executions. For simplicity, let us just take only one rule in consideration and several ticket instances.

Now how does this gets executed?

There are two cases of it:

1. C4C has a master job which runs every hour. It might be at 01:00, 02:00, 03:00.. or 00:30, 01:30, 02:30…and so on. What this job does is that it at the time of its execution it will look into the queue and find all the instances which are supposed to be executed by now or in the next one hour. So if we take the above table, then if the master job runs at 09:00, it will find the instances corresponding to T7, T8, T9 and T10. Now it sorts them in descending order: 09:55, 09:52, 09:47, 09:43. And will start from the first and will group all the instances together which are falling in the time zone of 5 minutes.

This grouping is done so that in one hour we have a maximum of 12 executions to improve the performance. If that is not the case and one execution is done for each instance then in the scenarios where hundred thousand instances are created in the system it will result in equal number of executions and will affect the system drastically. Here you can see that in the execution of some of the instances a delay can be expected (maximum of 5 minutes).

Now take a case where the master job at 09:00 did not run run for some reason. Though it will never happen. Then the job at 10:00 will find all the instance as scheduled including the ones mentioned in the table above. Now this job will again sort them and group them together as shown in the table below.

The delays marked in Red in the table above will never happen as the master job never fails to run every hour and schedule the corresponding entries in the queue.

1. We have another case where the scheduling of the instances of the queue are not done via the master job explained in point 1 above but are done immediately.

To understand it consider a use case where the change is done at 09:10 and the time of execution is 10 minutes later which is 09:20. Now the master job is supposed to run at 10:00 so if we wait for the master job to pick this instance at the time of its execution and schedule it, then this instance will get delay by over 40 minutes because master job will schedule it at 10:00 only. To avoid such situations such instances are scheduled directly without relying on the master job. And here one execution happens for every instance which might affect the performance. Here we always suggest to the customers that such configurations should be avoided because it bypasses the concept of grouping mentioned in the point 1 above and might result in huge number of executions.

In a nutshell, at the time of change, if the time of execution falls ahead of the next run of the master job then it is left up to the master job to pick it up later and schedule it(as explained in point 1 above). And if the time of execution falls before the next run of the master job then it is scheduled immediately without any delay. Here a maximum delay of only few seconds can be expected.

KBA , LOD-CRM-WKF , Workflow , How To