> For the complete documentation index, see [llms.txt](https://docs.brokvix.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.brokvix.com/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals/withdrawals-workflow.md). # Workflow approval **For:** Brand administrators configuring withdrawal approvals, with Risk, Finance, and Treasury owners reviewing the policy. Work in the intended brand workspace. ## When this route starts A live **Withdrawal requested** workflow owns the client request and its reserved funds. The first matching rule selects its outcome; otherwise the workflow's fallback chain runs. No extra authoritative Risk or Finance approvals are appended after the workflow chain. Final approval moves the request toward payment processing, **not** proof of payment. Before staffing Risk, Finance, or a custom level, follow [Set up approvers and advice collaborators](/crm-admin/platform-configuration/configure-financial-approval-flows/approver-and-advice-eligibility.md). A person selected by a level may still be read-only without the configured **Permission to decide**; a person asked for advice does not need that decision permission. ## Configure the chain 1. Open **Tenants & Brands → Approval Workflows** in the intended brand. Inspect the existing **live** withdrawal workflow and its initiator coverage first. In the current BrokVix QA example, the built-in withdrawal workflow is live and covers both channels. Publishing a custom overlap can replace or narrow that coverage. 2. Review **Withdrawal requested**, **Applies to**, decision permission, fallback levels, quorum, SLA, escalation, and [email events](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md). The built-in workflow's Risk → Finance fallback is system-managed and locked; custom workflows can use different levels. 3. Decide separately whether the requester may approve and whether one person may approve two levels. The built-in fallback requires distinct approvers. In a custom workflow, the second control is configurable; it is **not** the Treasury settlement permission. 4. Decide whether **Direct approval** is permitted. A qualified holder can approve/reject while a chain is pending and supersede its level approvals. Turn it off in a custom workflow if the policy requires every withdrawal to complete each level. Do not mistake the built-in screen's default-on state for a recommendation. 5. Add only approved rules. Check conditions, priority, effective dates, and outcome. A rule may select a chain different from the built-in Risk → Finance fallback; no match uses that fallback. Do not assume a custom chain gains Risk or Finance clicks from the older withdrawal record labels. 6. In QA, simulate a matching rule and fallback, then complete a representative synthetic request. Inspect the **workflow decision history**, reserved/debited amount, Treasury handoff, actual payment status, reconciliation, and notification delivery before publication. ![QA withdrawal workflow edit screen showing the trigger and four-eyes controls](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-5481173afadfb0cad5025abcbfec58186ec22195%2Ftrigger-and-four-eyes.jpg?alt=media) *QA example: trigger and approval controls on the built-in withdrawal workflow. Its system-managed fields are locked; the pictured permission settings and holder counts are illustrative, not a policy recommendation.* ![QA withdrawal workflow edit screen showing Risk and Finance fallback approval levels](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-822d69f54c8701d9ef29400c7d0e18f922186da0%2Frisk-and-finance-levels.jpg?alt=media) *QA example: the built-in fallback has Risk review at level 1 and Finance approval at level 2. The pictured role counts and unselected email templates are illustrative, not a recommended policy. A custom or rule-selected chain may differ.* ![QA live built-in withdrawal workflow showing fallback, direct-approval status and no-email warnings](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-b0660bcb3beb4da23ecdfc5d63a8233133dbd29b%2Fqa-live-fallback-and-no-email-warnings.jpg?alt=media) *QA observation, not a ready-to-use policy: this live built-in workflow has no active Risk/Finance-specific role holders in the pictured brand, and its outcome fields are set to **No email**. Tenant/Brand admins may be eligible, but that does not establish an independent Risk and Finance desk. Resolve staffing and notification warnings before treating this configuration as operational.* ## Select and prove the messages The outcome selectors offer `APPROVAL_APPROVED`, `APPROVAL_REJECTED`, `APPROVAL_INFORMATION_REQUESTED`, `APPROVAL_DECISION_RECORDED`, and `APPROVAL_SUPERSEDED`. A custom level also offers `APPROVAL_ASSIGNED` and `APPROVAL_REMINDER`; the built-in level fields shown in QA are locked. These choices do not guarantee deliverable content. In the pictured live QA workflow, **No email** is selected for outcome events; the page warns that nobody is emailed or notified at those events. The catalog may still contain active bodies and mappings. Current warnings do not block live workflow status. Do **not** enable the generic English `APPROVAL_APPROVED` wording for withdrawals without review: it currently says the request was “approved and processed,” while Treasury/payment may still be pending. Have Finance approve accurate brand wording, map it, and test actual delivery. Do not send a payout-complete message until the payment status confirms that event. ## Current audit and Treasury limitations For a **rule-selected or custom chain**, the backend currently writes a synthetic **System Risk** decision and labels the final workflow approver **Finance** in the older withdrawal review record, even when those were not the actual authorities. A first Risk level in such a chain is **not** recorded as that person's genuine Risk approval in the older record. The built-in fallback behaves differently and records its real Risk and Finance actors. Read the **workflow decision history** for the actual people and levels; do not treat the older labels as extra human sign-offs. The person recorded as final Finance approver is also blocked from later manual Treasury settlement, even if they hold Treasury permission. Arrange a different authorized Treasury operator when settlement is needed. Treasury routing and payment execution remain separate from the workflow chain; an eligible automatic-send route depends on published brand settings. Check final payment status and reconciliation before telling the client the money was sent. See the [transaction-to-decision map](/crm-admin/platform-configuration/configure-financial-approval-flows/from-transaction-to-decision.md) and [withdrawal overview](/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals.md). A custom chain that omits Risk or Finance does not require those departments to click merely because of the older record labels. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.brokvix.com/crm-admin/platform-configuration/configure-financial-approval-flows/withdrawals/withdrawals-workflow.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.