> 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/manual-deposits/manual-deposits-workflow.md).

# Workflow approval

**For:** Brand administrators configuring client-submitted bank deposit review, with Finance and Risk approving the business policy. Other manual methods and operator-created deposits are outside this guide.

## When this route starts

A live workflow with trigger **Manual / bank deposit created** applies to the client-initiated request. It owns the review. Its first matching rule chooses an outcome; if no rule matches, its fallback chain runs. There are no additional authoritative Risk or Finance clicks after the workflow completes.

Before assigning Risk or Finance operators, follow [Set up approvers and advice collaborators](/crm-admin/platform-configuration/configure-financial-approval-flows/approver-and-advice-eligibility.md). A selected level approver also needs the workflow's configured **Permission to decide**, if one is set; advice eligibility is a separate operator setting.

## Build the client-bank route

1. Open **Tenants & Brands → Approval Workflows** in the intended tenant and brand. Check whether another **live** workflow already owns this trigger and client-initiated channel. Publishing an overlap can replace it.
2. In a draft, choose **Manual / bank deposit created** and **Client-initiated**. Give it a recognizable name and code. The workflow is not active until published.
3. Configure the fallback chain. For an approved Risk-then-Finance policy, add **Risk review** at level 1 and **Finance approval** at level 2. Assign eligible, *active* people or desks to both; choose each level's quorum, allowed decisions, SLA, and escalation. If a level shows **0 active**, stop and correct staffing before publication.
4. Turn on **Requester cannot approve** and **Same person cannot approve two levels** if the policy requires those independent controls. Turn **Direct approval** off if every request must complete both levels; an enabled direct holder can supersede the chain.
5. Choose the [outcome and level email templates](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md). The QA editor offers `APPROVAL_ASSIGNED` and `APPROVAL_REMINDER` for each level. Review the brand's mapped body, sender, language, and delivery before relying on them.
6. Add rules only for approved exceptions. Conditions combine with AND; the first active matching rule wins. A no-match request still uses **this fallback chain**, not the authoritative route.
7. Use **Simulate** with a suitable QA deposit, then submit a synthetic client bank deposit with evidence. Confirm the actual level decisions, client communication, and exactly one credit on approval. Confirm rejection does not credit.

![Unsaved QA manual-bank workflow editor showing the trigger, client-initiated scope and four-eyes controls](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-e67e40dbfafc45d69819be9d74284548c1b67f81%2Fqa-trigger-controls.jpg?alt=media)

*QA editor illustration only: the example name/code and controls were not saved or published. Confirm the initiator channel and direct-approval policy before continuing.*

![Unsaved QA manual-bank workflow editor showing Finance level, assignment/reminder template selectors and incomplete approvers](https://1730587053-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpafqqfmUanubolAQzn0g%2Fuploads%2Fgit-blob-cbfe7df2686fdfeb5a0d5d928403c0486ab5cece%2Fqa-finance-level-and-emails.jpg?alt=media)

*QA editor illustration only: `APPROVAL_ASSIGNED` and `APPROVAL_REMINDER` were selected in the unsaved form. The pictured levels are **incomplete** because no eligible Risk/Finance operators were assigned. Never publish an incomplete chain.*

## What reviewers see and what they must check

Reviewers must inspect the client's uploaded payment evidence before deciding. In the current workflow **Decision** tab, follow the transaction link and open the evidence in transaction details; the file itself is **not** displayed directly on the Decision tab.

If a required Risk or Finance decision is missing, inspect the **workflow decision history** and the actual selected rule/chain, not merely a transaction label. A workflow that omits Risk or Finance does not acquire those stages automatically. Use the [transaction-to-decision map](/crm-admin/platform-configuration/configure-financial-approval-flows/from-transaction-to-decision.md) to diagnose route selection and the [manual bank deposit overview](/crm-admin/platform-configuration/configure-financial-approval-flows/manual-deposits.md) to compare the no-workflow path.


---

# 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/manual-deposits/manual-deposits-workflow.md?ask=<question>&goal=<user_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.