[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fDequ5nlIMQMcpRRHHco0ptkTCHyOnbMl93_OZVO0co8":3},{"item":4},{"id":5,"idKnowledge":6,"idDomain":7,"idCluster":8,"kindOverride":9,"slug":10,"title":11,"description":12,"bodyMarkdown":13,"bodyHtml":14,"author":15,"date":16,"createdAt":17,"topics":18,"image":26,"hasDownload":27,"fileName":9,"youtubeId":26,"domainCrumb":28,"clusterCrumb":31},"155","465107BA-AD29-544E-AC18-CC7175FB40F0","B5C0C140-5201-C54B-9B13-F29BA94F42E7","C92B8C4B-2D51-5743-A1D1-0B229521D4E6","","how-to-document-exceptions-without-making-a-process-unreadable","How to document exceptions without making a process unreadable","Exceptions belong in your process documentation — but add too many and the map becomes useless. Here's how to capture them at the right level.","Your process documentation looks complete on paper. Every step is mapped, every role is labeled, every handoff is drawn with a neat arrow. Then someone asks: \"But what happens when a customer sends a partial PO?\" or \"What do we do when a supplier ships the wrong quantity?\" Suddenly the map has seventeen sticky notes around it and nobody trusts it anymore. This article shows you how to document process exceptions in a way that actually helps your team — and doesn't turn a clear workflow diagram into an unreadable wall of edge cases.\n\n## Why exceptions break most process maps\n\nMost process maps are built around the *happy path* — the sequence of steps that works when everything goes right. That's fine as a starting point, but real business operations run on exceptions. An order comes in without a PO number. A new employee starts before IT has set up their accounts. A production batch fails quality control at the last step. These aren't rare events; they happen every week, sometimes every day.\n\nThe instinct is to document every one of them inside the main process map. The result is a BPMN diagram with forty decision diamonds, eight swimlanes, and color-coded exception paths that nobody outside the project team can read. The map becomes technically complete and practically useless — it doesn't help a new employee understand the flow, and it doesn't give a developer a clear picture of what to automate.\n\nThe opposite mistake is just as damaging: ignoring exceptions entirely, mapping only the happy path, and assuming the edge cases can be \"handled later.\" Later usually means: after the automation is already built, when fixing it costs ten times more.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F107?w=700&f=webp\" alt=\"process map happy path branching into exception lanes, becoming cluttered and unreadable\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## What counts as an exception — and what doesn't?\n\nBefore you can document exceptions well, you need to agree on what an exception actually is. A useful working definition:\n\n> **An exception is any situation where the standard process cannot continue without a human judgment call or a different sequence of steps.**\n\nUnder that definition, a lot of things people call exceptions are actually just *variants* — legitimate, predictable variations in the process that happen often enough to be part of the standard flow. The distinction matters:\n\n- **Variant (document in the main map):** A customer orders via EDI instead of the web portal. The order-to-invoice process is slightly different, but it's a known, structured path that happens hundreds of times a month.\n- **Exception (document separately):** A customer sends a handwritten fax order with a missing delivery address. This requires manual intervention, happens rarely, and following a rigid step-by-step process isn't the point — judgment is.\n\nIf something happens more than roughly 10–15% of the time, it probably belongs in the main flow as a named variant, not as an exception branch. If it happens once a month and requires a supervisor's sign-off, document it separately.\n\n## The three-tier documentation model\n\nThe most practical way to keep process maps readable while still capturing exceptions is to work in three tiers:\n\n**Tier 1 — The overview map (1 page)**\nThis shows the end-to-end flow at a high level: the major stages, the key roles, and the main decision points. No exception handling here. This is what you show a new manager or a C-level stakeholder. For an order-to-invoice process, it might show: Order received → Order validated → Production\u002Ffulfillment → Invoice sent → Payment received. Five to eight steps, maximum.\n\n**Tier 2 — The working process (per stage)**\nEach stage from Tier 1 gets its own detailed map. Here you include variants — the predictable alternative paths that staff encounter regularly. For the \"Order validated\" stage, you'd show what happens when a credit check fails, or when the customer is a new account without a credit history. These are expected variations, not surprises.\n\n**Tier 3 — The exception register (a separate document)**\nThis is where genuine exceptions live — not in the process map itself, but in a linked register. Each entry names the exception, describes the trigger (what makes this situation recognizable), assigns an owner, and describes the resolution path. It's more like a decision table or a runbook than a flowchart.\n\nExample row in an exception register for a production\u002Finventory workflow:\n\n| Exception | Trigger | Owner | Resolution |\n|---|---|---|---|\n| Supplier delivers wrong SKU | Goods receipt item doesn't match PO line | Warehouse manager | Hold receipt, raise supplier deviation, notify purchasing |\n| Batch fails QC at final inspection | QC rejection flag in production system | Quality lead | Quarantine batch, initiate rework order or write-off |\n\nThis keeps the Tier 2 process maps clean while giving the people who handle exceptions a practical, findable reference.\n\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F106?w=700&f=webp\" alt=\"three-tier diagram: overview map, detailed stage maps, exception register as linked document\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n## How to decide which tier an exception belongs in\n\nUse these four questions as a filter:\n\n1. **How often does it happen?** More than once a week in a team of ten? It probably belongs in Tier 2 as a variant. Once a month or less? Tier 3.\n2. **Is the resolution steps-based or judgment-based?** If there's a clear sequence of actions to take, document the steps. If it requires someone to evaluate the situation and decide, document the owner and the outcome criteria — not the steps.\n3. **Does it affect the main process timeline or output?** If an exception can silently delay an invoice by three days without anyone noticing, it needs to be visible in the Tier 2 map as a branch, not buried in a register.\n4. **Is it automation-relevant?** If you're mapping this process to automate it, any exception that the system needs to handle — even rarely — must be explicitly documented before development starts. A developer who doesn't know about partial PO handling will build a system that breaks on the first partial PO.\n\n## A step-by-step approach to documenting exceptions without derailing your process mapping session\n\nProcess mapping workshops have a well-known failure mode: someone raises an edge case, the group spends forty minutes debating it, and you leave the room with one half-finished diagram and a long list of unresolved questions. Here's how to avoid it:\n\n1. **Start with the happy path only.** Run through the process end-to-end as if everything goes right. Get this on paper first, agreed and signed off, before you touch a single exception.\n2. **Open a \"parking lot\" for exceptions.** When someone says \"but what if the customer doesn't have a VAT number,\" write it on a sticky note or in a separate column of your working document. Don't stop the happy-path walkthrough.\n3. **After the happy path is complete, triage the parking lot.** Go through each item and decide: variant (add to Tier 2 map), exception (add to exception register), or out of scope for this process.\n4. **For each exception in the register, assign an owner immediately.** Undocumented ownership is why exceptions stay unresolved for years. If nobody owns it now, nobody will own it after the automation goes live either.\n5. **Review the exception register with the people who actually handle the exceptions** — not just the process owner or the project manager. The warehouse manager who deals with wrong-SKU deliveries three times a week will tell you things the ERP system log never will.\n6. **Set a review cadence.** Exceptions evolve. A supplier issue that was exceptional two years ago might now be a weekly occurrence because you changed your sourcing. Build a quarterly review of the exception register into your process governance.\n\n## The onboarding process example: where exceptions hide in plain sight\n\nOnboarding is a process where exception documentation failures are especially visible — and expensive. The happy path looks clean: new employee signs contract → HR sends welcome email → IT creates accounts → manager assigns first tasks → employee starts day one.\n\nIn practice, a technology company with fifty new hires a year might deal with situations like:\n- The employee starts before the signed contract is returned (common in competitive hiring markets)\n- The laptop ordered four weeks ago hasn't arrived yet\n- The new hire is a contractor, not an employee, so half the standard onboarding steps don't apply\n- The manager is on holiday the week the person starts\n\nNone of these are in the happy path. All of them happen regularly. The question isn't whether to document them — it's *where*. The contractor variant probably belongs in a Tier 2 parallel flow (it happens 20% of the time). The delayed laptop is a Tier 3 exception (it has a clear owner: IT, and a clear resolution: temporary equipment policy). The absent manager is a governance issue that the exception register should name an escalation path for.\n\nDocumenting these correctly before you automate onboarding — say, by building a self-service onboarding portal or connecting your HRIS to IT provisioning — is what separates an automation that works from one that fails on week two.\n\n## Checklist: Is your exception documentation at the right level?\n\nBefore you hand off a process map to a developer, an automation tool, or an ERP implementation team, run through this:\n\n- [ ] The main process map shows only the standard flow and high-frequency variants — no more than 2–3 decision branches per stage\n- [ ] Every exception that requires a human judgment call is in a separate exception register, not in the main diagram\n- [ ] Each exception has a named owner, a trigger description, and a resolution path\n- [ ] Exceptions that affect the automated system's behavior (even rarely) are explicitly flagged for the development team\n- [ ] The exception register has been reviewed by the people who actually handle the exceptions — not just the process designer\n- [ ] A review cadence for the exception register is agreed and calendared\n- [ ] You can explain the main process flow to a new employee in under five minutes using only the Tier 1 map\n\n## FAQ\n\n**Should exceptions be in the same tool as the main process map?**\nNot necessarily. The main map might live in a diagramming tool like Lucidchart or draw.io, while the exception register works perfectly well as a structured table in Confluence, Notion, or even a shared spreadsheet. What matters is that they're explicitly linked — the process map should reference the exception register, and each exception entry should reference the relevant process stage.\n\n**How do I handle exceptions that are really just workarounds for a broken process?**\nDocument them, but flag them explicitly as \"process debt.\" An exception that exists because the ERP system can't handle split deliveries isn't a true business exception — it's a system limitation masquerading as one. Documenting it makes the problem visible and gives you a prioritized list of things to fix when you do rebuild or automate.\n\n**What if the exception register grows to fifty rows? Is that too many?**\nFifty exceptions across a complex end-to-end process (like order-to-cash across multiple product lines and geographies) is not unusual. The problem isn't the number — it's whether they're properly owned and triaged. If you have fifty exceptions and twenty of them have no owner, that's a governance problem. If they're all owned, reviewed, and prioritized, fifty rows is just operational reality well-documented.\n\n**Do exceptions need to be in scope for a process automation project?**\nYes — or explicitly out of scope with a documented decision. \"We will not automate this exception; it will continue to be handled manually\" is a valid choice, but it needs to be a conscious, recorded decision, not an oversight. Undocumented out-of-scope exceptions are where automation projects quietly fail in production.\n\n**How detailed should an exception entry be?**\nEnough that someone encountering the situation for the first time knows what to do without having to ask. That usually means: one sentence describing the trigger, one sentence describing the resolution, and a named owner. Anything longer is probably a separate mini-process, not an exception entry.\n\n---\n\nIf you're working through a process improvement or automation project and finding that your documentation keeps collapsing under the weight of its own exceptions, that's often a sign that the underlying process design — not just the documentation — needs attention. Loggix works with businesses to map, clarify, and where appropriate automate processes in FileMaker, custom web applications, and connected systems. Whether you need a structured mapping engagement before a development project or a second opinion on where your process boundaries should sit, that's exactly the kind of work we do.","\u003Cp>Your process documentation looks complete on paper. Every step is mapped, every role is labeled, every handoff is drawn with a neat arrow. Then someone asks: "But what happens when a customer sends a partial PO?" or "What do we do when a supplier ships the wrong quantity?" Suddenly the map has seventeen sticky notes around it and nobody trusts it anymore. This article shows you how to document process exceptions in a way that actually helps your team — and doesn't turn a clear workflow diagram into an unreadable wall of edge cases.\u003C\u002Fp>\n\u003Ch2>Why exceptions break most process maps\u003C\u002Fh2>\n\u003Cp>Most process maps are built around the \u003Cem>happy path\u003C\u002Fem> — the sequence of steps that works when everything goes right. That's fine as a starting point, but real business operations run on exceptions. An order comes in without a PO number. A new employee starts before IT has set up their accounts. A production batch fails quality control at the last step. These aren't rare events; they happen every week, sometimes every day.\u003C\u002Fp>\n\u003Cp>The instinct is to document every one of them inside the main process map. The result is a BPMN diagram with forty decision diamonds, eight swimlanes, and color-coded exception paths that nobody outside the project team can read. The map becomes technically complete and practically useless — it doesn't help a new employee understand the flow, and it doesn't give a developer a clear picture of what to automate.\u003C\u002Fp>\n\u003Cp>The opposite mistake is just as damaging: ignoring exceptions entirely, mapping only the happy path, and assuming the edge cases can be "handled later." Later usually means: after the automation is already built, when fixing it costs ten times more.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F107?w=700&f=webp\" alt=\"process map happy path branching into exception lanes, becoming cluttered and unreadable\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-left sm:mr-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>What counts as an exception — and what doesn't?\u003C\u002Fh2>\n\u003Cp>Before you can document exceptions well, you need to agree on what an exception actually is. A useful working definition:\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>An exception is any situation where the standard process cannot continue without a human judgment call or a different sequence of steps.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Cp>Under that definition, a lot of things people call exceptions are actually just \u003Cem>variants\u003C\u002Fem> — legitimate, predictable variations in the process that happen often enough to be part of the standard flow. The distinction matters:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Variant (document in the main map):\u003C\u002Fstrong> A customer orders via EDI instead of the web portal. The order-to-invoice process is slightly different, but it's a known, structured path that happens hundreds of times a month.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Exception (document separately):\u003C\u002Fstrong> A customer sends a handwritten fax order with a missing delivery address. This requires manual intervention, happens rarely, and following a rigid step-by-step process isn't the point — judgment is.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>If something happens more than roughly 10–15% of the time, it probably belongs in the main flow as a named variant, not as an exception branch. If it happens once a month and requires a supervisor's sign-off, document it separately.\u003C\u002Fp>\n\u003Ch2>The three-tier documentation model\u003C\u002Fh2>\n\u003Cp>The most practical way to keep process maps readable while still capturing exceptions is to work in three tiers:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Tier 1 — The overview map (1 page)\u003C\u002Fstrong>\nThis shows the end-to-end flow at a high level: the major stages, the key roles, and the main decision points. No exception handling here. This is what you show a new manager or a C-level stakeholder. For an order-to-invoice process, it might show: Order received → Order validated → Production\u002Ffulfillment → Invoice sent → Payment received. Five to eight steps, maximum.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Tier 2 — The working process (per stage)\u003C\u002Fstrong>\nEach stage from Tier 1 gets its own detailed map. Here you include variants — the predictable alternative paths that staff encounter regularly. For the "Order validated" stage, you'd show what happens when a credit check fails, or when the customer is a new account without a credit history. These are expected variations, not surprises.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Tier 3 — The exception register (a separate document)\u003C\u002Fstrong>\nThis is where genuine exceptions live — not in the process map itself, but in a linked register. Each entry names the exception, describes the trigger (what makes this situation recognizable), assigns an owner, and describes the resolution path. It's more like a decision table or a runbook than a flowchart.\u003C\u002Fp>\n\u003Cp>Example row in an exception register for a production\u002Finventory workflow:\u003C\u002Fp>\n\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Exception\u003C\u002Fth>\n\u003Cth>Trigger\u003C\u002Fth>\n\u003Cth>Owner\u003C\u002Fth>\n\u003Cth>Resolution\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Supplier delivers wrong SKU\u003C\u002Ftd>\n\u003Ctd>Goods receipt item doesn't match PO line\u003C\u002Ftd>\n\u003Ctd>Warehouse manager\u003C\u002Ftd>\n\u003Ctd>Hold receipt, raise supplier deviation, notify purchasing\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Batch fails QC at final inspection\u003C\u002Ftd>\n\u003Ctd>QC rejection flag in production system\u003C\u002Ftd>\n\u003Ctd>Quality lead\u003C\u002Ftd>\n\u003Ctd>Quarantine batch, initiate rework order or write-off\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>This keeps the Tier 2 process maps clean while giving the people who handle exceptions a practical, findable reference.\u003C\u002Fp>\n\u003Cimg src=\"\u002Fapi\u002Fknowledge\u002Finline-image\u002F106?w=700&f=webp\" alt=\"three-tier diagram: overview map, detailed stage maps, exception register as linked document\" loading=\"lazy\" class=\"w-full sm:w-1\u002F3 sm:float-right sm:ml-7 mb-5 rounded-2xl border border-[#E8E8ED] bg-[#F5F5F7]\" \u002F>\n\n\u003Ch2>How to decide which tier an exception belongs in\u003C\u002Fh2>\n\u003Cp>Use these four questions as a filter:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>How often does it happen?\u003C\u002Fstrong> More than once a week in a team of ten? It probably belongs in Tier 2 as a variant. Once a month or less? Tier 3.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Is the resolution steps-based or judgment-based?\u003C\u002Fstrong> If there's a clear sequence of actions to take, document the steps. If it requires someone to evaluate the situation and decide, document the owner and the outcome criteria — not the steps.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Does it affect the main process timeline or output?\u003C\u002Fstrong> If an exception can silently delay an invoice by three days without anyone noticing, it needs to be visible in the Tier 2 map as a branch, not buried in a register.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Is it automation-relevant?\u003C\u002Fstrong> If you're mapping this process to automate it, any exception that the system needs to handle — even rarely — must be explicitly documented before development starts. A developer who doesn't know about partial PO handling will build a system that breaks on the first partial PO.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>A step-by-step approach to documenting exceptions without derailing your process mapping session\u003C\u002Fh2>\n\u003Cp>Process mapping workshops have a well-known failure mode: someone raises an edge case, the group spends forty minutes debating it, and you leave the room with one half-finished diagram and a long list of unresolved questions. Here's how to avoid it:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Start with the happy path only.\u003C\u002Fstrong> Run through the process end-to-end as if everything goes right. Get this on paper first, agreed and signed off, before you touch a single exception.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Open a "parking lot" for exceptions.\u003C\u002Fstrong> When someone says "but what if the customer doesn't have a VAT number," write it on a sticky note or in a separate column of your working document. Don't stop the happy-path walkthrough.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>After the happy path is complete, triage the parking lot.\u003C\u002Fstrong> Go through each item and decide: variant (add to Tier 2 map), exception (add to exception register), or out of scope for this process.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>For each exception in the register, assign an owner immediately.\u003C\u002Fstrong> Undocumented ownership is why exceptions stay unresolved for years. If nobody owns it now, nobody will own it after the automation goes live either.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Review the exception register with the people who actually handle the exceptions\u003C\u002Fstrong> — not just the process owner or the project manager. The warehouse manager who deals with wrong-SKU deliveries three times a week will tell you things the ERP system log never will.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Set a review cadence.\u003C\u002Fstrong> Exceptions evolve. A supplier issue that was exceptional two years ago might now be a weekly occurrence because you changed your sourcing. Build a quarterly review of the exception register into your process governance.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2>The onboarding process example: where exceptions hide in plain sight\u003C\u002Fh2>\n\u003Cp>Onboarding is a process where exception documentation failures are especially visible — and expensive. The happy path looks clean: new employee signs contract → HR sends welcome email → IT creates accounts → manager assigns first tasks → employee starts day one.\u003C\u002Fp>\n\u003Cp>In practice, a technology company with fifty new hires a year might deal with situations like:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>The employee starts before the signed contract is returned (common in competitive hiring markets)\u003C\u002Fli>\n\u003Cli>The laptop ordered four weeks ago hasn't arrived yet\u003C\u002Fli>\n\u003Cli>The new hire is a contractor, not an employee, so half the standard onboarding steps don't apply\u003C\u002Fli>\n\u003Cli>The manager is on holiday the week the person starts\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>None of these are in the happy path. All of them happen regularly. The question isn't whether to document them — it's \u003Cem>where\u003C\u002Fem>. The contractor variant probably belongs in a Tier 2 parallel flow (it happens 20% of the time). The delayed laptop is a Tier 3 exception (it has a clear owner: IT, and a clear resolution: temporary equipment policy). The absent manager is a governance issue that the exception register should name an escalation path for.\u003C\u002Fp>\n\u003Cp>Documenting these correctly before you automate onboarding — say, by building a self-service onboarding portal or connecting your HRIS to IT provisioning — is what separates an automation that works from one that fails on week two.\u003C\u002Fp>\n\u003Ch2>Checklist: Is your exception documentation at the right level?\u003C\u002Fh2>\n\u003Cp>Before you hand off a process map to a developer, an automation tool, or an ERP implementation team, run through this:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The main process map shows only the standard flow and high-frequency variants — no more than 2–3 decision branches per stage\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Every exception that requires a human judgment call is in a separate exception register, not in the main diagram\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Each exception has a named owner, a trigger description, and a resolution path\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> Exceptions that affect the automated system's behavior (even rarely) are explicitly flagged for the development team\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> The exception register has been reviewed by the people who actually handle the exceptions — not just the process designer\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> A review cadence for the exception register is agreed and calendared\u003C\u002Fli>\n\u003Cli>\u003Cinput disabled=\"\" type=\"checkbox\"> You can explain the main process flow to a new employee in under five minutes using only the Tier 1 map\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2>FAQ\u003C\u002Fh2>\n\u003Cp>\u003Cstrong>Should exceptions be in the same tool as the main process map?\u003C\u002Fstrong>\nNot necessarily. The main map might live in a diagramming tool like Lucidchart or draw.io, while the exception register works perfectly well as a structured table in Confluence, Notion, or even a shared spreadsheet. What matters is that they're explicitly linked — the process map should reference the exception register, and each exception entry should reference the relevant process stage.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How do I handle exceptions that are really just workarounds for a broken process?\u003C\u002Fstrong>\nDocument them, but flag them explicitly as "process debt." An exception that exists because the ERP system can't handle split deliveries isn't a true business exception — it's a system limitation masquerading as one. Documenting it makes the problem visible and gives you a prioritized list of things to fix when you do rebuild or automate.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>What if the exception register grows to fifty rows? Is that too many?\u003C\u002Fstrong>\nFifty exceptions across a complex end-to-end process (like order-to-cash across multiple product lines and geographies) is not unusual. The problem isn't the number — it's whether they're properly owned and triaged. If you have fifty exceptions and twenty of them have no owner, that's a governance problem. If they're all owned, reviewed, and prioritized, fifty rows is just operational reality well-documented.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Do exceptions need to be in scope for a process automation project?\u003C\u002Fstrong>\nYes — or explicitly out of scope with a documented decision. "We will not automate this exception; it will continue to be handled manually" is a valid choice, but it needs to be a conscious, recorded decision, not an oversight. Undocumented out-of-scope exceptions are where automation projects quietly fail in production.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>How detailed should an exception entry be?\u003C\u002Fstrong>\nEnough that someone encountering the situation for the first time knows what to do without having to ask. That usually means: one sentence describing the trigger, one sentence describing the resolution, and a named owner. Anything longer is probably a separate mini-process, not an exception entry.\u003C\u002Fp>\n\u003Chr>\n\u003Cp>If you're working through a process improvement or automation project and finding that your documentation keeps collapsing under the weight of its own exceptions, that's often a sign that the underlying process design — not just the documentation — needs attention. Loggix works with businesses to map, clarify, and where appropriate automate processes in FileMaker, custom web applications, and connected systems. Whether you need a structured mapping engagement before a development project or a second opinion on where your process boundaries should sit, that's exactly the kind of work we do.\u003C\u002Fp>\n","Jeroen","2026-07-24",1784901660000,[19,20,21,22,23,24,25],"process mapping","process documentation","business process improvement","exceptions","automation readiness","workflow design","process management",null,false,{"title":29,"slug":30},"Process Improvement","process-improvement",{"title":32,"slug":33},"How to map a business process before automating it","how-to-map-a-business-process-before-automating-it"]