Manage branches and organization heads¶

Intended journey from the Tenant Admin Final Screens. The frontend is still in progress: branch actions are not connected and organization-head changes use local preview state. Tenant Admin is not selected for the initial staging rollout. Follow these steps as a design walkthrough until a connected environment has been verified; sample records and apparent changes do not confirm saved work.

This guide is for workspace administrators and for managers, executives and support staff who need to understand the effects of organization changes. Members can use the access-recovery guidance, but cannot grant themselves administrative or head authority.

Before you start¶

Confirm the workspace you intend to administer. You need an active account, an active administrator membership and current branch access. If you are a designated organization head with an ordinary member role, ask a workspace administrator to perform these changes.

Agree the branch location, intended members and leadership responsibility before changing records. For branch deactivation, identify an eligible administrator who will remain outside the affected branch. For head removal, review work that depends on that person's approval authority. The feature overview explains the access and governance rules.

The workspace Overview design summarizes membership, governance, billing and usage. Its sample amounts, dates and counts are illustrative. Use the relevant live records once available when approving an operational or commercial decision.

Find a branch¶

1. Open Branches in Tenant Admin.
2. Search by branch, city or country. Use Status and Country to narrow the directory.
3. Check the branch's location, status, headquarters indicator and member counts.
4. Select Manage for an active branch or Review for an inactive branch to open its detail.

The intended detail shows location, contact details, time zone, status and assigned members. A directory count is not an access guarantee: an assigned person can have an inactive membership or another access restriction. A workspace with no branches can still have members.

Create a branch¶

1. From Branches, select Create Branch.
2. Enter Branch name, choose Country, and enter City.
3. Enter Time zone if the country's configured default is unsuitable. Add Phone number and Address if useful.
4. Select Mark as headquarters branch only for the intended primary branch. Review any existing active or inactive headquarters first.
5. Select Create branch. In a connected implementation, confirm the saved branch appears in the directory as active before assigning people.

Use a recognizable location name. Keep the name within 255 characters, city within 100, address within 500 and telephone number within 30. The server must recognize the time zone. If the country is unavailable, use an available country only when it is accurate; do not substitute another country to bypass validation.

Cancel closes the dialog without creating the branch. If a submission times out or reports an unclear result, reload the directory and check for the branch before submitting again. The creation operation does not provide a verified duplicate-prevention guarantee.

Assign or remove members¶

1. Open the target branch and select Manage members.
2. In Available Members, search for an eligible active member and choose Select. Use Unselect to undo the selection.
3. Review the target branch and selected people. Select Assign selected to submit the intended assignment.
4. To remove an assignment, locate the person under Current Branch Members, choose Remove, review the selection and select Remove selected.
5. In a connected implementation, reload the branch and member records to confirm each result.

Assignment replaces the previous branch. Removal leaves the person in the workspace without a branch. The backend requires the target branch to be active for assignment, and requires an active membership for both assignment and removal. A removal must name the person's current branch.

The design demonstrates available members without a branch. The backend also permits moving an active member from another branch, but the inspected selection screen does not establish a complete cross-branch selection journey. Do not assume that a person absent from the picker cannot be moved; ask an administrator or support team to verify the intended supported path.

The backend accepts one member per request. A multi-selection therefore needs individual outcome handling; this draft does not promise an all-or-nothing bulk change. After a partial failure, confirm each person's current branch before retrying only the unresolved changes.

Deactivate a branch¶

1. Open the branch detail and select Deactivate branch.
2. In the confirmation, check the branch name, affected members and Access paused consequence.
3. Confirm another eligible administrator can manage the workspace after this change. Check headquarters/reporting and enterprise-role consequences where applicable.
4. Select Deactivate, or Cancel to leave the branch active.
5. In a connected implementation, reload the branch and verify affected members' access state.

Members retain accounts, licenses and branch assignments, but lose access associated with the inactive branch. This can also affect an administrator performing the change. Notifications are requested in the background; lack of an email does not mean the change failed.

Reactivate a branch¶

1. Open the inactive branch through Review.
2. Select Reactivate branch.
3. Check the branch and affected members in the confirmation, then select Reactivate.
4. Verify the branch is active and review any remaining access restrictions for its members.

Reactivation clears this branch restriction. It does not reactivate an account, repair a suspended workspace, purchase a missing product license or automatically restore enterprise roles suspended when branch access was lost. If the branch is a former headquarters, check for another active headquarters before restoring it.

Add an organization head¶

1. Open Members, then Organization Heads.
2. Review the current heads. The empty state offers Designate an active member; the directory also provides Add Head.
3. Select Add Head and choose the intended person in Active member. The design excludes people already designated as heads.
4. Review the person, then confirm with Add Head.
5. In a connected implementation, reload the head list and check the person's member record. Where WorkOS governance is used, verify the related approval authority has synchronized.

The person's role, branch and licenses remain unchanged. Head authority does not make an ordinary member an administrator. For eligible WorkOS profiles, designation can add voting membership in the system-managed organization-head approval body; signing authority is not granted by default.

Remove an organization head¶

1. Open Members → Organization Heads.
2. Locate the correct person. Use Open Member if you need to review their membership first.
3. Select Remove Head and review the member details and impact.
4. Consider any approvals that rely on this head, especially if this is the last one. Select Remove Head to confirm, or Cancel to retain the designation.
5. In a connected implementation, confirm the updated directory and downstream approval authority.

The person remains a workspace member with the same role, branch and licenses. Their synchronized organization-head approval-body membership ends while its history remains. The current design's “label” wording understates this consequence; a design correction is pending. Zero designated heads is permitted, but may leave work without the intended leadership coverage.

Resolve an unexpected result¶

For support, provide the workspace, branch or member involved, the action and approximate time, the visible error and whether the latest record shows the change. Use an authorized support channel for personal details. Do not send passwords, sign-in codes or access tokens.

Managers and executives should confirm the outcome in current records, including leadership coverage and affected access. Platform staff should use their authorized operational process when no eligible customer administrator remains; this guide does not grant a platform role or invent a recovery control.