Approval Workflows That Do Not Stall: Owner, Deputy, Timer

Wednesday, 11:40, at Meridian Parts. Ruth runs a desk of four and has filtered the queue to tickets in the waiting state. This is where tickets go when the desk has done its part and someone else has not. There are eleven. Four are waiting on Gareth, the operations manager, who owns the warehouse system and is on leave until a week on Monday. Three are waiting on owners who were e-mailed a fortnight ago and have not replied. Two are waiting on nobody, because nobody has been able to say who owns the supplier portal. The oldest is nineteen working days old. Its requester, Amal, has moved into a role she cannot yet do. She has started borrowing a colleague's login to do it. She mentioned this to Ruth in passing as though it were a tip.

An approval workflow is the path a request takes from "asked" to "yes" or "no". It covers who is asked, how they are asked, how long they have, and what happens when they do not answer. It stalls when a ticket sits in the waiting state with nobody's clock running. This happens for four reasons and no others. Nobody knows who decides, the decider is away, the decider is silent, or the decision belongs to a group and therefore to no one. This article is part of our Access & Permission Requests series. It is about the fixes for all four, which are smaller than they sound. They are one owner per resource, a deputy for each, a timer with a chase, and bundles approved in advance for the requests that recur.

It covers where approvals stall, one owner per resource, a deputy for each, and the timer and the chase. Next come pre-approved bundles by role and the approval recorded on the ticket. Then it covers what to do when the tool has no approval step, which is most tools. Self-approval and the emergency follow. A short war story and the approval matrix to copy come last.

Where Approvals Stall

Every stalled approval is one of four kinds. The first job is to say which, because each has a different fix. A desk that treats them all as "waiting" fixes none. The unknown owner stalls at the start. The desk cannot ask because it does not know whom to ask. The ticket waits while someone finds out. Nobody has been asked to do that. The absent owner stalls on a date. The request went to the right person, who is on leave. It will be answered when they return, after everything else in their inbox. The silent owner stalls on attention. The request went to the right person, who is in the building. They have not answered because nothing has happened to make answering urgent. The group decision stalls on structure. Three people have to agree, so each waits for the others, and the request waits for the meeting.

Ruth's eleven tickets sort cleanly. Four are absent, three silent, two unknown. The two waiting on the requester are not stalls at all but a different state. That state should have a different name so that the two kinds do not share a report. Sorting the waiting queue by stall type takes ten minutes and is the first thing to do. It turns "approvals are slow" into four small problems. Each has a fix that fits on a line of a table. The second thing to do is the table.

One Owner per Resource

Every resource that can be requested has exactly one owner, a named person who decides who may use it. The desk keeps the list. The owner is not the desk, not the person who set the resource up, and not "IT". It is the person responsible for what the resource holds or does. That means the finance lead for the finance share, the operations manager for the warehouse system, the head of HR for the personnel folders. Ownership is a role, so the list names the role and the person currently in it. When the person changes the list changes. A resource with no owner cannot be approved. A request for it is the moment to find one.

Build the list from the requests, not from a survey. A survey asking every manager what they own produces a long list of things nobody owns. It also produces a short list of things everybody claims. The requests produce, one at a time, the resources people actually ask for. For each the desk asks "who decides?" until someone says "me" and is written down. Ruth's supplier portal had no owner because nobody had ever been asked. When she asked the purchasing lead whether it was hers, the answer was "I suppose it must be". That is how most ownership begins. Ownership of shared folders in particular, and the folders nobody will own, is a tangle of its own. That is taken up in Shared Folders and the Permission Tangle. The list here is the short one of resources that get requested, and it grows by a line a week.

One owner means one. The temptation to write two or three "so there is always someone" produces the group decision in miniature. In that group, each owner assumes the other will answer. Write one owner and one deputy, which is the next section, and resist the committee. A resource owned by a committee is a resource whose access is decided monthly, if the committee meets. (It does not meet in August.)

A Deputy for Each

Every owner has a named deputy, a second person who may say yes or no on the owner's behalf. The deputy is named in advance, on the list, by the owner. The deputy is not found in a hurry when the owner is on a beach. The deputy is usually the owner's own deputy in the organisation, or the most senior person who uses the resource daily. The rule for the desk is simple. Either name is an approval. Both names are told what was approved. The owner sees on return what the deputy decided. Nothing about the deputy's decision is provisional. An approval that has to be re-approved when the owner returns is not an approval. It is a delay with a signature.

Ask for the deputy at the moment the owner is first recorded, because that is the only moment the owner is thinking about it. "You own the warehouse system; who approves when you're away?" takes ten seconds to answer and saves Amal's nineteen days. Owners who say "nobody, it has to be me" are describing a resource that cannot be requested for two weeks a year. Ask those owners whether they mean that. Most do not, and name someone once the consequence is said aloud. The few who do mean it are describing a resource sensitive enough that a two-week wait is the policy. The desk records that too, so that the requester can be told the truth on day one rather than discovering it on day nineteen.

When both owner and deputy are away, the approval climbs to the owner's manager. The manager may not know the resource but does know the owner's job. Their decision is recorded as a decision made at that level. This is rare, and it is written on the list so that when it happens nobody has to invent it. The list, with its owner, deputy and climb, is the matrix at the end of this article. It is one page for most organisations the size of Meridian.

The Timer and the Chase

A timer is the number of working days an approver has before the desk chases. A chase is what the desk does when the timer runs out. The two together are what turn the silent owner into an answering one. Without a timer, "waiting on owner" is a state a ticket can stay in forever, because nothing happens on any particular day to end it. With a timer, something happens on day two, and something larger on day four. The owner learns, over a few requests, that silence is not a way to make a request go away. The timer runs on the approver. It does not run on the requester, who has done everything asked of them. It does not run on the desk, which is waiting too.

The chase climbs in three steps, and each step is a message to a different person. On the second working day, send a reminder to the owner, short and plain. Restate the request in one line with the question "yes or no?" On the fourth, send the same request to the deputy, with the owner copied, saying the owner has not answered and the deputy may decide. On the sixth, send a note to the owner's manager saying a request for their team has waited six days for a decision. Ask them to nudge or decide. The messages are not angry and are not long. The craft of a chase that gets a reply, as opposed to one that gets filed, is in Follow-Up Messages That Get Replies. The access chase is the same craft with the ask made smaller. "Approve or decline, one word, in reply" is a request a busy person can meet in the time it takes to read it.

Tell the requester what is happening, in parallel, so that they chase the owner from their own side with the same information the desk has. "Your request went to Gareth on Monday. He has until Wednesday before I ask his deputy. You can speed it up by mentioning it to him." That status update recruits the requester into the chase instead of leaving them to chase the desk. Most owners answer a request faster when the person who needs it is standing in their doorway than when the desk e-mails. There is no shame in using that. Whether the service clock keeps running while the ticket waits on an approver is a question tools answer differently. Some pause it; many do not. The honest desk checks its own tool and reports waiting time separately either way. The last article in this series takes that up.

Pre-Approved Bundles by Role

A pre-approved bundle is a set of access that the owners have agreed in advance may be granted to anyone in a named role on the manager's word alone. It removes the approval step from the requests that recur. Every new starter in the drawing office needs the same four things. Every warehouse operative needs the same three. Every accounts clerk needs the same five. Asking the owners to approve each instance is asking them the same question thirty times a year. The thirtieth answer is slower than the first. Asking once, "may anyone in this role have this?", and recording the yes, means the thirtieth request is granted the day it arrives. The manager's confirmation that the person is in the role is then its only approval.

The bundles are the access half of a role profile. The profiles themselves belong to Role Profiles and Standard Kits. That article covers how to pick the handful of roles that cover most starters and what goes in each. This article leans on it rather than repeats it. What the approval workflow adds is the signature. Each bundle has, on the matrix, the owners who agreed to it and the date they agreed. The bundle is re-signed once a year so that an owner who has changed, or a resource that has become more sensitive, can withdraw from it. A bundle nobody has re-signed in three years is an approval given by people who may have left, for resources that may have changed. It is still better than thirty separate stalls, but it is not better than a re-signed one.

Anything outside the bundle is an ordinary request with an ordinary approval. The bundle must not quietly grow to avoid them. When the same exception is requested for the third person in a role, ask the owner to add it to the bundle, with a signature. That is the fix, not granting it on the strength of the previous two. The desk is the only place that sees the third request. That is why the counting of repeat requests, in Measuring Access Requests, is what keeps the bundles current. Bundles are approvals with a long shelf life. They still have a shelf life.

The Approval Recorded on the Ticket

An approval exists when the approver's own words saying yes are on the ticket, under the approver's name, with a date, and in no other case. "Gareth said it was fine" is a claim by the technician. A chat message the technician has seen is a claim with a screenshot. A reply from Gareth in the ticket, or an e-mail from Gareth's address forwarded onto the ticket with its headers intact, is an approval. A stranger reading the ticket in a year can see who said yes without trusting anyone's memory. The standard is not suspicion of the technician. It is the recognition that the technician will not be there to be asked.

Record what was approved as well as who approved it, because owners approve what they were asked and the desk sometimes grants something adjacent. Suppose the request said "warehouse system, picker role". If the grant was "warehouse system, supervisor role, because picker doesn't let her see the stock counts", the approval covers the first and not the second. In that case, the ticket has to show the difference and a second yes for it. A verbal approval, given by phone because the need was urgent, is recorded with the time, the name and the words. The approver is asked to confirm it in the ticket when they can. The record is provisional until they do, and says so. Where the request was declined, the no is recorded exactly as a yes would be, with the owner's reason in the owner's words. The next request for the same thing will want to know why the last one failed.

Keep the approval on the same ticket as the grant where you can, so that the yes and the change sit a few lines apart in one history. Where several owners must each approve a part, some desks open a child ticket per part and link them to the parent. This puts each approval beside the work it authorised. A slow owner then does not hold a fast one. The parent closes when the last child does. If you run QuerySolv, linked tickets and a complete event history on each are already there. In that case, the approver's reply and the technician's change land in order without a separate log. In any tool, the test is whether the yes can be found without opening a mailbox.

When the Tool Has No Approval Step

Most small-team help desk tools have no approval engine, QuerySolv included, and the convention below is what works instead. The convention has four parts. The ticket is put into a waiting state with a name that says what it waits for. That allows approvals to be filtered and counted apart from tickets waiting on requesters or vendors. The approver is brought onto the ticket, as a copied participant or by a public reply addressed to them. That way, their answer lands on the ticket rather than in the technician's inbox. The approver's reply is the approval, under the standard in the previous section. The technician's note records it as such and moves the ticket out of waiting. And the timer is a filter the desk runs each morning for tickets in the waiting-on-approval state older than the chase thresholds. This takes two minutes and replaces the engine's reminder. That is the whole convention. It has run access requests for organisations of several hundred people without anyone missing the engine.

The general version of this, for any approval a desk handles and not only access, is in Approvals Without a Workflow Engine. The software desk's version, where the questions are cost and safety rather than ownership, is in Approvals Without a Committee. The three articles share a shape and differ in who is asked. What an engine adds, where a tool has one, is the automatic reminder and the forced sequence. What it costs is a configuration that somebody has to maintain when the owners change. They do that more often than the engine's maintainer expects. A desk of four is better served by a list it can edit and a filter it runs. That serves it better than an engine it set up two years ago for owners who have since left.

Do not build the approval in a spreadsheet beside the ticket, and do not build it in the technician's mailbox. Both are places the yes can live where the review cannot find it, and both outlive the technician badly. The ticket is where the approval goes because the ticket is where the grant goes. A review that has to join two records will, in practice, read one of them.

Self-Approval and the Emergency

A requester who is also the owner of the resource approves their own request. The ticket says so: "requested and approved by the owner". That is not a loophole. It is the common case for a manager adding a team member to the team's own folders. Asking the manager to find a second approver for their own share is asking for a signature that means nothing. Where the resource is sensitive enough that one person should not grant themselves access to it, payroll, personnel records, the audit log, the matrix says so. It names a second approver, and self-approval is not accepted for that line. Mark those lines. They are few, and they are the ones an auditor will ask about.

The emergency is the request that cannot wait for the timer. It might be a person covering an absent colleague's work from this morning. Or it might be a system that has to be administered during an outage, or a deadline that arrives before the owner does. The emergency path is a phone call to the owner or deputy. It includes a verbal yes recorded with time and name, and the grant made time-boxed and small. The written confirmation is chased on the normal timer afterwards. What the emergency path is not is the desk deciding alone because the owner was slow. The shortcut is to the owner's phone, not around the owner. The pressure to grant more than the emergency needs, and the time-boxed grant that answers it, is the subject of Least Privilege Under Pressure. An emergency is a reason to approve fast. It has never once been a reason to approve nothing.

A Short War Story: The Approver on Leave at Ashgrove Housing

At Ashgrove Housing, a housing officer called Priti moved into the arrears team on a Monday. She asked for the tenancy system's arrears role, which was owned by a service manager called Malcolm. He had gone on three weeks' leave the Friday before and had no deputy on any list the desk held. The ticket sat in waiting for nineteen working days, with two reminders to an unread mailbox. Meanwhile Priti, who had letters to send, used a colleague's login. The colleague had written it on a card in the drawer for exactly this purpose. When Malcolm returned he approved the request in four minutes. The following quarter's audit found two hundred and twelve arrears letters issued under a name. That name had been on leave for one of the weeks the letters were sent. The arrears team spent about forty hours reconciling who had actually done what. Meanwhile the desk spent a day explaining why a request approved in four minutes had taken nineteen days. The deputy line on the matrix was added the same week, with Malcolm's deputy named by Malcolm. An approval that rests on one name and no second name is not a workflow. It is a stall waiting for a holiday.

The Approval Matrix

The matrix below is the one Ruth built from her eleven stalled tickets. It has one row per requestable resource. Each row has the owner, the deputy, what is pre-approved for which roles, the timer, and where the chase climbs. Fill it from the requests as they arrive rather than from a survey. Keep it where the whole desk can see it. Change a row the day its owner changes. The second block is the chase schedule. It is the same for every row unless a row says otherwise. The third is the short list of resources where self-approval is not accepted. One page is the right length. A matrix that needs a second page has resources on it that nobody has ever requested.

ACCESS APPROVAL MATRIX — ONE PAGE
Desk: ______________   Kept by: ______________   Last reviewed: ____________

RESOURCES (one row each; add a row the first time something is requested)
  Resource                 Owner (role / name)     Deputy             Pre-approved for roles        Timer
  _______________________  ______________________  _________________  ____________________________  __ days
  _______________________  ______________________  _________________  ____________________________  __ days
  _______________________  ______________________  _________________  ____________________________  __ days
  _______________________  ______________________  _________________  ____________________________  __ days
  _______________________  ______________________  _________________  ____________________________  __ days

PRE-APPROVED BUNDLES (the access half of each role profile)
  Role: ______________   Includes: ______________________________   Signed by: __________  On: ________
  Role: ______________   Includes: ______________________________   Signed by: __________  On: ________
  Bundles are re-signed every ____ months. Anything not in the bundle is an ordinary request.

THE CHASE (working days after the request reached the approver)
  Day __ : reminder to the owner, request restated in one line, "approve or decline?"
  Day __ : same request to the deputy, owner copied; the deputy may decide
  Day __ : note to the owner's manager: a decision for their team has waited __ days
  The requester is told at each step who is being asked and when.

WHAT COUNTS AS AN APPROVAL
  [ ] the approver's own words, on the ticket, under their name, with a date
  [ ] a forwarded e-mail from the approver's address, headers intact
  [ ] a verbal yes: time, name and words recorded; written confirmation chased on the timer
  Not an approval: "they said it was fine"; a chat message nobody forwarded; silence.

SELF-APPROVAL NOT ACCEPTED FOR (a second approver is named here)
  Resource: ______________   Second approver: ______________
  Resource: ______________   Second approver: ______________

Ruth's matrix had fourteen rows by Friday. Each was added when a ticket named the resource. The supplier portal had an owner by Thursday afternoon. The owner named a deputy in the same sentence. The four tickets waiting on Gareth went to his deputy under the new day-four rule. They were decided the same day. Amal stopped borrowing logins, which she had never wanted to do. The oldest ticket in the waiting state the following month was six working days old. It was waiting on a requester, which is a different queue and a different problem.

Frequently Asked Questions