Approval SLAs in ServiceNow

[Akash Bhardwaj]

One of the interesting challenges that often comes up during ServiceNow implementations is how to track Approval SLAs — especially when you have multiple levels of approvals (User, Line Manager, Group, Organizational, etc.) and want meaningful reporting across all of them.

While ServiceNow offers a robust approval framework out of the box, it doesn’t natively provide a straightforward way to track SLA metrics for approvals the same way it does for Incidents or Tasks.
Recently, we explored a clean, scalable way to achieve this without disrupting the OOTB logic.

The Business Requirement

The core ask was simple on paper:

“We need to track SLA metrics for all approvals — whether user-based or group-based — and report on the turnaround time for each.”

But the challenge lay in where to define these SLAs.
Since approvals are stored in the sysapproval_approver table (which isn’t a Task extension), SLAs cannot be directly applied using the standard SLA engine that relies on the Task table hierarchy.

That led to a design discussion:
Should we customize the core approval model, or should we extend it in a maintainable way?

The Proposed Approach

To meet the requirement, we proposed creating a custom table named “Approval SLAs”, designed as follows:

1. Extend from Task:
   The table extends from the Task table, enabling SLA definitions to be applied natively.
2. One-to-One Record Mapping:
   Each record in sysapproval_approver will have a corresponding entry in Approval Metrics.
   This keeps the data model simple and aligned to the source of truth.
3. Reference Linking:
   A reference field in Approval Metrics links back to the original approval record.
4. Automation via Business Rule:
   A business rule runs on the sysapproval_approver table to automatically create the related record in Approval Metrics whenever a new approval record is generated.
5. SLA Definition:
   SLA definitions are built directly on the Approval Metrics table, using approval states as the trigger conditions (e.g., Requested, Approved, Rejected).

This model provides all the flexibility of SLA reporting — durations, breaches, trends — while keeping the OOTB approval process untouched.

The Architecture Discussion

As with any good design conversation, the proposed model prompted a few valid concerns

1. Would this duplicate records for Group Approvals?

Response:
No, it wouldn’t. The Approval Metrics table only references approvals from sysapproval_approver, meaning it doesn’t replicate or replace the OOTB Group Approval tasks — it simply mirrors the approval record for reporting purposes.

1. What about SLAs for Group Approvals where only one member needs to approve?

Response:
That can be handled through SLA cancel conditions. For example, when the approval state changes to Not Required, the SLA is canceled. SLA reporting will focus only on completed approvals (Approved or Rejected).

Conclusion

In the end, the “Approval SLAs” model provided a neat, maintainable way to measure approval SLAs without disrupting the base approval framework.
It offered the flexibility to define SLAs on approvals, measure performance, and maintain full traceability to the original records.