# A document is stuck in — or skipped — approval

Work out which of three states a misbehaving document is in — never started approval, waiting on one step, or finished but still in a queue — and fix the one that applies.

Product: content-central · Versions: 7.x · Audience: catalog-administrator · Time: 20 minutes · Last verified: 2026-08-30

Canonical: https://help.ademero.com/content-central/workflow/document-stuck-in-approval

**By the end of this guide you'll know which of three states your document is in — it never entered approval, it's waiting on one step, or it's finished but still showing in a queue — and you'll have fixed the one that applies.**

> **NOTE:** Work the states in order. "Skipped approval" and "stuck in approval" usually come down to the same few causes, and the first check rules out the most common one in under a minute.

## First: where is the document right now?

Open **Queues** from the sidebar. The four tabs — **Approval**, **Work**, **Signature**, **Coding** — each show a count badge.

| Where the document is | What it means | Go to |
| --- | --- | --- |
| **Coding** tab | Not filed yet — approval hasn't started, and that's normal | State 1 |
| Filed, but on nobody's **Approval** tab | The approval process never started | State 1 |
| **Approval** tab, not moving | Waiting on a specific person or group | State 2 |
| **Work** tab, long after the work was done | A work-queue item that never expires | State 3 |

## State 1: The document never entered approval

Approval processes attach to **filed** documents. A Coding Queue item is a temporary holding record — its pre-assigned approval processes attach only at the moment it's committed to the catalog, so it will never appear in anyone's Approval Queue before then. When an invoice "bypasses approval," the process almost always never started: the document was filed as a type the process isn't attached to, or the process isn't set to start automatically.

1. Confirm the document is filed (not on the **Coding** tab) and note its **document type** — the type it was actually filed as, not the one you expected.

2. In catalog administration (**Catalogs & Document Types**), open that document type's actions menu and choose **Approval Processes**.

3. On the **Approval Processes** page, find the process and confirm **Enabled** is checked. A disabled process routes nothing.

4. Open **Edit Details** and check the box labeled **Automatically start this process on all captured content of this document type**.
   If it's unchecked, documents enter this process only when someone starts it manually or a workflow rule starts it.

*[Screenshot: Approval-Process Details page with the "Enabled" and "Automatically start this process on all captured content of this document type" checkboxes highlighted]*

5. To route the skipped document now, open it and use **Start Approval Process**: pick the **Assignment Type**, **Assign to**, and **Priority**, then click **Start Process**.
   
   **What you should see:** if the dialog instead says `No approval processes are configured for this document type`, the document was filed under a type with no process at all — that's your mismatch.

**Success check:** the document appears on the first approver's **Approval** tab, and the next document of this type filed from the Coding Queue enters approval on its own.

> **IMPORTANT:** Sending a document to a work queue during coding is a separate routing choice, not an approval substitute. A document can be in an approval process, a work queue, both, or neither.

## State 2: It's in approval, but not moving

1. On the **Queues** page, click **Admin** to open the **Admin Queue** — it shows items across all users for the document types you administer.

2. Find the document and use **View History** to see which member (step) it's waiting on.

3. Work out who that member really is:
   
   | Member type | Who's holding it |
   |---|---|
   | Named **User** | That one account — confirm it's still active |
   | **Group** | Depends on mode: **Multi** (all members see it; voting rules decide advancement), **Single** (one chosen member), **Review** (two peer-reviewers) |
   | **Creator** | Whoever created the document |
   
   > note: A Multi group whose voting rule requires **all** members stalls completely when one member is away or has left the company.

4. If the current assignee can act, the fastest fix is for them to approve or reject the item. Seeing `Comments are required for rejection.`? That's expected — add the note.

5. If the assignee can't act (deactivated, departed, on leave), select the item in the **Admin Queue**, use **Remove from Process**, then reopen the document and run **Start Approval Process** again, assigning it to someone who can act.

**Success check:** **View History** shows the item moved past the member it was stuck on, or the restarted process appears on the new assignee's **Approval** tab.

> **IMPORTANT:** If items keep landing on someone who has left, fix the process itself — edit it and adjust the member list (**Remove Member**) — or every future document will stall in the same place.

## State 3: The work is done, but items keep piling up

An approval item leaves the queue on its own when it passes the last member, is rejected off-process, or is removed. Lingering leftovers are usually on the **Work** tab, where expiration rules apply.

1. Check the **Work** tab's **Expiration** column. Items assigned with the **Never expires** switch on stay until someone completes or removes them — over time they accumulate.

2. For an item that should have a lifespan, use **Set Expiration** in the **Admin Queue** and give it an **Expiration Time** and **Expiration Interval** (Minute through Year).

3. When an item's expiration elapses, the system removes it automatically and silently — there's no notification. If the document is also in an approval process, the approval is unaffected.

> **NOTE:** Group-assigned work items appear to every group member, and the first person to complete one removes it for the whole group. "Stuck for me" is sometimes just "not completed by anyone yet."

**Success check:** items with expirations set disappear from the **Work** tab on their own, and the tab's count badge stops growing.

## Years of old items? Don't bulk-clean it yourself

**Remove from Process** and **Set Expiration** act on items you select — fine for a handful. Safely filtering years of accumulated never-expiring items into "dead" versus "still mid-flight" is hard to get right, and removals can't be undone from the queue. Treat a large historical cleanup as a scoped job: contact Ademero support to arrange it rather than selecting-all in the **Admin Queue**.

> **WARNING:** Removing an item from a process can't be undone from the queue — the process must be restarted from the document. Never bulk-remove items you haven't individually confirmed are dead.

## Still stuck?

Contact support with this — it's exactly what they need to pick the issue up quickly:

- [ ] Catalog name and the **document type** one affected document was actually filed as
- [ ] The **process name**, and whether **Enabled** and the auto-start checkbox are checked
- [ ] Which tab the document shows on (**Approval**, **Work**, **Coding**) — or none
- [ ] The **View History** output for one example document
- [ ] When it started, and what changed around then (new document type, staff change, process edit)

## What's next

- [A scheduled workflow didn't run](https://help.ademero.com/content-central/workflow/scheduled-workflow-didnt-run)
- [I can't find my document](https://help.ademero.com/content-central/search-and-find/cant-find-a-document)