1# User lifecycle management
2
3> For the complete documentation index, see [llms.txt](https://learn.chatgpt.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to the page URL.
4
5Use this guide to give employees the right ChatGPT workspace access when they
6join, update that access when their responsibilities change, and remove access
7when they leave. The process also covers workspace seats, group-based roles,
8Codex access tokens, and connected systems with their own access controls.
9
10Single sign-on (SSO) verifies an employee's identity. Provisioning adds the
11employee to a workspace. Neither action alone determines the employee's seat,
12feature permissions, local runtime policy, or access to an external system.
13
14Manage employee access across three lifecycle milestones:
15
16- **Join:** Provision workspace access, groups, roles, and the correct seat.
17- **Move:** Update the employee's groups and remove only obsolete direct roles.
18- **Leave:** Remove workspace access, revoke tokens, and review connected systems.
19
20## Verify prerequisites and assign owners
21
22Before onboarding employees, identify who controls each part of the lifecycle:
23
24| Owner | Responsibility |
25| ------------------------- | ----------------------------------------------------------------------------------------------------- |
26| Workspace owner | Enable directory synchronization, assign workspace roles, approve seat types, and review audit access |
27| Identity administrator | Configure the identity provider, application assignments, provisioning groups, and sync status |
28| Workspace administrator | Review workspace members, group membership, and supported administration settings |
29| Security or service owner | Review Codex tokens, connected systems, shared automation, and required audit evidence |
30
31Confirm the target workspace, verify the organization's email domain when
32required, and identify a workspace owner who can enable directory
33synchronization. Then check which controls the workspace plan supports:
34
35| Capability | Supported workspace plans |
36| ------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
37| Directory synchronization through SCIM | ChatGPT Enterprise, Edu, and Healthcare |
38| Custom roles and role-based access control | ChatGPT Enterprise, Edu, Healthcare, and Teachers |
39| Codex access tokens | ChatGPT Business and Enterprise |
40| Codex-only seats | Eligible Enterprise and qualifying existing Business workspaces; unavailable to Edu, Teachers, or Healthcare |
41
42SCIM stands for System for Cross-domain Identity Management. A Business
43workspace can support Codex access tokens without SCIM, while an Edu workspace
44can support SCIM without Codex access tokens or Codex-only seats. Apply only
45the controls available to your workspace.
46
47A Business workspace can keep and add Codex-only seats only if it had a Codex
48seat before June 24, 2026, or a qualifying pending Codex-seat invitation as of
49that date. New Business workspaces and workspaces without a qualifying seat or
50invitation can't add their first Codex-only seat. See
51[Manage workspace lifecycle and migration in ChatGPT Business](https://help.openai.com/en/articles/8801890-managing-workspace-lifecycle-and-migration-in-chatgpt-business).
52
53Where the workspace supports more than one seat type, review the default in
54**Workspace settings > Identity & access** before enabling automated
55provisioning. SCIM-provisioned users inherit that default, and a seat controls
56which product surfaces are available. A custom role can't grant access that
57the seat doesn't include.
58
59Use **Permissions & roles** to inspect local-access, access-token,
60credential-lifetime, and remote-device controls. Some workspaces combine local
61access in **Codex and Work Local**, with the **Allow members to use Codex and
62Work Locally** control. Others separate **Codex Local**, with **Allow members
63to use Codex locally**, from **Work Local**, with **Use Work locally**.
64Separate Codex and Work controls don't grant access to each other. Token
65controls appear either in the local-access section or in a separate **Access
66tokens** section. These settings are separate from group membership and
67assigned seat types.
68
69The following example shows combined **Codex and Work Local** controls and a
70separate **Access tokens** section:
71
72
73
74> Illustration: ChatGPT Permissions & roles showing Codex and Work Local access, personal access tokens, and the access token expiration limit.
75
76
77
78For current prerequisites and supported identity patterns, see
79[Identity and provisioning](https://help.openai.com/en/articles/9672121)
80and [Manage members, seat types, roles, and access](https://help.openai.com/en/articles/8266401-managing-members-seat-types-roles-and-access-in-chatgpt-enterprise).
81
82## Choose how employees join the workspace
83
84Choose one primary provisioning method for each audience:
85
86| Method | How access begins | Where to remove access |
87| -------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------- |
88| Manual invitation | A workspace owner or admin invites an employee | Workspace member administration |
89| Automatic Account Creation | An employee with an eligible email domain signs in | Workspace administration and the relevant identity flow |
90| Directory Sync with SCIM | An identity administrator assigns the employee in the identity provider | The identity-provider application or provisioning group |
91
92Use manual invitations for a small pilot or a group that isn't managed through
93directory synchronization. Use SCIM when workspace membership should follow
94the identity provider as employees join, change teams, or leave.
95
96Don't enable Automatic Account Creation and SCIM together. Users added through
97Automatic Account Creation might lack SCIM management, so removing them from
98an identity-provider group might not remove their workspace access. See the
99[SCIM integration FAQ](https://help.openai.com/en/articles/10011769-openai-platform-scim-integration-faq)
100for current guidance.
101
102SCIM can connect a single ChatGPT workspace or an organization's tenant,
103depending on the approved identity setup. Keep each workspace and product
104assignment explicit. A shared directory connection doesn't automatically grant
105or remove access across every workspace or Platform API organization.
106
107## Connect a provisioning group to the correct workspace
108
109Configure the connection before adding the first pilot employee. A workspace
110owner and an identity administrator have separate responsibilities:
111
1121. Have the workspace owner select the intended ChatGPT workspace and inspect
113 **Workspace settings > Groups**. Record existing group names, members,
114 custom-role assignments, and relevant project or GPT sharing.
1152. Have the identity administrator identify the exact identity-provider group
116 intended for synchronization. Compare its name and membership against every
117 existing workspace group.
1183. If a synchronized group shares a name with an existing workspace group,
119 reconcile or rename the conflicting group before enabling synchronization.
120 Have the workspace owner approve the resulting members, inherited roles, and
121 sharing. A matching existing group becomes SCIM-managed, and its membership
122 switches to identity-provider control.
1234. Select a narrowly scoped pilot group and record the approved workspace,
124 expected employees, and group-role assignments.
1255. Have the workspace owner open **Workspace settings > Identity & access**
126 and select **Enable Directory Sync**. If prompted, choose **Use SCIM only
127 for this workspace** for workspace-level provisioning, or **Keep the option
128 to expand across products** for approved tenant-level provisioning. If
129 tenant-level SCIM is already active, manage that existing connection
130 instead of creating a second workspace connection.
1316. Have the identity administrator complete the identity-provider connection,
132 select the ChatGPT application, and assign the approved group to provision
133 members into the intended workspace.
1347. In **Workspace settings > Groups**, confirm that the selected group displays
135 its SCIM badge. Verify the group name, synchronized members, and target
136 workspace before using it for access.
1378. Have the workspace owner open **Permissions & roles > Custom roles**,
138 create or select the approved role, and assign it to the synchronized group.
139 Role configuration is available on the web and requires workspace owner
140 access.
1419. Review the group's effective permissions and the default workspace seat
142 type before adding a representative pilot employee.
143
144The identity-provider administrator controls application and group membership;
145the workspace owner controls directory synchronization and workspace role
146assignment. See the [SCIM integration FAQ](https://help.openai.com/en/articles/10011769-openai-platform-scim-integration-faq)
147and [Configure role-based access control](https://help.openai.com/en/articles/11750701-rbac)
148for current provider-specific steps and availability.
149
150## Provision a new employee
151
152For an employee managed through SCIM:
153
1541. Confirm the intended workspace, verified email address, default seat type,
155 and identity-provider group.
1562. Assign the employee to the ChatGPT application or access-granting group in
157 the identity provider.
1583. Allow the directory synchronization to complete. Check the current
159 identity-provider status if the employee doesn't appear.
1604. In **Workspace settings > Members**, verify the employee's email,
161 membership or pending invitation, seat type, and SCIM badge.
1625. In **Workspace settings > Groups**, confirm the employee belongs to the
163 intended synchronized group. Have the workspace owner verify the custom
164 role assigned to that group.
1656. Have a representative employee sign in to the correct workspace and verify
166 the specific product surfaces, features, and connected systems they need.
1677. Record the access owner and the successful verification using your
168 organization's approved process.
169
170If you add an employee manually, send the invitation from workspace member
171administration, then perform the same seat, group, role, and sign-in checks.
172
173A group organizes members but doesn't grant access to every feature by itself.
174For the current role-assignment procedure, see
175[Roles and workspace permissions](https://learn.chatgpt.com/docs/enterprise/roles-and-workspace-permissions)
176and [Configure role-based access control](https://help.openai.com/en/articles/11750701-rbac).
177
178## Update access when an employee changes teams
179
180An employee who changes teams can keep access from previous group or role
181assignments. Update the source that owns the membership before verifying the
182new access level:
183
1841. Identify the employee's new team, required workspace, seat, approved
185 feature permissions, and destination group.
1862. Add the employee to the approved destination group before removing them
187 from their previous group if they must remain in the workspace throughout
188 the change. Update SCIM-managed membership in the identity provider; update
189 manually managed membership through workspace administration.
1903. Confirm that the approved role is already assigned to the destination group.
191 Preserve existing role assignments on shared groups so the other members
192 keep their approved access.
1934. Have a workspace owner change a group-to-role assignment only after
194 approving a separate group-wide policy change and reviewing its effect on
195 every member.
1965. Have a workspace owner open the employee's profile, review **Direct roles**,
197 and remove outdated roles assigned directly to that person. Custom roles use **Default**,
198 **On**, and **Off**. An explicit **Off** in any assigned role overrides
199 **On** in another role.
2006. Review the employee's effective permissions across all direct and
201 group-assigned roles before approving the team change.
2027. If the workspace supports more than one seat type, have a workspace owner open
203 **Workspace settings > Members > Change seat type** and review the
204 employee's intended product access.
2058. Before converting a ChatGPT seat to a Codex-only seat, confirm that the
206 employee should lose access to chats, memories, projects, and other
207 ChatGPT features. The underlying data isn't deleted and becomes available
208 again if the employee returns to a ChatGPT seat.
2099. After synchronization and permission updates complete, verify both the
210 newly allowed actions and the actions that should no longer be available.
211
212If the employee owns an automation workflow, review whether its Codex token,
213secret-manager entry, or connected-service authorization should move to another
214approved owner. Removing the employee's local Codex permission suspends that
215employee's Codex tokens but doesn't revoke them. Restoring the permission
216reactivates those tokens, so revoke credentials that must lose access permanently.
217
218## Remove a departing employee
219
220Start with the system that owns the employee's workspace membership:
221
2221. Determine whether SCIM manages the employee or an administrator added the
223 employee manually.
2242. For a SCIM-managed employee, remove that employee's ChatGPT application
225 assignment and remove the employee from every access-granting provisioning
226 group in the identity provider. Don't remove the shared groups themselves.
2273. For an employee who isn't managed through SCIM, have a workspace owner or
228 admin remove the member from **Workspace settings > Members**.
2294. Confirm that the member is no longer present in the intended workspace.
230 For SCIM-managed access, verify that synchronization completed and that no
231 other identity-provider assignment can restore the membership.
2325. Record the completed removal and assign an owner to review tokens,
233 connected systems, and retained data.
234
235Don't rely on a workspace-side removal when the identity provider still assigns
236the employee to a SCIM-managed group. A later synchronization can add the
237employee back to the workspace.
238
239### Revoke Codex access tokens and transfer automation
240
241Removing a person from the workspace doesn't replace an explicit review of
242credentials used by trusted automation. Apply this procedure only when the
243workspace supports and enables Codex access tokens.
244
245Removing local Codex permission suspends existing tokens but doesn't revoke
246them. Those tokens can work again if a workspace owner restores the permission,
247so explicitly revoke credentials that must lose access permanently.
248
249The **Access tokens** page identifies each token's creator and status. Use
250**Revoke** to remove access from active tokens:
251
252
253
254> Illustration: ChatGPT Access tokens showing token names, their creators and status, and the Revoke action.
255
256
257
2581. Have a workspace owner or admin open
259 [Access tokens](https://chatgpt.com/admin/access-tokens).
2602. Identify tokens created by the departing employee and the workflows using
261 those tokens.
2623. Choose the replacement identity. For a durable non-human workflow on an
263 eligible pay-as-you-go plan, use an approved dedicated [service
264 account](https://learn.chatgpt.com/docs/enterprise/service-accounts). Otherwise, identify an
265 approved active workflow owner. Have a workspace owner grant that person
266 access-token creation permission if needed and confirm that the person has
267 local Codex permission.
2684. Create the replacement token. A permitted service-account operator can
269 create a token from the service account's detail page. For a personal
270 replacement, have the new workflow owner create a token for their own
271 ChatGPT workspace identity. If the dialog shows **Scopes**, select
272 **Codex**. Select other scopes only when the workflow requires them. A
273 dialog without **Scopes** creates a Codex-only token. An administrator can't
274 create a personal token on another user's behalf.
2755. Update the workflow's stored secret, then verify that it runs successfully
276 with the replacement token.
2776. Have the workspace owner or admin revoke the departing employee's tokens
278 and any replaced credentials.
2797. Confirm that the revoked tokens can no longer start new authenticated runs.
280
281When an approved replacement owner creates a token, use a descriptive workflow
282name and choose the shortest credential lifetime allowed by your organization's
283policy. If **Scopes** appears, select **Codex** and avoid permissions the
284workflow doesn't require. The following example shows the scoped interface:
285
286
287
288> Illustration: ChatGPT Create access token dialog showing Name, Scopes with Codex selected, Expiration, and the Create action.
289
290
291
292Workspace owners and admins can revoke any token in their workspace. A member
293with access-token permission can revoke only tokens they created. For current
294token permissions and rotation steps, see
295[Access tokens](https://learn.chatgpt.com/docs/enterprise/access-tokens#rotate-or-revoke-a-token).
296
297### Review connected systems and retained data
298
299Workspace provisioning doesn't manage every authorization boundary. Ask the
300relevant service owner to review access to:
301
302- Source repositories and connected GitHub accounts.
303- Google Drive, Slack, and other connected applications.
304- Installed plugins, bundled skills, and connector-backed capabilities.
305- Hosted Codex environments, shared automation, and stored secrets.
306- Managed devices, locally stored credentials, and supported remote sessions.
307- Separate Platform API organizations, projects, and API keys.
308
309Apply the controls owned by each system instead of assuming that a workspace
310group or SCIM change updates permissions everywhere. See
311[Roles and workspace permissions](https://learn.chatgpt.com/docs/enterprise/roles-and-workspace-permissions)
312for the complete boundary model and [Plugin controls](https://learn.chatgpt.com/docs/enterprise/apps-and-connectors)
313for plugin availability, bundled skills, and connected-app permissions.
314
315Removing workspace access isn't the same as deleting content. When a member
316leaves, the workspace automatically reassigns their projects and custom
317GPT ownership to a workspace owner. Those items aren't flagged for deletion.
318If the member rejoins, ownership returns to that member.
319
320For Enterprise and Edu workspaces, chats, files, and canvas documents follow
321the configured workspace retention policy. Business workspaces keep chats,
322files, and canvas documents indefinitely. Healthcare workspaces also provide
323data retention controls; review the applicable workspace configuration and
324[ChatGPT for Healthcare guidance](https://help.openai.com/en/articles/20001046-chatgpt-for-healthcare).
325
326Reassigning a project or GPT doesn't transfer the former member's private
327conversations or files, and the workspace owner can't view that private content
328through the ownership change. See
329[Workspace member removal and data retention](https://help.openai.com/en/articles/8266418)
330for current plan-specific behavior.
331
332If security or compliance requires evidence of the change, record the
333affected workspace, employee, identity-provider assignment, completion time,
334approval owner, and token-revocation verification in the approved system.
335Confirm available records, administrator permissions, and retention in the
336authenticated [Admin API reference](https://chatgpt.com/admin/api-reference).
337Sensitive compliance scopes can require a workspace owner. For the product
338overview, see [Compliance API and audit events](https://learn.chatgpt.com/docs/enterprise/compliance-api).
339Don't infer event coverage, fields, or retention periods from this guide.
340
341## Troubleshoot missing or unexpected access
342
343| Symptom | What to check | Corrective action |
344| ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
345| An employee can sign in but can't find the workspace | The target workspace, invitation, identity-provider assignment, and email address | Correct the assignment or email mapping, then verify workspace membership |
346| A synchronized employee receives the wrong seat | The default seat type for the workspace and the current member record | Have a workspace owner review the default and the employee's supported seat options |
347| A team change doesn't remove a feature | Other group memberships, **Direct roles**, and the employee's combined permissions | Remove the employee from obsolete groups, then have a workspace owner revoke only that employee's obsolete direct roles |
348| A manual group becomes SCIM-managed without approval | Matching group names, identity-provider members, inherited roles, and existing sharing | Reconcile approved group membership in the identity provider and review affected access |
349| Other employees lose access after a team change | Recent changes to shared group-role assignments and the former team's approved access | Have a workspace owner restore the approved shared group role, then update only the moving employee's membership |
350| An automation token stops working after a team change | The workflow owner's local Codex permission and current token status | Have a workspace owner restore approved local Codex access, or rotate and revoke the affected token |
351| An access change doesn't appear immediately | Identity-provider sync status, the expected sync window, and recent role updates | Have the identity administrator verify the sync before contacting OpenAI Support |
352| A removed employee returns to the workspace | The identity-provider application assignment and every access-granting provisioning group | Remove the employee in the identity provider instead of only in workspace settings |
353| A departing employee still has a listed token | The token creator, workflow owner, and workspace administrator's token permissions | Rotate any required automation credential, then revoke the departing employee's token |
354| A connected application still allows access | The source system's account, plugin availability, and application grant | Ask the relevant service owner to remove access using that system's supported controls |
355
356Most identity providers synchronize every 30 to 40 minutes, although some
357apply updates immediately. Custom-role changes can take about five minutes to
358appear. You can't force a SCIM synchronization, so don't remove and recreate
359a workspace member to work around a delayed update.
360
361If an access removal or group update still hasn't completed after the expected
362provider-specific window, have the identity administrator collect:
363
364- The affected workspace and employee email address.
365- The identity provider, application assignment, and provisioning group.
366- The attempted change, its timestamp, and the latest synchronization status.
367- The direct roles, group roles, or tokens that still need review.
368
369Contact [OpenAI Support](https://help.openai.com/) with those details through
370the Help Center. Treat a departed employee who retains access as a security
371exception and follow your organization's incident-escalation process.
372
373For provider-specific setup and synchronization behavior, use the current
374[SCIM integration FAQ](https://help.openai.com/en/articles/10011769-openai-platform-scim-integration-faq).
375For sign-in and identity errors, see
376[Troubleshooting authentication](https://help.openai.com/en/articles/10489721-login-and-authentication-faq-s-and-troubleshooting-sso-scim-and-domain-verification).
377
378## Verify the complete employee lifecycle
379
380Use a representative test employee to verify all three transitions before a
381broader rollout:
382
383| Lifecycle stage | Primary owner | Successful outcome |
384| --------------- | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
385| Joiner | Identity administrator | The employee joins the correct workspace with the intended seat, group, and feature access |
386| Mover | Identity and workspace owners | Administrators update group membership, and workspace owners remove obsolete direct roles while preserving shared group roles |
387| Leaver | Identity and security owners | Administrators remove workspace access, review supported tokens, and revoke or reassign external access |
388
389Record who approved each change, what you verified, and which owner is
390responsible for resolving any remaining access exceptions. Schedule recurring
391access reviews according to your organization's identity and security policies.
392
393## Related docs
394
395- [Admin rollout guide](https://learn.chatgpt.com/docs/enterprise/admin-setup)
396- [Groups and provisioning](https://learn.chatgpt.com/docs/enterprise/groups-and-provisioning)
397- [Roles and workspace permissions](https://learn.chatgpt.com/docs/enterprise/roles-and-workspace-permissions)
398- [Plugin controls](https://learn.chatgpt.com/docs/enterprise/apps-and-connectors)
399- [Access tokens](https://learn.chatgpt.com/docs/enterprise/access-tokens)
400- [Service accounts](https://learn.chatgpt.com/docs/enterprise/service-accounts)
401- [Authentication](https://learn.chatgpt.com/docs/auth)
402- [Managed configuration](https://learn.chatgpt.com/docs/enterprise/managed-configuration)
403- [Compliance API and audit events](https://learn.chatgpt.com/docs/enterprise/compliance-api)
