Broken workflow issues often arise when processing leave with HR21. You will know a workflow has broken when an escalation is directed to the fallback manager. Escalations occur when the time allocated for a workflow request to be actioned has elapsed and so the system attempts to send the request to another manager.
The fallback manager is the catch all when the system doesn’t know how to proceed with a workflow record. This person is usually someone with responsibility for making sure all workflow records are processed, such as the payroll manager. The trouble is that broken workflows can become an unnecessary burden on the fallback manager.
The aim is to set your system up so that the incidences of broken workflows are minimised. I say minimised because it would be impossible to completely eliminate all of these issues. See my blog 8 Ways to Optimise Your HR2 Workflow for more information about setting up your workflow.
So what causes broken workflows? It’s usually a position that has been closed (end dated) or a position that has no incumbent. In either of these cases the system won’t know who to escalate the workflow record to and so it will defer to the fallback manager.
A common trigger for broken workflows
If you make a position change after a workflow process has been initialised but before it is completed then there is the potential for a broken workflow. Consider this example:
Let’s say an employee requests leave via HR21. As a consequence of this, a workflow process is started and an email alert is sent to the employee’s manager. Soon after this the Payroll department makes a change to the manager’s position (POS record). If position history is being maintained, then the current position record will be end dated and a new position record created. The problem is, the workflow process doesn’t know about the new position record that has just been created by Payroll. When attempting to escalate the request it still looks at the previous record which is now closed.
Note in the screenshot above how the position has been changed and history created. If an employee requested leave before this change was made (15/08/2013) then the workflow process could continue to refer to the second record. However, this record is now closed so will cause the workflow process to break.
You can avoid this situation by regularly refreshing the position tree. Do this by running the Load Position Tree (RTR) process in Chris21. By running this process daily you will rebuild the position staff relationships in HR21. The best way to make sure this happens is to schedule the RTR process to run automatically on a daily basis. To do this, go to RTR and select the Reports To and Initialise Tree checkboxes. Then click the Run Options tab at the bottom of the page. Refer to my blog How to Schedule Reports in Chris21 for help scheduling this process.
A final important note: when scheduling RTR make sure that it runs before the Control Forwarding (WFF) process. This will ensure that the system is up to date with position changes before any escalations are processed. This in turn will reduce the incidences of broken workflows and reduce the burden on the fallback manager.