What This Table Is

The sysapproval_approver table stores individual approval records that require specific users to take action. Each record represents one person's approval decision within a larger approval process. When a Change Request needs approval from three managers, ServiceNow creates three separate sysapproval_approver records—one for each manager.

This table is owned by the Platform module and supports approval workflows across all ServiceNow applications—Change Management, Service Catalog, HR Service Delivery, and custom applications. The approval engine automatically creates these records when tasks enter approval states, and users interact with them through My Approvals or email notifications.

The table extends task, inheriting standard task fields like number, state, and description. No tables extend sysapproval_approver—it's a leaf table in the inheritance tree. The source_table and sysapproval fields link each approval back to its originating task and parent approval record.

Large enterprises see significant record volume—a busy Change Management process might generate 50,000+ approval records monthly. Performance matters when querying active approvals or building approval dashboards. The table includes indexes on approver, state, and source_table to support common query patterns.

When You'll Script Against This Table

You'll script against sysapproval_approver primarily in Business Rules triggered by approval state changes, Script Includes that build approval logic, and Scheduled Jobs that escalate overdue approvals. UI Actions on approval forms often query this table to show approval history or chain status. Background Scripts frequently query approvals for reporting or bulk approval operations.

Access requires the approver_user role to read approval records, and approval records have built-in ACLs that restrict visibility to the assigned approver, task requestor, and users with admin roles. Scripted queries run with elevated privileges can bypass these restrictions.

Common scripting patterns:

  • Query active approvals for a specific user to build custom approval dashboards
  • Check approval completion status before advancing task workflow states
  • Automatically reassign approvals when users are out of office or inactive
  • Generate approval metrics and SLA reporting for management dashboards
  • Send custom notifications when approvals are overdue or require escalation
  • Bulk approve or reject multiple approvals based on business logic conditions
  • Create audit trails showing complete approval chain history for compliance

Table Gotchas

⚠️

The state field uses different values than typical task states. Active approvals are state='requested', approved records are state='approved', and rejected records are state='rejected'. Never query for state='1' expecting active approvals.

⚠️

The approver field references sys_user, but approval records can exist for inactive users. Always check approver.active=true in queries, or you'll include approvals assigned to deactivated accounts.

  • The source_table field stores the table name as a string, not a table reference. Use source_table='change_request' not a sys_id value.
  • Approval records inherit task security, but have additional ACLs. A user might read a Change Request but not see its approval records if they lack proper approval roles.
⚠️

Querying approvals without filtering by source_table or approver performs poorly at scale. Always include at least one of these indexed fields in your query conditions.

  • The due_date field can be empty even when approval SLAs are configured. Check both due_date and task SLA records for complete escalation logic.
  • Modifying approval records directly can break approval workflows. Use the Approval API or built-in approval actions instead of direct GlideRecord updates when possible.
Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

No spam · Unsubscribe anytime

Related Tables

The parent task table provides inherited fields like number, state, and sys_created_on. When building approval reports or audit trails, you'll often join approval data with task workflow states and assignment history. The sys_user table connects through the approver field to get approver details like department, manager, and active status.

The sysapproval table contains parent approval records that group individual approver records together. Query both tables when you need approval chain logic—checking if all approvals in a group are complete, or finding the approval policy that generated the approvals. Source task tables like change_request, sc_req_item, and sc_request link back through document_id to show the complete business context around each approval decision.

The wf_activity and wf_context tables connect when approvals are part of workflow processes. Advanced approval logic often queries these tables to understand which workflow step generated an approval, or to programmatically advance workflows after approval completion. The sys_email table frequently appears in approval scripts that send custom notifications or parse approval responses from email.