Re-evaluate Approvers Upon Resubmission
Written by Michelle Henley
Updated at August 12th, 2024
In cases where a manager may change, or new information is added to a request that requires an additional approver, the system will automatically re-evaluate approvers upon resubmission of a request.
If the HR File or Mapping table has changed since the last submission of the request, then upon resubmission of a request, the following rules apply:
| Scenario | Triggered Approver |
|---|---|
| The submitter's manager has changed in the HR file since the last submission of the request | → New Manager is triggered during either resubmission of the activity, recipient, or both. (Even if the previous manager already approved.) |
| The manager of the business owner has changed in the HR file since the last submission of the request | → New manager of the business owner is triggered. (Even if the previous manager already approved.) |
| The manager approver was reassigned by a request admin upon initial submission, but the manager has now changed within the HR file | → Reassigned approver will remain, and if they have already approved, is not required to approve again. |
| Pre-populated approvers have changes in the mapping table since last submission of the request | → New approver(s) from mapping table is triggered. (Even if the previous approvers already approved.) |
If an original approver on a multi-recipient request is either deactivated or blocked since the last submission of the request, then upon resubmission of a request, the following rules apply:*
| Scenario | Triggered Approver | Approval Flow Step |
|---|---|---|
| The blocked or inactivated approver hasn't approved their step completely (activity and/or all recipients) | → The submitter is allowed to choose a new approver from the dropdown list. | → The approval step will start over with the newly chosen approver. |
| The blocked or inactive approver has fully completed their step (activity and/or all recipients) | → Approver should not be reselected | → Approval flow will remain approved at that step by the original approver. |
*The scenarios listed in the table above only apply to requests where the original approver was selected from the approver dropdown list. If the approver is pre-populated based on the HR file or mapping table, and the HR file or mapping table has not been updated, the system will not change the assigned approver.
If a submitter has a manager during the initial submission of a request, and then has no manager (based on the HR file), then upon resubmission of the request, the following rule applies:
| Scenario | Triggered Approver |
|---|---|
| The submitter has no manager upon resubmission of the request | → Original manager is triggered. |
Collaborators
If the previous manager or approver had added collaborators, then the following rules apply:
| Collaborator Scenario | Scenario | Triggered Approver |
|---|---|---|
| The original manager from the HR file added a collaborator to the request, but the collaborator does NOT take action then → | The original manager has changed in the HR file since last submission of the request | → The collaborator will remain as a collaborator on the request. The newly assigned manager is able to add/remove new collaborators and/or remove any previously assigned collaborators. |
| The original manager from the HR file added a collaborator to the request, and the collaborator takes action on the request then → | The original manager has changed in the HR file since last submission of the request | → Since the collaborator took action, the collaborator remains as the approver. Upon resubmission of the request, the collaborator should not need to reapprove. |
| An original approver, who was selected or prepopulated, added a collaborator to the request, but the collaborator didn't take action then → | The approver is removed from the workflow during resubmission | → The collaborator is removed from the request. |
| An original approver, who was selected or prepopulated, added a collaborator to the request, and the collaborator takes action → | The original approver is removed from the workflow upon resubmission | → Since the collaborator took action, the collaborator remains as the approver. Upon resubmission of the request, the collaborator should not need to reapprove. |
What happens if there are three (or more) approvers on a request, the request is currently at the third approver, and the first approver changes? Does the second approver need to re-approve the request? No. In this case, the request would go back to the first approver, which has now been changed. Then, once the new first approver has been approved, the system will skip the second approver who has already approved and resume back at the third approver.
In the example below, John Smith is now the new first approver. Once John approves, the request will go back to Chris Johnson.
Updates made by the Submitter
If the submitter initiates an update to a request that is already in progress, the system will only update conditional approver(s)s to the portion of the request that was updated.
For example, if the submitter only updates the activity, then the conditional approver will only be applied to the activity (if applicable) and not any recipient(s). In order to trigger conditional approvers on both the activity and recipient(s), the submitter must update and resubmit both.