Bottleneck Tracking: Where Work Stalls and Why

The Workflow Health tab of Audit Trails answers the operational question the chronology cannot: where is work actually stalling? It reconstructs, from the status-transition rows already in the audit log, how long every study has spent in each state, and it pairs every rejection with the resubmission that followed. It reports — it does not notify: nothing here sends an alert, an email or an SLA breach event.

Where studies stall

Every status transition on a study opens or closes a state span: the time the study sat in one state. Spans are rebuilt from the transition rows each time you open the tab, and the API returns each one with its duration already computed in whole minutes (duration_minutes), which the list renders as 2d 4h. The longest-waiting spans sit at the top of the list.

Field	Meaning
State	The workflow state the study sat in, with its human-readable label
Duration	How long the span ran, in minutes, computed server-side at read time
Entered / Exited	The transition that opened the span and the one that closed it; an open span has no exit
Responsible role	The role that owns the state, read from the state’s role mapping — who the span is waiting on
Status	One badge: At Risk, Active (the study is still in that state), or Closed

The badge shows a single value, and at-risk wins over the other two — a historical span that closed after more than 48 hours reads “At Risk” rather than “Closed”, so check the exit timestamp before concluding the study is still sitting there.

The at-risk rule

A span whose computed duration exceeds 48 hours is flagged at-risk (strictly more than 48h — the constant behind it is BOTTLENECK_ALERT_HOURS). That is the whole mechanism: a boolean on the span, evaluated when the view loads, with no watcher, no reminder and no escalation on top of it. Refreshing the tab re-measures open spans against the current time, which is why an untouched study moves from Active to At Risk on its own. The flag is a status on the span, not a judgment on the study — a busy partner week legitimately produces at-risk sign-off spans, which is why the view pairs duration with the responsible role. The Overview KPI “At-Risk Bottlenecks” is narrower than the list: it counts only at-risk spans that are still active.

The rejection log

Rejections are tracked as cycles, not single events:

• The rejection — every transition into the rejected state, with the rejection reason text as captured on that transition’s justification notes, plus the actor and their role.
• The resubmission — the first later transition out of rejected, paired to the rejection as its resubmission (resubmitted_at on the row). The card itself prints the route, the actor, the reason and the bounce count.
• The bounce count — how many transitions into rejected that study has accumulated. A study with a bounce count of two or three is a pattern, not an accident: the reasons across its bounces are the fix list.

Cycles are newest-rejection-first, and the same actor, study and date filters apply to this list.

Using it to keep the queue moving

1. Work the at-risk list longest first. Each span names its responsible role; escalate or reassign accordingly.
2. Read the bounce counts before the rejections. A study bouncing repeatedly has a recurring defect in the file (usually a disposition or a parameter), and the reasons will repeat — fix the cause, not the symptom.
3. Cross-check against My Tasks. The bottleneck list tells you where the queue is stuck; My Tasks tells you which of those studies are waiting on you.
4. Export the underlying rows when the stall needs to be raised above the team — the ledger export covers the transition and override rows behind these spans.

Reading the numbers together

The two lists answer complementary questions:

• Bottlenecks tell you where work is slow — which state, for how long, and waiting on which role.
• Rejections tell you why work bounces — which studies keep coming back, and with what reasons.

A study that is both at-risk in a state and high on bounce count is the clear priority: it is slow and it is failing review. A study that is at-risk but never rejected is simply waiting — a capacity or priority issue, not a quality one. A study that bounces often but never sits at risk is a quality issue with fast turnaround. Each points at a different fix.

FAQ

Is the workflow tab paginated? No. The list asks the API for the 100 longest spans (the endpoint defaults to 50 and caps out at 500, so this is a window on the worst offenders, not the whole set) and the counter beside the heading reports how many spans exist in total; the rejection list loads in full. The other tabs are server-paginated.

What counts as “time in a state”? From the transition that entered the state to the transition that left it — or, for the state the study currently holds, to now. Timestamps are normalised to UTC before the arithmetic, so stored timezone offsets cannot distort a duration.

Do failed or draft studies appear? A study appears from its first transition; a draft that has not moved yet has no spans until it does. A study left open in a state it no longer holds closes that span at its last recorded transition, so an interrupted history does not produce an infinite span.