Manage a user's access across companies in 6am

Outcome and boundaries

One login may belong to several companies, with an independent role in each. Grant only approved memberships, review effective permissions and remove access from the intended company without removing access elsewhere. This procedure covers company membership, not deletion of the person's platform account.

The responsible administrator needs permission to manage members in every company they will change. A company administrator is not automatically a platform administrator and does not gain access to all client companies. Keep an approved matrix of person/email × company × role × business reason × review date.

01. Map and grant memberships

1. Sign in at app.6am.ag. List the exact companies the person needs and the minimum role for each. Do not assume the same role is appropriate everywhere.
2. Select the first company in the company menu. In Team management → Company members, verify whether the person already belongs to it.
3. For a missing membership, follow SOP 006. Invite the same verified email separately in each approved company. A single invitation does not select or grant multiple companies.
4. Have the recipient accept each invitation and confirm the company switcher shows only their actual memberships. Record the role for each company. If a company is absent from your own menu, request access from its administrator rather than changing identifiers in a URL.

02. Change a member's role

1. Select the correct company and open Company members. Search by email and confirm the identity and company together.
2. Choose Change role, select a permitted role and save. Check the role displayed after saving; refresh the member's session and test one allowed and one forbidden action.
3. You cannot change your own role from this screen or grant capabilities you do not possess. Ask another authorized administrator for changes to your own role. The last administrator cannot be demoted: assign another approved administrator first, verify their access, then review the previous role.
4. A role change affects this membership only. Recheck direct and team permissions when applicable; replacing a role does not erase those independent grants. User has no administrative or CRM permissions by default, while Admin is broad. Arrange a suitable custom role before granting access when those defaults do not fit.

03. Remove access safely

1. Before offboarding, transfer open opportunities, follow-up tasks and operational responsibilities using the relevant CRM screens. Member removal does not automatically reassign commercial work.
2. Select the company, search the member and choose Remove from company. Read the confirmation: this removes that membership and cancels pending invitations for the same email in this company. Other company memberships remain.
3. Confirm only the approved scope. You cannot remove yourself or the last administrator through this flow. If the action is unavailable, use another authorized administrator and preserve an administrator in the company.
4. Reload Company members and confirm the person is absent. Their next server request must no longer access that company; a previously open browser tab is not evidence of continuing permission. Ask them to refresh or sign in again and check that the company is no longer available.
5. Inspect Invitations and cancel any other mistaken pending invitations. If the offboarding applies to multiple companies, repeat in each approved company. Do not delete the global user account as a substitute for company-specific removal.

04. Acceptance checklist

• The selected company name matches the approved access matrix at every change.
• A person approved for companies A and B can switch between those companies; their roles can differ.
• Changing or removing access in A preserves membership and role in B.
• An unapproved company cannot be accessed by replacing a URL identifier.
• An administrator with revoked management permission cannot continue making changes through a stale screen.
• Self-removal, self-role changes and removal/demotion of the final administrator are blocked.
• Pending invitation history remains available; cancelled or expired invitations do not restore access.
• Ownership of commercial work and the internal access register have been reviewed.

Perform permission tests with controlled synthetic accounts before customer rollout. Record the company, action, resulting role/access, reviewer and review date; do not store passwords or tokens. Plan limits and seat-based billing may affect adding/removing members. This procedure does not configure SSO, automatic role synchronization, record-level sales permissions or bulk deletion of user accounts.

Review the matrix when duties change, when a person leaves and at the organization's agreed review interval. The SOP's public Last reviewed date describes this document's review; it does not replace the review date of an individual's access.