This guide walks you through introducing approval requirements into your Organization one workflow at a time. You do not need to configure all governance at once — the system is designed so you can move each workflow from fast single-user operations to fully governed multi-party approval at your own pace.
For how policies and approval settings work, see Policies, approvals, and governance. For the permission model, see Permissions and workflows.
The interaction between Execute and "Always require approval" gives you two governance options per workflow:
The first three steps are reversible. The fourth — locking — is the point of commitment.
The Owner starts with full permissions on all workflows. At this stage, the Owner is the only Member and can complete any action without approval. This is the expected starting state.
Build the approval setup for a specific workflow while "Always require approval" stays OFF. The Owner retains Execute and can continue working normally.
At the end of this step, the approval rules are defined and the right people have permissions, but nothing is enforced yet. The Owner can still complete actions via Execute and can still change policies alone.
Toggle "Always require approval" to ON for the target workflow. This forces every action, including the Owner's, through approval. Verify that:
Because the policy is not yet locked, you can still roll back. Toggle "Always require approval" OFF to restore immediate completion and adjust the configuration before trying again.
This is the safe window for experimentation. Governance is in effect for the target workflow, but the Owner retains unilateral control over the policy itself and can roll back at any time.
Once satisfied, lock the policy. This is the point of commitment. From here:
Important: Before locking, make sure at least one other active Member holds Approve on the Manage Policies workflow. The system requires an independent approver before it allows locking.
Important: Locking removes any one person's ability to weaken governance on this workflow alone. Future changes, including unlocking, depend on an independent approver remaining available through the Manage Policies workflow.
All other workflows remain as fast paths — the Owner can still use Execute on any workflow whose policy has not been locked. Return to Step 2 for the next workflow.
This progression is a recommendation, not a requirement. You can operate indefinitely with any combination of governed and ungoverned workflows.
A CFO wants to retain the ability to complete withdrawals immediately while requiring all withdrawals from Fund Managers to go through review.
Permission setup:
Lid | Bekijken | Initiëren | Goedkeuren | Voer uit |
|---|---|---|---|---|
CFO | Ja | Ja | Ja | Ja |
Fund Manager A | Ja | Ja | — | — |
Fund Manager B | Ja | Ja | — | — |
Policy settings:
The CFO can initiate and immediately complete withdrawals using Execute. Fund Managers can initiate withdrawals, but each request enters the approval queue and requires 1 approval from the CFO.
Transitioning to full governance: When the CFO later decides that all withdrawals, including their own, must go through approval, they request a policy change (which itself requires independent approval because the policy is locked):
After this change, the CFO's Execute permission remains assigned but has no effect. The policy now requires independent approval for every request, including the CFO's.
Keeping Execute assigned even when it currently has no effect preserves the Member's access scope in the permission matrix. This will be especially useful when multi-account support is available, where Execute also defines which accounts a Member can operate on.
This example shows a fully configured Initiate Withdrawal workflow and illustrates how permissions and policy interact in practice. The layout mirrors the permission matrix visible in the product UI.
Lid | Bekijken | Initiëren | Goedkeuren | Voer uit |
|---|---|---|---|---|
Organization Owner | Ja | Ja | Ja | Ja |
Alice | Ja | Ja | Ja | — |
Bob | Ja | — | Ja | — |
Charlie | Ja | Ja | — | — |
Policy: Required approvals: 2 of 3 available approvers. Always require approval: ON.
The Owner has Execute, but because "Always require approval" is ON it has no effect.
Every withdrawal request must be approved by 2 independent Members. The person who initiates the request is excluded from the approval pool for that request.
Scenario | Who initiates | Who must approve | Why |
|---|---|---|---|
Owner withdraws | Eigenaar | Alice and Bob | Only 2 Members with Approve remain after excluding the Owner. Both must approve. |
Alice withdraws | Alice | Owner and Bob | Alice is excluded. The remaining approvers are the Owner and Bob. |
Charlie withdraws | Charlie | Any 2 of: Owner, Alice, Bob | Charlie does not have Approve, so all 3 approvers are eligible. Any 2 suffice. |
Bob initiates | — | — | Bob does not have Initiate. He cannot create a withdrawal request. He can only approve. |