Task Routing & Approvals: The Complete Guide to Risk-Based Workflow Design

Task Routing & Approvals: A Risk-Based Guide for IT and SaaS Teams

A password reset that waits two days for a manager's sign-off shows an approval chain built for the wrong risk. Task Routing & Approvals decide who receives each request, who must authorise it, and what happens automatically. This guide from the Zero Touch IT Editorial Team covers risk tiers, routing rules, approval patterns, escalation design and audit evidence, and includes a scoring framework you can adapt.

By Zero Touch IT Editorial Team. We review this guide when the referenced frameworks are revised.

• What Task Routing & Approvals Means
• Match Approval Depth to Risk
• Routing Rules That Work
• Approval Patterns Compared
• The Routing Risk Score Framework
• Escalations, SLAs and Delegation
• Common Mistakes
• Implementation Checklist
• FAQ

What Task Routing & Approvals Means

Task Routing & Approvals is the logic that sends a ticket, change or access request to the right resolver group, then collects the authorisations its risk requires before work starts. Routing handles assignment. Approvals handle permission. The two fail in different ways, so design them separately.

When routing fails, a request sits in the wrong queue and gets reassigned several times. When approvals fail, work waits on someone who adds no real oversight, or risky work goes ahead without review. Many teams fix one problem and make the other worse. Adding approvers to stop a bad change slows routine fulfilment for everyone. Removing approvers to speed delivery weakens control over the rare high-impact change.

Every workflow has four parts:

• Intake: structured fields such as category, affected service and requester role that routing can act on.
• Assignment logic: rules that map those fields to a resolver group or an individual.
• Authorisation gates: the approvals required for the request's risk tier.
• Evidence: a timestamped record of who approved what and why.

Match Approval Depth to Risk

Approval depth should depend on risk and impact, not on habit or seniority. The ITIL 4 framework sets the reference model. It sorts changes into standard, normal and emergency types, and each type gets a different level of governance and approval based on risk and impact, as ITSM.tools explains in its overview of ITIL 4 change enablement.

A standard change is low-risk, repeatable and pre-authorised, follows a documented procedure, and often needs little or no additional approval. These changes are frequently automated, according to ITSM.tools. A normal change must be assessed and authorised before implementation, based on factors such as risk, impact, urgency and complexity (same source). Emergency changes need fast authorisation, with fuller review afterwards.

The same tiers work beyond change management. Software licence requests, onboarding tasks and access grants can all be sorted as standard, normal or urgent. Using one shared model lets a SaaS operations team run Task Routing & Approvals with one consistent set of rules across every request type.

Routing Rules That Work

Good routing rules are deterministic, depend on structured data, and send anything they cannot match to a monitored triage queue. Free-text keyword matching is fine as a fallback, but it should not drive core routing.

Evaluate rules in this order:

1. Service ownership: route to the group that owns the affected service or configuration item.
2. Category and subcategory: narrow down to a specialist team, such as identity or endpoints.
3. Location or tenant: for multi-site or multi-tenant SaaS estates, route to the regional queue.
4. Skills or load balancing: within the group, assign round-robin or by skill tag.
5. Fallback: send unmatched requests to triage and review them each week to find missing rules.

The fallback queue is your best diagnostic. If one category keeps landing there, the intake form is missing a field. Fix the form before you add another routing rule. For device-related requests, routing gets far more accurate when endpoints are already enrolled and tagged. Our guide to automated device management covers how to keep inventory data reliable enough to route on.

Approval Patterns Compared

Most Task Routing & Approvals designs use five patterns: pre-approved, single approver, sequential, parallel and committee. Choose the lightest pattern that still produces real accountability.

ITIL 4's Change Authority concept supports this range. A change authority can be a delegated team, a peer review mechanism for standard changes, an automated approval inside a CI/CD pipeline, or business stakeholders for high-risk changes, according to ITSM.tools. In practice, the approver is a role that fits the risk, not a fixed committee.

Parallel approvals are often misconfigured. If security and finance both review a new SaaS subscription, write down whether one rejection ends the request or sends it back for rework. If that rule is left undefined, approvers send emails back and forth outside the audit trail.

The Routing Risk Score Framework

The Routing Risk Score is a Zero Touch IT framework. You score each request type on four factors from 0 to 3, add the scores, and the total sets the approval tier. It turns ITIL's risk factors into a rule a workflow engine can apply.

• Impact scope (0–3): one user, one team, one service, or the whole organisation.
• Reversibility (0–3): instant rollback, scripted rollback, manual rollback, or irreversible.
• Data sensitivity (0–3): none, internal, confidential, or regulated or privileged.
• Novelty (0–3): done routinely, done occasionally, done rarely, or never done before.

Here is an example. Granting a user a standard design-tool licence scores 0 for scope, 0 for reversibility, 0 for data and 0 for novelty, for a total of 0, so it is automated. Granting admin rights to a finance platform scores 1, 2, 3 and 1, for a total of 7, so it needs both owner and security sign-off. Score request types, not individual tickets, so the tier is fixed when the catalogue item is built.

Escalations, SLAs and Delegation

Every approval step needs a time limit, a named delegate and an escalation target. Without them, one person on leave can stall a whole queue. Set these three items when you build the workflow, not when a problem appears.

• Reminder: send automatically partway through the approval window.
• Delegation: approvers set out-of-office delegates, and the system routes to them automatically.
• Escalation: when the limit is reached, move the request to the approver's manager or the service owner. Never auto-approve.
• Emergency path: quick verbal or chat authorisation, recorded on the ticket, followed by a mandatory retrospective review.

Do not auto-approve on timeout. It defeats the purpose of the approval gate and creates an audit finding. Speed up low-risk work by moving it to the pre-approved tier instead. Teams that run zero-touch onboarding workflows use this method: they pre-authorise role-based access bundles once, so new starters do not trigger approvals for every app.

Common Mistakes

Most Task Routing & Approvals failures come from five avoidable design errors. Each one adds delay without reducing risk.

1. Approver as notification: adding stakeholders as approvers when they only need to be informed. Use watchers instead.
2. Self-approval: letting requesters approve their own requests. Block this with a rule in the workflow engine.
3. Routing by person, not role: naming individuals in rules, which break when people change jobs.
4. No evidence of reasoning: approvals recorded with no comment or risk context, which makes audits slow.
5. Static standard catalogues: pre-approved items that are never reviewed, even after a failed change.

Mistake three causes the most hidden rework. Tie routing to groups and approvals to roles such as "service owner" or "data owner", and keep those role assignments in your directory. Our identity and access management articles explain how to keep role data accurate.

Implementation Checklist

Build or redesign Task Routing & Approvals in this order: inventory, score, route, gate, measure. Following the sequence stops teams automating a broken process.

1. List every request and change type you currently handle.
2. Score each one with the Routing Risk Score and assign it a tier.
3. Add mandatory structured intake fields that your routing rules can match on.
4. Map each type to a resolver group and an approver role, never a named person.
5. Set time limits, delegates and escalation targets for every approval step.
6. Block self-approval and require a comment when an approver rejects.
7. Track reassignment counts, approval wait time and fallback-queue volume.
8. Each quarter, review the standard catalogue and any failed changes.

Task Routing & Approvals FAQ

What is the difference between task routing and approvals?

Task routing decides who does the work, and approvals decide whether the work may go ahead. Routing assigns requests to resolver groups based on structured data. Approvals add authorisation gates whose depth depends on the request's risk.

Does every change need CAB approval?

No. ITIL 4 recognises that many low-risk or standard changes can be approved automatically or by delegated change authorities, as summarised by ITSM.tools. Reserve CAB review for high-risk changes that affect several services.

Should approvals auto-approve after a timeout?

No. Escalate on timeout instead of auto-approving. Auto-approval removes the control the gate exists to provide. Move genuinely low-risk work into a pre-approved standard tier.

How many approval steps should a workflow have?

Use the fewest steps that give real accountability, usually zero to two. Each sequential step adds waiting time. Use parallel approval when two independent checks are needed.

Can CI/CD pipelines act as an approver?

Yes. ITIL 4's Change Authority concept includes automated approval within a CI/CD pipeline, according to ITSM.tools. In that setup, passing tests and policy checks count as the authorisation.

How do I measure whether routing is working?

Track reassignment counts, fallback-queue volume and approval wait time. Frequent reassignment means routing rules are wrong. A growing fallback queue means intake fields are missing.

Keep reading

More from Zero Touch IT:

• More articles and guides
• About us
• Get in touch