Policies, approvals, and governance

Policies control whether actions in your Organization are completed immediately or must be approved by other Members first. Each workflow has its own independently configurable policy. This article explains how approvals, policies, and locking work together. For how permissions and workflows are structured, see Permissions and workflows. For a high-level overview, see About Organizations.

How approvals work

Every governed action in an Organization follows the same lifecycle:

Step 1 — Initiation: A Member with Initiate or Execute permission creates a request.

Step 2 — Immediate completion check: If the Member holds Execute and the workflow does not require approval ("Always require approval" is OFF), the request is completed immediately. No approval queue, no waiting.

Step 3 — Approval queue: If the request cannot be completed immediately — either because the Member lacks Execute, or because "Always require approval" is ON — the request enters the approval queue. Members with Approve permission on that workflow can review it.

Step 4 — Approval threshold: Once the required number of independent approvals is reached, the request is completed.

Step 5 — Rejection: Any single approver can reject a pending request. A rejected request is not completed.

Separation of duties

A Member cannot approve their own request. This rule is enforced by the system across all workflows and cannot be overridden by any permission or policy configuration.

The only way a single Member can complete an action alone is through Execute, and only when the workflow policy permits it.

Execute and policy interaction

Execute permission interacts with the "Always require approval" policy setting:

Member's permissions	"Always require approval"	What happens
Initiate + Execute	OFF	Request completed immediately, no approval needed
Initiate + Execute	ON	Request enters approval queue, must wait for independent approvers

Important: Execute only works when the workflow policy allows immediate completion. When "Always require approval" is ON, Execute has no effect — all requests must be approved by independent Members.

What happens to Execute when "Always require approval" is ON?

Execute is not removed from the Member. It remains visible in the permission configuration, but the system ignores it while "Always require approval" is ON. The UI shows a warning-color indicator on the Execute column. If you later toggle "Always require approval" back to OFF, the Member can complete actions immediately again without needing to be re-assigned the permission.

Email confirmation for address changes

When a Member uses Execute to add or remove a whitelisted address immediately (without independent approvers), the system sends an email confirmation before the change takes effect. The address change does not finalize until the confirmation is completed.

During Beta, the email confirmation is sent to the Organization Owner regardless of which Member initiated the change. Sending the confirmation to the request creator directly is planned for a future release.

Device trust status does not affect this behavior — email confirmation is always required for immediate address changes.

When an address change request goes through the standard approval process with independent approvers, no email confirmation is needed. The approval from other Members serves as the security control.

How to configure a policy

Go to the Manage Policies section in your Organization.
Select the workflow you want to configure (for example, Initiate Withdrawal).
Set the required number of approvals — this is how many independent Members with Approve must sign off before a request is completed.
Choose whether to enable "Always require approval". When ON, every request on this workflow must go through the approval queue, even from Members with Execute. When OFF, Members with Execute can complete actions immediately.
Review the configuration and confirm.

If the Manage Policies workflow itself has a policy configured, your changes may enter the approval queue. See Locking policies for details on how policy governance works.

Important: Before setting a required approval count, make sure enough Members hold Approve permission on the target workflow to meet the threshold. The system prevents configurations that cannot be satisfied.

Policy settings

Each workflow has its own policy with two settings:

Setting	What it does
Required approvals	The number of distinct approvers that must sign off before a request is completed. Approvers are drawn from the pool of Members with Approve permission on that workflow. The person who initiated the request is always excluded from the approver pool.
Always require approval	When ON: all requests must go through approval, even if the Member holds Execute. When OFF: Members with Execute can complete actions immediately.

Locking policies

Policy locking prevents any single Member, including the Organization Owner, from changing a workflow's governance settings alone.

When a policy is locked:

Any change to that workflow's policy requires approval from independent Members
Unlocking also requires independent approval
The Owner is bound by the same rules as every other Member

Once governance is locked, no one person can weaken it alone. Future changes still remain possible, but they depend on independent approval and approver coverage remaining available.

Scope: Policy locking applies per workflow. Locking one workflow's policy does not affect any other workflow. This lets you tighten governance incrementally, one workflow at a time.

Policy lock vs "Always require approval" on Manage Policies

These two controls serve the same goal at different levels:

Control	Scope	Effect
Policy Lock	One workflow at a time	Changes to that specific workflow's policy require independent approval. Other workflows are unaffected.
"Always require approval" on Manage Policies	All workflows at once	All policy changes across every workflow require independent approval. Acts as a bulk governance switch.

Use Policy Lock for incremental tightening. Use "Always require approval" on Manage Policies only when you want to govern all policy changes at once.

Safeguards

The system enforces safeguards to prevent invalid or unenforceable configurations:

Approver availability: A policy cannot be locked unless at least one other Member (besides the person locking) holds Approve on the Manage Policies workflow. Without this, a locked policy could create a deadlock where no one can approve future changes.

Lockout prevention: The system blocks saving a policy when the only Member with Approve on a workflow also holds Initiate and the required approval count is 1. Since Members cannot approve their own requests, this Member's requests would have no eligible approver.

Deactivation does not check approver coverage: Deactivating or removing a Member currently proceeds even if it reduces the number of available approvers below the required threshold for a workflow. Automatic coverage checks for deactivation are planned for a future release. Until then, verify that enough other Members with Approve remain active to meet the required approval count on affected workflows before deactivating a Member, or contact support if you need assistance.

Troubleshooting

I can't lock a workflow's policy

The system requires at least one other Member (besides you) to hold Approve permission on the Manage Policies workflow before a policy can be locked. Without an independent approver, locking would create a deadlock where no one could approve future policy changes. Assign Approve on Manage Policies to another Member and try again.

My request is stuck in the approval queue

Check whether enough Members with Approve permission on that workflow are still active. If a Member with Approve has been deactivated or removed since the request was created, the remaining approvers may no longer be enough to reach the required count. A pending request is held to the approval threshold that applied when it was created — changing the policy now does not lower the requirement for an already-queued request. To unblock it, re-activate the deactivated Member or assign Approve to another active Member so the original threshold can be met. If Manage Access also requires approval and the same approvers are unavailable, contact support for assistance.

Execute has no effect, actions still go to the approval queue

"Always require approval" is ON for that workflow. When this setting is enabled, Execute is dormant — the permission is still assigned but every request must go through independent approval. To restore immediate completion for Members with Execute, toggle "Always require approval" to OFF. Note that this is a Manage Policies action — if Manage Policies itself requires approval, the change must be approved by independent Members before it takes effect. See Execute and policy interaction above.

I can't save the policy configuration

This workflow has only one Member with Approve, and that Member also holds Initiate. Since Members cannot approve their own requests, their requests would have no eligible approver. Assign Approve to at least one other Member, or grant this Member Execute so they can complete actions without approval when the policy allows.

I deactivated a Member and now a workflow doesn't have enough approvers

Deactivation is not blocked by approver shortages. If you deactivated a Member who held Approve on one or more workflows, verify that enough active Members with Approve remain to meet each workflow's required approval count. If a workflow is short on approvers, either re-activate the Member or assign Approve to another active Member on the affected workflows. Pending requests on those workflows will remain in the queue until the required approval count can be reached.

What's next

Once you understand how policies and approvals work, see Rolling out governance for a step-by-step guide to introducing approval requirements one workflow at a time, including worked examples showing selective and full governance configurations.