Rolling out governance

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.

Two ways to govern a workflow

The interaction between Execute and "Always require approval" gives you two governance options per workflow:

Approvals for some, fast-path for others: Lock the policy with "Always require approval" OFF. Members with Execute can still complete actions immediately; everyone else goes through approval. The lock prevents anyone from changing these rules alone.
Approvals for everyone: Lock the policy with "Always require approval" ON. Every Member, including the Owner, must go through the approval queue. No single person can complete an action alone.

Step-by-step progression

The first three steps are reversible. The fourth — locking — is the point of commitment.

Step 1: Bootstrap

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.

Step 2: Configure

Build the approval setup for a specific workflow while "Always require approval" stays OFF. The Owner retains Execute and can continue working normally.

Invite Members and assign Approve permission on the target workflow.
Set the required number of approvals.
If you plan to lock the policy (Step 4), make sure at least one other Member holds Approve on the Manage Policies workflow. The system requires an independent approver before it allows locking.

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.

Step 3: Validate

Toggle "Always require approval" to ON for the target workflow. This forces every action, including the Owner's, through approval. Verify that:

Approvers receive pending requests and can act on them
The required approval count is achievable with the current Members
The end-to-end flow works as expected

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.

Step 4: Lock

Once satisfied, lock the policy. This is the point of commitment. From here:

All requests follow the configured approval rules
Changes to the policy — toggling "Always require approval," changing the required approval count, or unlocking — also require independent approval
No single person can weaken governance on this workflow alone

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.

Step 5: Repeat

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.

Example: selective governance for withdrawals

A CFO wants to retain the ability to complete withdrawals immediately while requiring all withdrawals from Fund Managers to go through review.

Permission setup:

Member	View	Initiate	Approve	Execute
CFO	Yes	Yes	Yes	Yes
Fund Manager A	Yes	Yes	—	—
Fund Manager B	Yes	Yes	—	—

Policy settings:

Required approvals: 1
Always require approval: OFF
Policy: Locked

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):

Assign Approve to Fund Managers so they can review each other's requests.
Increase required approvals to 2.
Toggle "Always require approval" to ON.

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.

Example: four-member approval scenarios

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.

Member	View	Initiate	Approve	Execute
Organization Owner	Yes	Yes	Yes	Yes
Alice	Yes	Yes	Yes	—
Bob	Yes	—	Yes	—
Charlie	Yes	Yes	—	—

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	Owner	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.