Rolling out governance

The Execute level and the “Always require approval” setting combine into two postures:

• Fast path for some, approvals for the rest. Lock the policy with “Always require approval” OFF. Members whose profile holds Execute complete requests immediately; everyone else goes through approval. The lock prevents anyone from loosening the rules alone.
• Approvals for everyone. Lock the policy with “Always require approval” ON. Every request, including the Owner’s, goes through independent approval. No single person can complete a governed operation alone.

Different workflows can hold different postures. A common shape: approvals for everyone on Withdrawal Request, a fast path on Transfer Request (funds stay inside the Organization), and approvals on Manage Policies to protect the rules themselves.

The first three steps are freely reversible. Locking is the commitment.

Step 1 - Bootstrap

The Owner starts with the system-defined Admin profile and Full access role: Execute on every workflow, every permission on every account. Every workflow’s policy starts open. As a single-user Organization, you operate exactly as before, nothing waits for approval, because there is no one to approve.

Step 2 - Configure

Build the approval setup for one workflow, typically Withdrawal Request first, while “Always require approval” stays OFF:

1. Invite Members and assign Workflow Profiles that hold Approve on the target workflow. The system-defined Approver profile grants approval rights on every workflow; Funds Manager covers starting and approving transfers and withdrawals.
2. Assign Account Roles so initiators hold the right fund-movement permissions on the right accounts.
3. Set the required number of approvals on the target workflow.
4. If you plan to lock (Step 4), set up the unlock route on Manage Policies now: a Member who can start a Manage Policies request, plus as many other Members holding Approve on Manage Policies as that workflow requires. The system does not check this before it lets you lock.

Nothing is enforced yet. You retain Execute and continue working normally while the pieces go into place.

Step 3 - Validate

Turn “Always require approval” ON for the target workflow. Every request, including yours, now queues. Verify with live requests:

• Approvers see pending requests and can approve and reject.
• The required approval count is reachable with your current team.
• The end-to-end flow, from initiation through completion, behaves as expected. Check the resulting security events link back to their requests.

This is the safe window: governance is in effect, but the policy is not locked, so you can turn the setting OFF, adjust, and try again as often as needed. Decide whether the final posture should keep “Always require approval” ON or turn it OFF before you lock the policy.

Step 4 - Lock

Lock the policy. Locking is itself a Manage Policies request: if Manage Policies already requires approval, the lock takes effect once another Member approves it. From this point:

• All requests follow the configured approval rules.
• Every change to this policy, the approval count, the “Always require approval” setting, unlocking, waits for sign-off from another Member holding Approve on Manage Policies. Execute on Manage Policies does not bypass this: the lock overrides immediate completion for the locked policy.
• The Owner’s changes go through the same review as everyone else’s.

Step 5 - Repeat

Every other workflow keeps its current posture until you return to Step 2 for it. Any mix of governed and ungoverned workflows is a valid steady state, the progression is a recommendation, not a requirement.

The final step - lock Manage Policies itself

Manage Policies has its own policy and its own lock. Locking it is the end state of the rollout: from then on, every rule change anywhere in the Organization, policy settings, locks, and unlocks, on every workflow, requires independent approval, and no single person can loosen governance again through the product.

Take this step last, once every workflow you intend to govern is configured and locked. Confirm first that a Manage Policies request can still be started and approved without you: someone who can start it, plus as many other Members holding Approve on Manage Policies as that workflow requires, all of them verified and active. Locked policies stay changeable only while that route exists, and the system does not check it for you. See Policies, approvals, and governance for how this lock behaves.

A CFO wants to complete withdrawals immediately herself while every withdrawal from the fund managers goes through her review.

Workflow Profiles:

All three hold an Account Role granting Withdraw on the operating accounts. The levels in this example describe Withdrawal Request only. The system-defined Initiator profile also grants Initiate on every other workflow. Use a custom profile if the fund managers should initiate withdrawals but not other governed operations.

Withdrawal Request policy: required approvals 1, “Always require approval” OFF, policy locked.

The result: the CFO’s withdrawals complete immediately through Execute. Each fund manager’s withdrawal waits for one approval, in practice, the CFO’s, since she is the only approver. Nobody can change these rules alone, because the policy is locked.

Before locking, check that a Manage Policies request could still be approved without the person who starts it: as many Members holding Approve on Manage Policies as that workflow requires. Those Members approve future policy changes and unlock requests. The system does not check this for you.

Tightening later. When the firm decides all withdrawals, including the CFO’s, need review, the change goes through a policy request (independent approval required, since the policy is locked):

1. Move the fund managers to a profile that holds Approve, so they can review each other and the CFO.
2. Raise required approvals to 2.
3. Turn “Always require approval” ON.

The CFO’s Execute stays on her profile, dormant. If the firm ever relaxes the policy again, her fast path resumes without anyone re-assigning access.

A four-person team on the Withdrawal Request workflow, showing how approval eligibility resolves per request:

Policy: required approvals 2, “Always require approval” ON (so the Owner’s Execute is dormant).

• Withdrawal Request configured, validated, and locked
• Transfer Request posture decided (fast path or full approvals) and locked
• Manage Addresses approval requirements set, the whitelist guards every withdrawal
• Manage Team & Access and Manage API Keys policies set, access changes and new credentials are worth reviewing
• Manage Policies governed, and, as the final commitment, its own policy locked, so the rules themselves are protected
• A Manage Policies request can still be started and approved without any one person, someone to start it, plus as many other Members holding Approve as that workflow requires, keeping locked policies changeable
• A periodic access review scheduled, using security events