> 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/approver-and-advice-eligibility.md). # Set up approvers and advice collaborators **For:** Tenant and brand administrators who manage operators, roles, and approval workflows. Configure and test in the intended tenant and brand; use a synthetic request in QA before relying on a new assignment. An **approver** decides a currently open workflow level. An **advice collaborator** can answer a question from an approver but cannot decide that level. These are separate forms of access: selecting an operator in a level does not bypass the workflow's decision permission, and switching on collaboration eligibility does not make someone an approver. | Requirement | Workflow approver | Advice collaborator | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | | Operator record | Active, unblocked, not deleted, and in the request's exact tenant and brand | Same | | Workflow level | Must resolve from that level's named **Operator**, **Role**, or **Desk** selector and receive an assignment when the level opens | Does **not** need a level assignment; the approver asks a named operator for advice | | Operator setting | **Eligible for Collaboration** is not required | **Eligible for Collaboration** must be on | | Approval permission | If **Permission to decide** has a key, the operator's role must hold that exact key; with **None**, an assigned operator may decide without an additional decision key | No workflow decision permission is required to answer the specific advice request | | Portal access | Check `CAN_ACCESS_APPROVALS_COCKPIT` and `CAN_VIEW_APPROVALS_INBOX` on the operator's role | Check the same portal-access permissions; the specific advice request grants the right to answer it | The cockpit and inbox permissions provide access to the approval area; **neither grants decision authority**. `CAN_VIEW_ALL_APPROVALS` is broader read access and is not required merely to decide an assigned level or answer advice. Workflow-configuration permissions are also not required for either activity. Check these role grants for newly created or customized operator roles instead of assuming they were inherited. ## Make an operator available for advice 1. In the correct tenant and brand, open the operator's record in **Admin Portal → Operators → Security**. Confirm that the operator is active, not blocked or deleted, and belongs to the same tenant and brand as the approval request. 2. Turn on **Eligible for Collaboration** and **Save**. An administrator needs the Operator **Security** tab permission (`SEE_OPERATOR_SECURITY_TAB`) to see this control and `UPDATE_OPERATORS` to save the operator change. These are the administrator's permissions, **not** permissions to grant to the advice recipient. 3. In **Roles → Permissions**, check that the recipient's role can access the approval cockpit and inbox (`CAN_ACCESS_APPROVALS_COCKPIT` and `CAN_VIEW_APPROVALS_INBOX`). No `*.decide` permission is needed solely for advice. 4. Have an assigned approver open a QA request's **Decision** tab and ask the named operator for advice. The approver cannot ask themself. Verify that the recipient can open and answer the request. Their answer is recorded as advice; it does **not** count toward approval quorum or advance the workflow. The advice picker only offers eligible operators in the request's exact tenant and brand. Eligibility is checked again when the approver sends the request, so a stale picker entry cannot make an ineligible operator a collaborator. ## Make sure the advice request reaches them > **Not yet in production.** Everything in this section arrives with a named release. Until it is live and verified in the brand you are documenting, treat the behaviour below as unavailable, and tell approvers to send the request link themselves. Eligibility decides who **can** be asked. It does not tell them they **have been** asked. Two settings decide that, and without them the operator is asked silently: the advice request is recorded, the approver sees it as sent, and nothing reaches the recipient at all. 1. **Map the three advice email templates on the workflow.** In **Tenants & Brands → Approval Workflows → Edit → Notifications**, set **Advice asked**, **Advice received** and **Advice cancelled**, then **republish**. See [Choose approval email templates safely](/crm-admin/platform-configuration/configure-financial-approval-flows/approval-email-templates.md). A field left on **No email** sends no email **and raises no in-app notification** — the two channels are deliberately tied together, so an unmapped field silences both. 2. **Confirm the recipient's portal access**, as in the steps above. The notification carries a link straight to the request; without cockpit and inbox access that link is refused. Once both are in place, an operator who is asked for advice receives an email and an in-app notification, and the request appears in the Approvals area under **Advice asked of you**, beside the usual list of items waiting for their decision. The two lists are kept separate on purpose: advice carries no authority over the step. **Never add an adviser to a workflow level so that the request appears in their queue.** A level assignment is decision authority, and it is the wrong tool for making a question visible. If a recipient cannot find the request, fix the notification configuration and their portal access instead. ### What the recipient sees | On their screen | What it means | | -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Advice asked of you** in the Approvals area | The requests where a colleague has an open question for them. It is empty for everyone who has not been asked. | | **Advice asked of you** card on the request's **Decision** tab | Their own question and the box to answer it. An approver who asked somebody else sees the same card titled **Advice you asked for**. | | An answer box with approve/reject and a note | Their opinion, recorded against the request. It does **not** count toward quorum, move the level, or decide anything. | | **Advice no longer needed** | The approver either withdrew the question or decided the step without waiting. Nothing further is expected from them. | ## Make an operator able to decide a workflow level 1. In **Tenants & Brands → Approval Workflows**, select the correct brand and inspect the **live** workflow. Read its **Permission to decide** field; the applicable rule may choose a different chain from the fallback, but the workflow's decision-permission setting still applies. 2. Check the relevant level's **Operator**, **Role**, or **Desk** selector. The operator must be active, unblocked, not deleted, in the same tenant and brand, and actually match that selector when the level opens. A role or desk label on the diagram does not itself grant the operator an assignment. 3. Give the operator's role cockpit and inbox access (`CAN_ACCESS_APPROVALS_COCKPIT` and `CAN_VIEW_APPROVALS_INBOX`). If **Permission to decide** names a key, grant that **same key** to the role. The key is workflow-wide, not a different permission automatically assigned for each level. If the field is **None**, a correctly assigned operator can decide without a separate decision key. 4. In QA, use **Simulate** with a representative request. Review the resolved approvers: **no eligible approver** means the selector or operator scope/status needs attention; **no decide permission** means an assignment was found but the required role grant is absent. Then open a synthetic request and confirm that the operator receives an assignment and can decide the currently open level. Simulation alone does not prove that the decision or financial outcome works. For the standard workflow subjects, the default decision keys are: | Workflow subject | Default key when a decision permission is configured | | --------------------------------------------- | ---------------------------------------------------- | | Manual bank deposit and overlimit PSP deposit | `approvals.withdrawal.decide` | | Withdrawal | `approvals.withdrawal.decide` | | IB application or commission-profile change | `approvals.commission_profile.decide` | | Trading-account request | `approvals.trading_account.decide` | The deposit and withdrawal subjects currently **share** `approvals.withdrawal.decide`; its display name may say *assigned transaction approval level*. Do not infer a different deposit key from a level labelled Finance or Risk. Always use the **actual Permission to decide shown on the workflow**: it may be **None** or deliberately configured differently from the defaults above. Granting a key to a role is wider than selecting one operator on one request, so review the role's membership and brand scope with the process owner. An assigned operator may still be prevented from deciding by the workflow's requester/four-eyes rules or because another level is currently open. **Direct approval**, exceptional override, and later Treasury settlement have separate controls and permissions; none are required simply to decide an assigned level or answer advice. ## If someone cannot participate | What you see | Check first | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Operator absent from the advice picker | **Eligible for Collaboration** saved on the operator; active/unblocked/not deleted; exact tenant and brand; approver is not asking themself. | | Advice recipient cannot open or answer | Cockpit and inbox access; the request is addressed to that operator and remains open. A decision permission does not substitute for the specific advice request. | | Advice recipient received no email and no notification | The workflow's **Advice asked** template, and whether the workflow was **republished** after it was set. An unmapped field silences the email and the in-app notification together. Check the brand's email body and delivery trace in Communication Hub before concluding the request was never sent. | | Advice recipient cannot find the request | **Advice asked of you** in the Approvals area; the ordinary inbox lists only items awaiting their **decision**, and an adviser is never assigned to the level. Do not resolve this by adding them to a workflow level. | | Advice card missing entirely from the request | Whether the page reported a loading error for the advice section. Reload the request; if an error persists, record it for support rather than re-sending the advice request. | | Operator selected in a workflow but absent from the open level | The live workflow and selected rule/fallback, level selector, role/desk membership, exact tenant/brand, and operator status. | | Assigned level is read-only or decision returns `APPROVAL_PERMISSION_REQUIRED` | Compare the workflow's **Permission to decide** with the operator role's **active** grant. Assignment alone is insufficient when a key is configured. | | Decision returns `APPROVAL_NOT_ASSIGNED` | Confirm that this operator has an assignment on the **currently open** level, not merely a future or completed level. | See [Configure deposit and withdrawal approvals](/crm-admin/platform-configuration/configure-financial-approval-flows.md) for routing, rules, and fallback chains, and [From transaction to decision](/crm-admin/platform-configuration/configure-financial-approval-flows/from-transaction-to-decision.md) for how a request reaches a level. --- # 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/approver-and-advice-eligibility.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.