Blockers
A blocker is a real-world dependency that prevents an engagement from advancing. Assure Pro tracks them explicitly so the pipeline reflects reality — a card sitting in In review isn’t really “in review” if it’s actually waiting for an IRS letter that hasn’t arrived.
Blockers do two things:
- Visually mark the engagement. A blocker badge appears on the card. The detail page shows the active blockers prominently.
- Gate stage advancement. Strict gates check active blockers before allowing a move. See Stages & gates.
The 5 blocker types
| Type | What it means | Auto-creates when… | Auto-resolves when… |
|---|---|---|---|
| K-1 dependency | This engagement needs a K-1 from another engagement that hasn’t been issued yet. | A pass-through entity (1120-S, 1065) engagement and a partner / owner 1040 are linked via client relationships; the 1040 waits on the K-1. | The pass-through engagement reaches a stage that produces K-1s. |
| Document missing | A specific document on the checklist hasn’t been uploaded. | The intake checklist has unmatched items past their expected date. | The document is uploaded and matched. |
| Payment pending | An invoice tied to this engagement is unpaid. | An invoice is created with status Outstanding. | The invoice is marked Paid. |
| Signature pending | A signing package (engagement letter or 8879) tied to this engagement is sent but not signed. | A signing package is sent. | The signing package is fully signed. |
| Manual | Anything else — IRS notice pending, client travel, internal dependency. Free-form. | You add it explicitly. | You mark it resolved. |
Where blockers show up
| Surface | How |
|---|---|
| Kanban card | Red badge with count: for example, 2 blockers. Hover for the list. |
| Engagement detail page | Top section if any are active. |
| Engagement drawer → Blockers section | Full list with details. |
| Strict-gate move attempt | Dialog: “Can’t move to In review — 1 blocker active”. |
| AI morning brief | Surfaces engagements with active blockers in the “Stuck” group. |
Active vs resolved
Each blocker is either Active or Resolved. The Blockers section of the engagement detail page shows active blockers prominently and resolved blockers in a collapsed “History” group.
A resolved blocker can’t be re-opened — if the dependency returns, create a new blocker. This keeps the timeline truthful (each blocker is a distinct event).
Adding a manual blocker
From the engagement detail page → Blockers section → + Add blocker (or click Add blocker in the engagement’s Quick actions menu).
The dialog asks:
| Field | What goes here |
|---|---|
| Title | ”Waiting on IRS Letter 525 response”, “Client traveling until Apr 5”, “K-1 from outside firm”. |
| Description | Optional longer detail. |
| Expected resolution | Optional date. When set, Assure Pro nudges you on that date to check whether it’s still active. |
| Notify on resolution | If checked, the assignee gets a notification when this blocker is resolved. |
Click Add. The blocker appears in the active list immediately. If the engagement was on a strict-gate stage and the blocker prevents the next move, the strict gate now enforces.
Resolving a blocker
When the dependency is resolved in real life (the IRS letter arrived, the client came back from travel, the outside firm sent the K-1):
- Open the engagement detail page.
- Find the blocker in the Blockers section.
- Click Mark resolved.
- Optionally add a resolution note: “Letter arrived Mar 14, client withdrew claim — closed.”
The blocker moves to the History group. Assure Pro logs the resolution in the activity timeline.
If the blocker was an auto-created type (K-1, Document, Payment, or Signature), the underlying event resolves it automatically — you don’t need to manually mark it.
K-1 dependency blockers in detail
This is the most subtle blocker type. Here’s how Assure Pro handles it:
Setup
- The pass-through entity (S-corp on Form 1120-S, partnership on Form 1065) has an engagement.
- The owners or partners are linked as separate Form 1040 engagements.
- The owners are linked to the entity via a client relationship of type Owner or Partner.
Behavior
- When the 1040 engagement is created, Assure Pro checks: “Does this client have an Owner or Partner relationship to any entity with an open pass-through engagement for the same tax year?” If yes, it auto-creates a K-1 dependency blocker on the 1040 engagement.
- The 1040 can’t pass the strict-gated stage In review (or whichever stage the firm configures) while the K-1 blocker is active.
- When the pass-through engagement advances to a stage flagged as “issues K-1s” (typically Filed or Awaiting signature), Assure Pro resolves all dependent K-1 blockers on linked 1040 engagements.
Override
If the owner’s 1040 doesn’t actually depend on the K-1 (for example, it’s filed on extension and the K-1 comes later, or the owner has $0 from the entity), override the gate with a reason like “owner verified zero pass-through income for 2025”.
Document missing blockers
When the intake checklist has unmatched required items past their expected upload date, Assure Pro creates a Document missing blocker.
| The blocker shows | What it tells you |
|---|---|
| Title: “Missing: 1099-DIV from Fidelity” | The specific document. |
| Description: “Expected by Mar 1, last reminder sent Mar 8” | Timeline context. |
| Source: the intake checklist | Click to open the intake page. |
Resolves automatically when the document is uploaded and AI-matched (or when you manually match it in the intake review queue).
Payment pending blockers
Created when an invoice is sent for this engagement and status is Outstanding. The blocker shows the invoice number and amount due. Resolves automatically when the invoice is marked Paid (either manually or after Stripe confirms the payment cleared).
Some firms don’t want payment status to gate the workflow (for example, payment is collected after filing). Disable per-pipeline at Settings → Pipelines → Gate on payment.
Signature pending blockers
Created when a signing package is sent for the engagement. Shows package title, recipients, and sent date. Resolves automatically when all required signatures are collected.
For multi-signer packages (MFJ — Married Filing Jointly — engagement letters with two signers), the blocker stays active until all required signers have signed. Single-signer packages resolve as soon as the one signer completes.
Notifications
By default, blockers generate notifications:
- On creation → engagement preparer.
- On resolution → engagement preparer plus anyone who subscribed via “Notify on resolution”.
- On stale (no progress for N days, default 7) → engagement reviewer and partner.
Configure per-firm at Settings → Workflow → Blocker notifications.
Stale blockers
A blocker that’s been active longer than the firm’s configured threshold (default 7 days) appears in the Stale blockers report. The report is in:
- Reports → Stale blockers — firm-wide.
- Workflow page → Filter: Stale blockers — kanban or table view showing only engagements with stale blockers.
- The AI morning brief.
Use this to find engagements where the firm is losing time to dependencies that aren’t being addressed.
Common patterns
”Always pending — never gets done”
Engagements that have had a blocker active for 30+ days probably have an undocumented underlying issue (client out of contact, missing info that no one is chasing). The Stale blockers report surfaces them. Move them to On hold until the underlying issue is fixed.
”Cleared the blocker but it came back”
Don’t re-open the old blocker — create a new one with a fresh title. The audit trail is cleaner that way.
”Blocker is real but I want to move the card anyway”
Use a gate override. Add a reason. The blocker stays active (so it’s visible on the engagement) but the move proceeds.
Next
- Stages & gates — how blockers gate stage moves.
- The engagement detail page — where blockers display.
- Relationships — how K-1 dependencies get auto-detected.