Explain why this feature exists and how it can be used. Provide common scenarios and use case benefits.
Self approvals can allow for faster cycle times and reduced overhead for scenarios where the end user is entrusted to make the purchase themselves. Given that with Coupa there is full spend visibility, reporting, watchers, and spend guard alerts - self approvals can become a less daunting endeavor.
Many organizations look to define these holistically across their user base for consistency and transparency in terms of what is allowed and what is not. And while there's no magic number to set these at, typically self approval limits range from $250-$1000.
List out any configuration/design considerations that should be taken into account when defining the design. Include details on common mistakes, misconceptions, or things to look out for.
Include Suite Synergy considerations as well - if/how this relates to other areas of the platform.
- Standard self approvals trigger as part of the management hierarchy and will not override any custom approval chains configured.
- If your core approval design focuses on dynamic approvals (ex: cost center based) rather than management hierarchy you should have consistent self-approval limits to allow the dynamic chain to be triggered after the dollar threshold for self approval.
- Self approvals can be enabled at a global level and defined at a user level or through custom approval chains by listing the approver as the 'Requester'. The latter should be used to a limited degree to avoid extensive approval chain management.
- Define review process to manage spend guard alerts or other reports related to self approval
Regional/Country Specific Considerations
List any countries that have unique specifications in regards to this feature/design. Create separate pages with those details and link them here. If there are none, list N/A.
- Country 1
- Country 2
Do's & Don'ts
List out the specific elements that are defined as part of this feature/function. For each provide the Coupa recommended design (best practice), alternative designs that are acceptable, and risky designs that are not recommended. These should be styled in a yes/no format - where someone can understand and clearly state whether their design has that incorporated or does not. Try to remove any ambiguous language. Also list out the rationale for why we recommend one design over another or why the risky design would create challenges.
|Design Element||Recommended Design||Alternative Design||Risky Design||Rationale|
|Enable Self Approval||Set self approval limit on user record.||Use a custom chain to set a single limit for everyone||Complex rules for when self approval is allowed (excess of 50 chains to define self approval rules)||Using the standard functionality of setting the self approval limit on the user record allows for easiest maintenance and applies across modules.|
|Self Approval Amount||Keep value consistent across all users||Values inconsistent across users (when core design is not management hierarchy)||Inconsistencies will require more maintenance effort and complexities in custom approval chains. It also may be challenging for users as they are unclear on scenarios where they have the authority to self-approve.|
User Record Limit (source of truth)
|Feed approval limit information from HR system along with other user record details||Maintain user record information through user forms||
No source of truth for self approval limits
|Without a source for this information this will need to manually maintained for each user.|
Heat Map Assessment
(heatmap descriptors remains the same for all)
For this specific heatmap item articulate why the heatmap should be colored one way or another.
Some things may not be applicable for "Out of Scope" or "External Solution" - list N/A if that is the case.
|Self Approvals will not be used for any scenarios||No Risks are incorporated into the current design and the design is fully defined (all design elements determined).||Customer is still determining use cases for Self Approval||One or more Risks are incorporated into the current design||Self approvals are happening offline or via a third party application|
Related Success Metrics and Value Drivers
List out relevant metrics/BVDs that this feature/design may have an impact on and any considerations that should be taken into account because of this.
- Approval Cycle Time
- Avg. Number of Approvers per Transaction
If these are key metrics for a customer's business, enabling self approvals could make a significant impact to these values while not leveraging this feature may be a risk in itself.