User lifecycle management

Use this guide to give employees the right ChatGPT workspace access when they join, update that access when their responsibilities change, and remove access when they leave. The process also covers workspace seats, group-based roles, Codex access tokens, and connected systems with their own access controls.

Single sign-on (SSO) verifies an employee's identity. Provisioning adds the employee to a workspace. Neither action alone determines the employee's seat, feature permissions, local runtime policy, or access to an external system.

Manage employee access across three lifecycle milestones:

• Join: Provision workspace access, groups, roles, and the correct seat.
• Move: Update the employee's groups and remove only obsolete direct roles.
• Leave: Remove workspace access, revoke tokens, and review connected systems.

Verify prerequisites and assign owners

Before onboarding employees, identify who controls each part of the lifecycle:

Confirm the target workspace, verify the organization's email domain when required, and identify a workspace owner who can enable directory synchronization. Then check which controls the workspace plan supports:

SCIM stands for System for Cross-domain Identity Management. A Business workspace can support Codex access tokens without SCIM, while an Edu workspace can support SCIM without Codex access tokens or Codex-only seats. Apply only the controls available to your workspace.

A Business workspace can keep and add Codex-only seats only if it had a Codex seat before June 24, 2026, or a qualifying pending Codex-seat invitation as of that date. New Business workspaces and workspaces without a qualifying seat or invitation can't add their first Codex-only seat. See Manage workspace lifecycle and migration in ChatGPT Business.

Where the workspace supports more than one seat type, review the default in Workspace settings > Identity & access before enabling automated provisioning. SCIM-provisioned users inherit that default, and a seat controls which product surfaces are available. A custom role can't grant access that the seat doesn't include.

Use Permissions & roles to inspect local-access, access-token, credential-lifetime, and remote-device controls. Some workspaces combine local access in Codex and Work Local, with the Allow members to use Codex and Work Locally control. Others separate Codex Local, with Allow members to use Codex locally, from Work Local, with Use Work locally. Separate Codex and Work controls don't grant access to each other. Token controls appear either in the local-access section or in a separate Access tokens section. These settings are separate from group membership and assigned seat types.

The following example shows combined Codex and Work Local controls and a separate Access tokens section:

For current prerequisites and supported identity patterns, see Identity and provisioning and Manage members, seat types, roles, and access.

Choose how employees join the workspace

Choose one primary provisioning method for each audience:

Use manual invitations for a small pilot or a group that isn't managed through directory synchronization. Use SCIM when workspace membership should follow the identity provider as employees join, change teams, or leave.

Don't enable Automatic Account Creation and SCIM together. Users added through Automatic Account Creation might lack SCIM management, so removing them from an identity-provider group might not remove their workspace access. See the SCIM integration FAQ for current guidance.

SCIM can connect a single ChatGPT workspace or an organization's tenant, depending on the approved identity setup. Keep each workspace and product assignment explicit. A shared directory connection doesn't automatically grant or remove access across every workspace or Platform API organization.

Connect a provisioning group to the correct workspace

Configure the connection before adding the first pilot employee. A workspace owner and an identity administrator have separate responsibilities:

1. Have the workspace owner select the intended ChatGPT workspace and inspect Workspace settings > Groups. Record existing group names, members, custom-role assignments, and relevant project or GPT sharing.
2. Have the identity administrator identify the exact identity-provider group intended for synchronization. Compare its name and membership against every existing workspace group.
3. If a synchronized group shares a name with an existing workspace group, reconcile or rename the conflicting group before enabling synchronization. Have the workspace owner approve the resulting members, inherited roles, and sharing. A matching existing group becomes SCIM-managed, and its membership switches to identity-provider control.
4. Select a narrowly scoped pilot group and record the approved workspace, expected employees, and group-role assignments.
5. Have the workspace owner open Workspace settings > Identity & access and select Enable Directory Sync. If prompted, choose Use SCIM only for this workspace for workspace-level provisioning, or Keep the option to expand across products for approved tenant-level provisioning. If tenant-level SCIM is already active, manage that existing connection instead of creating a second workspace connection.
6. Have the identity administrator complete the identity-provider connection, select the ChatGPT application, and assign the approved group to provision members into the intended workspace.
7. In Workspace settings > Groups, confirm that the selected group displays its SCIM badge. Verify the group name, synchronized members, and target workspace before using it for access.
8. Have the workspace owner open Permissions & roles > Custom roles, create or select the approved role, and assign it to the synchronized group. Role configuration is available on the web and requires workspace owner access.
9. Review the group's effective permissions and the default workspace seat type before adding a representative pilot employee.

The identity-provider administrator controls application and group membership; the workspace owner controls directory synchronization and workspace role assignment. See the SCIM integration FAQ and Configure role-based access control for current provider-specific steps and availability.

Provision a new employee

For an employee managed through SCIM:

1. Confirm the intended workspace, verified email address, default seat type, and identity-provider group.
2. Assign the employee to the ChatGPT application or access-granting group in the identity provider.
3. Allow the directory synchronization to complete. Check the current identity-provider status if the employee doesn't appear.
4. In Workspace settings > Members, verify the employee's email, membership or pending invitation, seat type, and SCIM badge.
5. In Workspace settings > Groups, confirm the employee belongs to the intended synchronized group. Have the workspace owner verify the custom role assigned to that group.
6. Have a representative employee sign in to the correct workspace and verify the specific product surfaces, features, and connected systems they need.
7. Record the access owner and the successful verification using your organization's approved process.

If you add an employee manually, send the invitation from workspace member administration, then perform the same seat, group, role, and sign-in checks.

A group organizes members but doesn't grant access to every feature by itself. For the current role-assignment procedure, see Roles and workspace permissions and Configure role-based access control.

Update access when an employee changes teams

An employee who changes teams can keep access from previous group or role assignments. Update the source that owns the membership before verifying the new access level:

1. Identify the employee's new team, required workspace, seat, approved feature permissions, and destination group.
2. Add the employee to the approved destination group before removing them from their previous group if they must remain in the workspace throughout the change. Update SCIM-managed membership in the identity provider; update manually managed membership through workspace administration.
3. Confirm that the approved role is already assigned to the destination group. Preserve existing role assignments on shared groups so the other members keep their approved access.
4. Have a workspace owner change a group-to-role assignment only after approving a separate group-wide policy change and reviewing its effect on every member.
5. Have a workspace owner open the employee's profile, review Direct roles, and remove outdated roles assigned directly to that person. Custom roles use Default, On, and Off. An explicit Off in any assigned role overrides On in another role.
6. Review the employee's effective permissions across all direct and group-assigned roles before approving the team change.
7. If the workspace supports more than one seat type, have a workspace owner open Workspace settings > Members > Change seat type and review the employee's intended product access.
8. Before converting a ChatGPT seat to a Codex-only seat, confirm that the employee should lose access to chats, memories, projects, and other ChatGPT features. The underlying data isn't deleted and becomes available again if the employee returns to a ChatGPT seat.
9. After synchronization and permission updates complete, verify both the newly allowed actions and the actions that should no longer be available.

If the employee owns an automation workflow, review whether its Codex token, secret-manager entry, or connected-service authorization should move to another approved owner. Removing the employee's local Codex permission suspends that employee's Codex tokens but doesn't revoke them. Restoring the permission reactivates those tokens, so revoke credentials that must lose access permanently.

Remove a departing employee

Start with the system that owns the employee's workspace membership:

1. Determine whether SCIM manages the employee or an administrator added the employee manually.
2. For a SCIM-managed employee, remove that employee's ChatGPT application assignment and remove the employee from every access-granting provisioning group in the identity provider. Don't remove the shared groups themselves.
3. For an employee who isn't managed through SCIM, have a workspace owner or admin remove the member from Workspace settings > Members.
4. Confirm that the member is no longer present in the intended workspace. For SCIM-managed access, verify that synchronization completed and that no other identity-provider assignment can restore the membership.
5. Record the completed removal and assign an owner to review tokens, connected systems, and retained data.

Don't rely on a workspace-side removal when the identity provider still assigns the employee to a SCIM-managed group. A later synchronization can add the employee back to the workspace.

Revoke Codex access tokens and transfer automation

Removing a person from the workspace doesn't replace an explicit review of credentials used by trusted automation. Apply this procedure only when the workspace supports and enables Codex access tokens.

Removing local Codex permission suspends existing tokens but doesn't revoke them. Those tokens can work again if a workspace owner restores the permission, so explicitly revoke credentials that must lose access permanently.

The Access tokens page identifies each token's creator and status. Use Revoke to remove access from active tokens:

1. Have a workspace owner or admin open Access tokens.
2. Identify tokens created by the departing employee and the workflows using those tokens.
3. Choose the replacement identity. For a durable non-human workflow on an eligible pay-as-you-go plan, use an approved dedicated service account. Otherwise, identify an approved active workflow owner. Have a workspace owner grant that person access-token creation permission if needed and confirm that the person has local Codex permission.
4. Create the replacement token. A permitted service-account operator can create a token from the service account's detail page. For a personal replacement, have the new workflow owner create a token for their own ChatGPT workspace identity. If the dialog shows Scopes, select Codex. Select other scopes only when the workflow requires them. A dialog without Scopes creates a Codex-only token. An administrator can't create a personal token on another user's behalf.
5. Update the workflow's stored secret, then verify that it runs successfully with the replacement token.
6. Have the workspace owner or admin revoke the departing employee's tokens and any replaced credentials.
7. Confirm that the revoked tokens can no longer start new authenticated runs.

When an approved replacement owner creates a token, use a descriptive workflow name and choose the shortest credential lifetime allowed by your organization's policy. If Scopes appears, select Codex and avoid permissions the workflow doesn't require. The following example shows the scoped interface:

Workspace owners and admins can revoke any token in their workspace. A member with access-token permission can revoke only tokens they created. For current token permissions and rotation steps, see Access tokens.

Review connected systems and retained data

Workspace provisioning doesn't manage every authorization boundary. Ask the relevant service owner to review access to:

• Source repositories and connected GitHub accounts.
• Google Drive, Slack, and other connected applications.
• Installed plugins, bundled skills, and connector-backed capabilities.
• Hosted Codex environments, shared automation, and stored secrets.
• Managed devices, locally stored credentials, and supported remote sessions.
• Separate Platform API organizations, projects, and API keys.

Apply the controls owned by each system instead of assuming that a workspace group or SCIM change updates permissions everywhere. See Roles and workspace permissions for the complete boundary model and Plugin controls for plugin availability, bundled skills, and connected-app permissions.

Removing workspace access isn't the same as deleting content. When a member leaves, the workspace automatically reassigns their projects and custom GPT ownership to a workspace owner. Those items aren't flagged for deletion. If the member rejoins, ownership returns to that member.

For Enterprise and Edu workspaces, chats, files, and canvas documents follow the configured workspace retention policy. Business workspaces keep chats, files, and canvas documents indefinitely. Healthcare workspaces also provide data retention controls; review the applicable workspace configuration and ChatGPT for Healthcare guidance.

Reassigning a project or GPT doesn't transfer the former member's private conversations or files, and the workspace owner can't view that private content through the ownership change. See Workspace member removal and data retention for current plan-specific behavior.

If security or compliance requires evidence of the change, record the affected workspace, employee, identity-provider assignment, completion time, approval owner, and token-revocation verification in the approved system. Confirm available records, administrator permissions, and retention in the authenticated Admin API reference. Sensitive compliance scopes can require a workspace owner. For the product overview, see Compliance API and audit events. Don't infer event coverage, fields, or retention periods from this guide.

Troubleshoot missing or unexpected access

Most identity providers synchronize every 30 to 40 minutes, although some apply updates immediately. Custom-role changes can take about five minutes to appear. You can't force a SCIM synchronization, so don't remove and recreate a workspace member to work around a delayed update.

If an access removal or group update still hasn't completed after the expected provider-specific window, have the identity administrator collect:

• The affected workspace and employee email address.
• The identity provider, application assignment, and provisioning group.
• The attempted change, its timestamp, and the latest synchronization status.
• The direct roles, group roles, or tokens that still need review.

Contact OpenAI Support with those details through the Help Center. Treat a departed employee who retains access as a security exception and follow your organization's incident-escalation process.

For provider-specific setup and synchronization behavior, use the current SCIM integration FAQ. For sign-in and identity errors, see Troubleshooting authentication.

Verify the complete employee lifecycle

Use a representative test employee to verify all three transitions before a broader rollout:

Record who approved each change, what you verified, and which owner is responsible for resolving any remaining access exceptions. Schedule recurring access reviews according to your organization's identity and security policies.

Related docs

• Admin rollout guide
• Groups and provisioning
• Roles and workspace permissions
• Plugin controls
• Access tokens
• Service accounts
• Authentication
• Managed configuration
• Compliance API and audit events