Which Workday approvals are sitting unanswered, and why nobody can see them

It is the fourth business day of the month. The HR operations manager has a list of eleven requisitions that were supposed to be posted last week and are not posted, because each one is waiting on a step somebody has not clicked. She opens Workday, filters business processes by status, and gets a clean table: process name, initiator, current step, assigned approver, days in step. Eleven rows. Three of them have been sitting for nine days with the same VP's name in the approver column.

She opens Gmail next, because she already knows what the table does not tell her. She searches the VP's name. There is a thread from eight days ago where the VP replied to the hiring manager: "Hold this one until we know whether the Q3 headcount plan survives the reforecast. I'll approve as soon as finance confirms." There is a second thread on a different requisition where the VP wrote "approved, go ahead" in plain English to the recruiter and never went into Workday to press the button. And there is a third where nobody has said anything at all, and the VP has been out on leave since the 22nd.

Three rows that look identical in Workday. Three completely different situations. The only place the difference is written down is in email, and the only person who knows all three is the person who has just spent forty minutes reading threads to reconstruct it.

What Workday shows on its own

Workday is precise about the mechanics of an approval, and it is genuinely good at this. A business process instance carries its definition, its current step, the security group or named person the step is routed to, the timestamp of every transition, and any comment typed into the Workday comment box. Reports on business process transactions will tell you exactly how many days an item has been in its current step. Delegation rules, if configured, will tell you who inherits a step when the assignee is out.

Where it stops is not a gap in the reporting. It is a boundary in what the system is a record of. Workday records what happened in Workday. A step that has not been actioned is, from the system's point of view, a single fact: not actioned, since this timestamp. There is no field that distinguishes "deliberately held pending a finance decision" from "verbally approved but the button was never pressed" from "the approver has not opened the notification". Those are three different reasons, and Workday holds none of them, because the reasons were never typed into Workday.

You can push back and say the comment box exists. It does, and where people use it, it is the single most useful field in the whole record. In practice most approvers reply to the email notification instead of clicking through into the system, because replying is four seconds and clicking through is a login and three screens. The reasoning ends up in the reply, not the record.

What Gmail shows on its own

Gmail has the reasoning. Search from: the VP for the last two weeks and you can read exactly what she thinks about each of these. The intent is written in full sentences, dated, attributable, and often more specific than anything a structured field would have captured. "Hold until finance confirms" is more useful than any status value Workday could offer.

What Gmail does not have is the population. Search cannot tell you which approvals exist. It can only tell you about the ones you already thought to search for. There is no query in Gmail that returns "requisitions with a pending Workday step", because Gmail has no idea what a requisition is. The Workday notification emails are in there, but they are notifications of an event at a moment in time, not a current state: an email saying "awaiting your approval" sent nine days ago says nothing about whether the item was approved on day two.

And the reasoning is scattered by the shape of email rather than by the shape of the work. The hold instruction went to the hiring manager. The verbal approval went to the recruiter. Neither thread is in the HR operations manager's inbox at all unless someone thought to copy her, which is exactly why she is searching rather than reading.

Why the gap is structural, not a missing feature

Half the evidence here is a record and half of it is a sentence somebody wrote.

The record half is well behaved. A business process instance has an ID, a definition, a state, an assignee and a set of timestamps. It is queryable because it was designed to be queried. Every fact about it fits in a column.

The sentence half was never designed at all. "Hold this one until we know whether the Q3 headcount plan survives the reforecast" has no ID, no state field, and no relationship to anything except through the fact that a human reading it recognises which requisition it means. It is evidence, and it is the decisive evidence, and it exists only as prose.

This is why the two halves stay apart, and it is worth being precise about which tools fail at which half.

Automation platforms are trigger based and they are excellent at that job. A Zap or a Make scenario fires when something happens and moves the work forward: notification sent, record updated, Slack message posted. That design is what makes them reliable, and it is also why they cannot answer this question. There is no trigger for "has been sitting for nine days for a reason nobody logged". The question is about accumulated state, asked at an arbitrary moment, about things where the notable property is that nothing happened.

BI tools fail for a different and equally structural reason. Power BI Copilot and Looker Conversational Analytics both handle natural language well, and both would happily give you the pending approvals table with day counts if Workday is in the warehouse. But the VP's email is not a modelled source. It is not in the semantic layer, it is not in a table, and there is no version of a BI tool where it could be, because a sentence in somebody's inbox is outside the class of thing these tools connect to at all. The answer is not hard for them to compute. Half the evidence is invisible to them.

What the join actually requires

The key is thinner than you would like. In the good case the Workday notification email carries the business process instance ID or the requisition number in the subject line, and any reply inherits that subject, so the thread is joinable on an exact string. That covers reply-to-notification, which is a large share of real approver behaviour.

The rest joins on softer signals. Sender and recipient identity match the Workday assignee and initiator. Message dates fall inside the window the step has been open. And the requisition is often referred to by its job title and hiring manager rather than by number: "the senior backend role for Priya's team" is the thread you need, and no string match will find it.

Then there is the judgement call, which is the part that cannot be a rule. Given a matched thread, someone has to read it and decide what it means for the pending step. "Approved, go ahead" from an approver to a recruiter means the step is stuck on an unclicked button and the fix is thirty seconds. "Hold until finance confirms" means the step is not stuck at all, it is correctly waiting, and chasing it wastes everyone's time. Silence plus an out of office auto-reply means the delegation rule did not fire. Those three call for three different actions, and the difference is entirely in the reading. A keyword rule for "approved" would mark the hold thread as approved, because it contains the words "I'll approve as soon as".

How you would answer it with Skopx

Skopx connects to Workday and Gmail among nearly 1,000 integrations, so both halves are readable in one place. The realistic sentence someone types in chat is close to how they would say it out loud:

"List every Workday approval step that's been pending more than 5 days, and for each one check Gmail for anything the approver or hiring manager has said about it. Tell me which ones are genuinely blocked, which ones have a verbal approval nobody clicked, and which ones nobody has responded to at all."

What comes back is the eleven rows, each with the Workday facts, the relevant email quoted with a link to the thread, and a read of what the message means for that step. Every claim carries its citation, so when the answer says a requisition was verbally approved, you can click through and see the sentence rather than trusting the classification.

Ask it once and you have your morning back. Ask it every week and you would rather not retype it, which is where a standing console over the same question is the better shape. Described in a sentence in chat, an internal app built on this pair would show the pending approvals as a live list, each row carrying its day count, its approver, the quoted email evidence, and a category: verbally approved, deliberately held, or no response. Filters by approver and by age. The single action available on a row is a button that sends a chase message to the approver, with a confirmation step before it goes.

That is the whole scope of the write. It reads Workday, it reads Gmail, and one button sends one message when a person clicks it.

Honest limits

The console does not approve anything in Workday. It shows you what is waiting and why, and the approval itself stays in Workday where the audit trail belongs.

It stores nothing. There is no new database of approval reasons and no record created anywhere. Every load reads both systems fresh, which means it is always current and also means there is no history in it: it cannot tell you how this looked last Tuesday.

It does not watch or alert. Nothing runs on a schedule, nothing fires when an approval crosses a threshold, and nothing arrives in your inbox unprompted. Somebody opens it and looks.

The categorisation is a reading, not a fact, and readings are sometimes wrong. Ambiguous threads get classified with a shrug, and the reason the email is quoted directly on every row is so you can overrule it in two seconds.

It only sees email the connected account can see. Approval reasoning that happened in a Slack DM, in a meeting, or in a thread nobody was copied on is invisible, exactly as it is to you today. And it will miss threads where the requisition is referenced in a way no key matches and no phrasing suggests, though those tend to be the same ones a human search misses too.

Skopx is $16 per seat per month on Team, including 2.3 million AI tokens per seat, and $5 on Solo. SOC 2 controls are in place.