How long approvals really take

Where do requisitions sit, and on whose desk? The tenant purges the tasks before the question gets interesting, and offers no delivered answer even inside the window. With the events in a table you own, every version of the question is one query.

RuleMeasure elapsed time per step from stored approval events, and read bottlenecks from the data instead of from opinions.

Nevermeasure cycle time from a system that purges its tasks after 30 days. A truncated sample flatters every slow step.

◆ The questions nobody can answerrecurring requests, no delivered report.

Approver-wise elapsed time on requisitions is a recurring request on the community forums, and the answers on offer are workarounds. The tenant keeps tasks in the approval screens for 30 days after last update, then purges them, as the previous page documents. Even inside the window there is no delivered analysis of time per step, time per approver, or where documents queue.

So procurement leaders know the total feels slow, and nobody can say which desk is slow. The difference between those two statements is the difference between a complaint and a fix.

◆ One query awaya worked example of time per step.

Approval step, one requisition, illustrative	Elapsed days
Submission to cost center manager	0.5
Cost center manager to category owner	1.5
Category owner review	4.5
Finance final approval	2.5
Submission to fully approved	9.0

Sample values are illustrative, never client data. The point of the table is what it makes visible: one step holds the document half the total time. Averaged across a quarter of requisitions, that step is a named bottleneck with a number attached, not a rumor.

◆ Built on the owned factthe same table that beat the purge.

Everything here reads from the approval-event fact the foundation page describes: every task action, extracted continuously, retained forever. Time per approver is a difference of timestamps. Bottleneck steps are a group-by. Aging of in-flight approvals is a filter on tasks with no terminal event yet, which is the report that finds the requisition sitting quietly on a desk today.

-- average days per approval step, last quarter
SELECT step_name, AVG(elapsed_days) AS avg_days
FROM fct_approval_step
WHERE document_type = 'requisition'
  AND submitted_date >= DATE '2026-04-01'
GROUP BY 1 ORDER BY 2 DESC

None of this is exotic analytics. It is ordinary reporting on events the source refuses to keep, which is why owning the events is the whole build.

Use case

Problem

Approval cycle time cannot be measured in the tenant: tasks purge after 30 days and there is no delivered time-per-step analysis even inside the window.

What we build

Cycle-time marts on top of the owned approval-event fact: time per approver, step bottlenecks, and aging of every in-flight approval.

What you get

A named bottleneck with a number attached, refreshed daily, plus an aging list of exactly which documents are stuck and where.

Which approval step costs you the most days?

We build the cycle-time marts that answer it from events you own.

Talk to us

Terms on this page

ERP: Enterprise resource planning, the system of record for operations and finance.
approval event: One recorded action on a task: submitted, approved, rejected, escalated.
cycle time: Elapsed time from submission to final approval.
bottleneck: The step holding documents longest. Found by measuring, not voting.
in-flight: Submitted but not yet fully approved or rejected.
fact table: A warehouse table of events or measurements, one row each.
aging: How long each open item has been waiting, banded by days.
mart: A small purpose-built reporting table on top of the facts.