OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Request Approvals: Design Controls That Work

ServiceNow request approvals should answer four questions: what is being requested, why approval is needed, who has authority to decide, and what happens after the decision. A control that adds delay without clarifying risk is not a useful approval design.

For request owners designing approvals that are proportionate, traceable, and useful in ServiceNow..

ServiceNow request approvalsrequest approval workflowapproval authority
Discuss this ServiceNow topic

Guide map

Designing approval steps that people will follow

Decide which requests require approval

Approval is worth its delay only for requests that spend money, grant access or change something hard to reverse, so keep routine requests out of the approval chain.

Match authority to consequence

Set approval rules by risk and cost rather than by request category alone, so low-risk items move quickly and sensitive ones get the review they need.

Capture evidence and decision reasons

Each approval should record who decided, what they saw and a short reason, so an auditor or a manager can reconstruct the choice without asking anyone.

The practical framework

Design ServiceNow request approvals with clear criteria, authority, evidence, delegation, timing, rejection reasons, fulfilment, and auditability.

Decide which requests require approval

Separate requests that can be fulfilled by a defined rule from those that affect access, cost, risk, policy, service condition, or another person’s responsibility. Explain the approval trigger in terms the requester and approver can understand. Avoid sending every request to a senior approver simply because the process has no better distinction.

The ServiceNow service-catalogue route is the relevant internal destination when request choices and approval triggers need clearer design.

Match authority to consequence

Define who can approve the request, what evidence that person needs, and when another authority is required. Consider service ownership, data sensitivity, financial or operational consequence, and separation of duties. Keep the approval boundary visible when a request changes during fulfilment.

The ServiceNow access-controls route provides an internal path when approval design affects access or control evidence.

Capture evidence and decision reasons

The approval record should show the request scope, requester, affected service or resource, authority, decision, timestamp, comments where needed, and supporting evidence. A decision marked approved without explaining what was reviewed may not help a later audit or dispute.

The ServiceNow GRC evidence route is relevant when evidence requirements are part of the control design.

Handle delegation, rejection, and expiry

Define how delegated authority is recorded, when an approver is unavailable, what a rejection must explain, and when an old approval expires. Do not allow a stale approval to silently authorise a changed request. Re-approval should be triggered by a meaningful change in scope or consequence.

The ServiceNow process-automation route supports the workflow and exception design.

Connect approval to fulfilment and review

Approval should release the right fulfilment work and preserve the decision context for the person completing it. After fulfilment, check whether the result matched the approved scope and whether repeated exceptions show that the catalogue or approval rule needs improvement.

For request approval controls work, the ServiceNow continuous-improvement route provides the next internal path.

Common questions

Questions teams ask about request approvals

Can every request use the same approver?

Usually not. Authority should reflect the request’s consequence, affected service, access or data boundary, and policy. A single approver may be appropriate for a narrow class of requests but not as a universal shortcut.

What makes an approval auditable?

The record shows what was requested, what evidence was considered, who had authority, what decision was made, when it was made, and what fulfilment followed. It also explains exceptions, delegation, or re-approval.

The research-grounded boundary

Approval controls also touch security, compliance, and governance, and in ServiceNow they sit inside the platform where requests are raised and decided. For this article, the test is practical: can the team explain the normal route, the blocked route, the correction route, and the review that follows each one? The request approval controls operating record should make the normal path and the correction path equally understandable.

Map each approval trigger to the consequence it guards

An approval earns its place only when the consequence of approving the wrong request is larger than the delay the approval adds. The design work is to sort the catalog into request classes by consequence, then assign each class a rule that a requester can predict. Requests for a standard laptop from a fixed list rarely need a human decision at all. Requests that grant higher-privilege access, change a cost center or alter a production service need a decision from someone who can see the consequence. Poor approval designs often send everything to the same senior approver because nobody took the time to draw the line between the two groups.

Request classApproval rule shapeWho holds authorityRe-approval trigger
Standard item from a fixed listNo approval, or automatic approval against a defined ruleThe rule owner, reviewed periodicallyA change to the item, its price or its eligibility
Access to a business systemManager approval followed by a data owner decision for sensitive rolesThe line manager and the system’s data ownerA change in the requested role or the data it reaches
Change to a production serviceParallel approval from the service owner and the risk functionBoth, with either able to refuseA change in scope, timing or affected service
Spend above a set limitSequential approval up the finance lineThe budget holder at the level the limit definesA change in amount or cost code

Build the approval path as an ordered sequence

The order of approvals matters as much as the number of them. Sequential approval puts the most senior person last, so they see a request only after the lower steps have accepted it. Parallel approval gets an answer faster, but a refusal from one approver may come after another has already accepted, which leaves a messy record. The sequence below is a practical way to decide which pattern each request class should use.

  1. Write the decision each approver is making in one sentence, so the approver knows what they are accepting and what they are not.
  2. Place the approvers in order of the consequence they can see, with the approver closest to the detail first.
  3. Choose parallel approval only where both approvers hold independent authority and either can refuse without needing the other’s view.
  4. Define the evidence each approver receives, such as the request scope, the affected service and the risk statement.
  5. Set the route for a rejection, including the reason field that must be completed and who is told.
  6. Define what happens on timeout, and make sure the default is an escalation rather than an automatic approval.

Where approvals stall or go wrong

A stalled approval is often a delegation problem. An approver is on leave, nobody holds a delegation, and the request waits until someone notices. Designs that add a named delegate for each approver remove much of this, provided the delegation expires and is visible. A second problem is an approval given to a request that has since changed. Approving the original scope and then letting the fulfillment team deliver a larger change is the kind of gap an audit can flag. The approval should be tied to the version of the request that was reviewed, and a material change should reopen it. The ServiceNow access, privacy and segregation of duties page connects what a person can see or do with the workflow decisions and responsibilities that access affects, which is relevant to access requests in particular.

Rejections are the third problem. A rejection with no reason gives the requester nothing to correct and leaves the same request to return unchanged. A reason field with a short list of common causes, plus a free-text note, produces rejections that can be acted on. The ServiceNow employee workflows and HRSD page covers making a difficult employee request easier to complete while giving the service team enough context to act, and the same approval design questions arise there.

Approval evidence worth keeping

An approval record is useful to an auditor only if it shows the decision and the basis for it. Keep the following for each decision: the request version reviewed, the approver and whether they acted as the delegate, the timestamp, the decision, the reason where one was required, and the evidence the approver was shown. A record that says approved with no version or basis may satisfy a dashboard but will not answer a dispute about what was authorized.

Testing the approval path before release

Test the path with at least five routes: a normal approval, a rejection with a reason, a timeout that escalates, a delegated approval, and a changed request that must return for approval. Run each route as the real approver role rather than an administrator account, since role conditions often behave differently from what the designer expected. Record what each route produced, and keep the test evidence with the catalog item so that a later change can be checked against it.

Questions about request approvals

Should managers approve their own team’s requests?

Often they should for routine access, but not where they are also the owner of the data or service the request touches. In that case the approval needs a second authority, so that the person who benefits from the decision does not also decide on it alone.

What happens when an approver leaves the organization?

The approval routing should be driven by a role or a function rather than a named person, so that a departure reroutes pending items automatically. Pending approvals assigned to a departed person should be reviewed as a batch, not left to expire. The ServiceNow employee offboarding controls page treats offboarding as a coordinated handover rather than only an access-removal task, which makes approver routing for leavers part of the picture.

Can fulfillment begin before approval is complete?

Preparation work that changes nothing in a live service can start, such as reserving a device or drafting a configuration. Any step that grants access or changes a service should wait for the approval the step depends on.

How should emergency requests be handled?

Define an emergency route in advance, with a named authority who can approve under pressure and a rule that the normal approval is completed afterwards. Without that rule, an emergency route quietly becomes the normal route.

Reviewing which approvals still earn their place

If approvals in your catalog slow down routine work or fail an audit, the first task is to separate the requests that need a decision from those that need a rule. The ServiceNow change, request and service catalog management page covers helping a person recognize the service or change they need and understand what happens after submission, and you can discuss the approvals you run today.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading