Skip to main content

How the Approval Chain Works

Not every action an agent takes in the CRM takes effect immediately. For changes that carry real consequences — editing core lead data, applying high-stakes tags, or recording financial transactions — the system routes the action through a manager's approval queue first. Nothing is finalized until a manager reviews and approves it.

This two-step pattern is the approval chain: agent initiates → manager approves (or rejects) → the change takes effect (or doesn't).

Why it exists​

The approval chain is a control layer. It prevents unintentional or unauthorized changes from going directly into the system. It also creates an audit trail — every approval or rejection is logged with who acted and when.

The two approval queues​

There are two separate queues, each handling a different kind of action:

1. Data Change Requests​

Data Change Requests catch changes to a lead's information and labels. Three kinds of agent actions land here:

  • New lead submissions — when an agent creates a new lead directly, the lead may require manager sign-off before it's active.
  • Master data edits — when an agent uses the Set Master Data action to update a lead's core details (name, contact info, etc.), the update doesn't apply immediately; it queues for approval.
  • Non-modifiable tag applications — when an agent tries to apply a tag whose Is Modifiable setting is turned off, the attempt creates a Data Change Request instead of applying the tag. The tag appears on the lead only after the manager approves.

Managers review Data Change Requests by navigating to Data Change Requests in the main sidebar. Each request shows the proposed change. Clicking Approve applies it; clicking Reject discards it. An agent whose request is rejected will see no change on the lead.

2. Lead Transactions​

Lead Transactions is the approval queue for financial actions — deposits and withdrawals that agents record on behalf of a lead.

When an agent clicks Create a Deposit or Create a Withdrawal on a lead's profile and submits the form, the transaction does not immediately post to the lead's record. It enters the Lead Transactions queue with a Pending status.

Managers review the queue by navigating to Lead Transactions in the sidebar. Each entry shows the lead, the transaction type, the amount, and the method. The manager can:

  • Approve — the transaction is finalized and recorded against the lead. For registered customers, an approved deposit or withdrawal then flows into the Finance views for execution and reconciliation.
  • Reject — the transaction is discarded. The manager can provide a reason. Nothing is recorded on the lead's financial history for a rejected transaction.

No funds move and no financial record is created until the manager approves. This is by design.

What "approved" and "rejected" mean downstream​

ActionApproved outcomeRejected outcome
Data Change Request (master data)Lead record updatedLead record unchanged
Data Change Request (tag)Tag applied to leadTag not applied
Lead Transaction (deposit)Deposit recorded on lead; flows to Finance queueNo deposit recorded
Lead Transaction (withdrawal)Withdrawal recorded on lead; flows to Finance queueNo withdrawal recorded

Who sits where in the chain​

Agents initiate actions. They submit the request and then wait — they cannot approve their own submissions. If a request is rejected, the agent sees no change and (depending on configuration) may receive feedback via the rejection reason.

Managers own both approval queues. Checking these queues regularly is part of the daily manager workflow — if a manager doesn't approve, agents are blocked from progressing those leads or recording those transactions.

See also​