> 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/approval-email-templates.md). # Choose approval email templates **For:** Brand administrators configuring notifications, with a Communication Hub owner reviewing wording and delivery. Template selection is part of the workflow configuration, but it is **not** proof of delivery. ## Where each template is selected Open **Tenants & Brands → Approval Workflows → Create/Edit** in the intended brand. The **Notifications** section handles outcome messages; each **Approval level** has its own assignment and reminder choices. The QA editor currently offers these event templates: | Editor field | Available event template | Intended recipient/event to verify | | ----------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | Approved (client) | `APPROVAL_APPROVED` | Client after final approval. For withdrawals, review the wording carefully: approval is **not** payout completion. | | Rejected (client) | `APPROVAL_REJECTED` | Client after a final rejection. | | Information requested | `APPROVAL_INFORMATION_REQUESTED` | Person asked to supply information. | | Decision recorded (requester) | `APPROVAL_DECISION_RECORDED` | Requester as a multi-level chain advances. | | Superseded (assignees) | `APPROVAL_SUPERSEDED` | Pending assignees when a direct approval or other supersession ends their assignment. | | Level assignment | `APPROVAL_ASSIGNED` | Eligible approver(s) when that level starts. | | Level reminder / SLA breach | `APPROVAL_REMINDER` | Eligible approver(s) when the configured reminder/escalation fires. | | Advice asked (adviser) | `APPROVAL_COLLABORATION_REQUESTED` | Operator asked for advice, at the moment the approver sends the question. | | Advice received (approver) | `APPROVAL_COLLABORATION_ANSWERED` | Approver who asked, when the adviser answers. | | Advice cancelled (adviser) | `APPROVAL_COLLABORATION_CANCELLED` | Operator asked, when the approver withdraws the question or decides the step without waiting. | > **Not yet in production.** The three advice fields and their event templates arrive with a named release. Until that release is live and verified, do not instruct administrators to configure them. Check the current editor for the brand you are documenting before publishing this row set; see [Set up approvers and advice collaborators](/crm-admin/platform-configuration/configure-financial-approval-flows/approver-and-advice-eligibility.md) for the behaviour they drive. These are **editor choices**, not proof that delivery will work. A brand may use an exact mapping or an eligible active SaaS body fallback; header resolution, locale, sender, and recipient still need review. Some legacy deposit/withdrawal emails exist in the broader template catalog but are not offered by these workflow fields; do not substitute their names in a workflow. ## Configure and verify 1. Agree with Finance/Risk which events should notify the client, requester, and approvers. For a sensitive event, choose **No email** intentionally if the approved wording is not ready; that option sends no fallback text. 2. In **Communication Hub → Email Bodies**, inspect the body in each supported language and brand. Check subject, placeholders, sender/header, exact mapping or SaaS fallback, and a rendered preview. Create or approve a brand-specific version where the shared wording is unsuitable. 3. Return to the workflow editor and select the approved event template for each outcome and for **each level's** assignment/reminder. Set the level SLA and escalation separately; selecting `APPROVAL_REMINDER` alone does not schedule a reminder. Where the advice fields are available, treat them the same way: they are the only thing that tells an operator they have been asked for an opinion. 4. **Republish the workflow after changing any template.** A request already in progress reads the templates stored with the version it started on, so an edit left unpublished changes nothing for work already in the queue. 5. Review publication warnings. In current QA behavior, a missing selected event template or unresolvable publishable content is a **warning**, not a publish blocker; nobody is emailed **or notified in-app at that event** until the configuration resolves. A valid active SaaS fallback may satisfy content resolution without an exact brand mapping. Do not treat a green publish as communication acceptance. 6. In QA, generate a synthetic request and trigger the chosen events. Check the actual recipient, subject/body/locale, Communication Hub delivery trace, and in-app notification. Repeat for failure, information request, and supersession where enabled. ![QA Email Bodies page showing the generic approval subject and body preview](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-a254f19b0a78cc64311d4c48e2cac5e9311d296a%2Fqa-approved-body-preview.jpg?alt=media) *QA catalog illustration: preview the actual body before selecting its event in a workflow. This is a read-only SaaS body, not a brand-approved withdrawal message or a delivery test.* > **Withdrawal wording trap:** The currently visible generic English `APPROVAL_APPROVED` body says the request was “approved and processed.” That can be read as *paid*, although workflow approval can precede Treasury submission and provider settlement. Do not enable that wording for withdrawal approval until a Finance-approved, accurate brand body is mapped and tested. A separate payment-complete notification must be driven by actual payment status, not by approval alone. The [transaction-to-decision map](/crm-admin/platform-configuration/configure-financial-approval-flows/from-transaction-to-decision.md) explains when these events can occur. The screenshots in the manual and overlimit guides are unsaved QA illustrations, **not** evidence that the pictured templates are live or sending. The withdrawal guide shows a live built-in workflow with **No email** selected in its outcome fields; that is a configuration state, not proof that the catalog lacks those bodies. --- # 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/approval-email-templates.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.