Approval Sequences Best Practices
Overview
The Submit Action and related SubActions (Approve, Reject, Revise, Request Approval) provide a much cleaner user interface for managing approvals.
The action clicked on the user-side does not always trigger the same, corresponding, action in the system.
The table below describes the user-clicked action and the conditions on which an action is performed by the system.
Table of user-clicked actions & conditions
| Submit |
No Approvals Required. No conditions are met on any of the Reason Trees. |
Submit |
| Submit |
1 or more Approvals Required. Conditions are met on at least one of the Reason Trees. |
Request Approval |
Approve
(green check mark) |
This is the final Approver across all Reason Trees. No further Approvals Required. |
Submit |
Approve
(green check mark) |
1 or more further Approvals Required. There is at least one more approval pending across all Reason Trees. |
Approve |
| Revise |
Always |
Revise |
| Reject |
Always |
Reject |
Administration
Reset reasons on "Revise" action
The Revise action does not send out emails after evaluating the reason tree and finding new active reasons.
Don't reset reasons on "Reject" action
When resetting reasons on reject, they are immediately re-evaluated and emails are sent to the appropriate approvers. Therefore, the Approval Description will not contain the correct information upon rejection.
Don't transition on "Reject"
The intended functionality is that the Sales Rep will revise the transaction if the quote is rejected.
Return at least one approver when using advanced approver functionality
- The functionality uses the format
1~user~company|2~group~company
- The "1" denotes that it is a user that you are designating as the approver.
- The "2" denotes that it is a group that you are designating as the approver.
- The "|" can only be added in if there are multiple approvers. If it is included at the beginning or the end it will cause an error.
- When using the advanced approvers, you must return an approver: it cannot be blank.
Adhere to one pending approval step when setting up transitions
Adding in multiple steps increases the complexity of the build. This is definitely the case when trying to transition after more than one approval. Most use cases can be handled with having a variety of participant profiles.
Keep parent action "Submit" and sub-action "Submit for Approval" advanced modifications equivalent
The JavaScript pop-up comment box is generated based on the parent's advanced modification. If the parent modification affects the reason tree's evaluation differently than the sub-action, this can lead to inconsistent results.
Hide "Submit" attributes on pending step
This will result in less confusion for the user.
Approval trees don't control access to profiles
Add each potential approval group to the Approver profile, either using Advanced Forwarding or static User Access Rights. When a non-Approver accesses a Quote, they will be able to view the Quote using their profile, but will not be able to Approve/Reject.
Summary of "Submit for Approval"
- Line level modify tab is evaluated if line level changes have happened
- Advanced modification for update line is applied if there are line level changes
- Advanced validation for update line is applied if there are line level changes
- Quote level modify tab is evaluated for the Submit action
- Advanced modification for the Submit action is applied
- Advanced validation for the Submit action is applied
- Reason tree is evaluated and 'Submit' attributes are updated
- If approval is needed (for example, if at least one reason evaluated to true) modification to the transaction is not saved and the user gets a pop-up to enter comments.
If there were no reasons to evaluate, the modification would be saved and the parent action's transitions would fire.
User enters comments and clicks Submit
- The child 'Submit for approval' action is then fired
- Line level modify tab is evaluated if line level changes have happened
- Advanced modification for update line is applied if there are line level changes
- Advanced validation for update line is applied if there are line level changes
- Quote level modify tab is evaluated for the 'Submit for approval' sub-action
- Advanced modification for the 'Submit for approval' sub-action is applied
- Advanced validation for the 'Submit for approval' sub-action is applied
- Reason tree is evaluated and 'Submit' attributes are updated
- Line level modify tab is evaluated if line level changes have happened
- Advanced modification for update line is applied if there are line level changes
- Advanced validation for update line is applied if there are line level changes
- Quote level modify tab is evaluated for the sub-action
- Advanced modification for the sub-action is applied
- Advanced validation for the sub-action is applied
- Reason tree is evaluated and 'Submit' attributes are updated
|
- Line level modify tab is evaluated if line level changes have happened
- Advanced modification for update line is applied if there are line level changes
- Advanced validation for update line is applied if there are line level changes
- Quote level modify tab is evaluated for the sub-action
- Advanced modification for the sub-action is applied
- Advanced validation for the sub-action is applied
- Any reset reasons are reset
- Reason tree is evaluated and 'Submit' attributes are updated
|
If the user clicks the Revise Sub-action it evaluates the same as a normal Modify action with only one difference: any reasons that are checked to reset are reset and the reason tree is evaluated, but emails are not sent.
Related Topics
See Also
