Best practices for ChatGPT Edu workspace configuration in higher education

Configure campus access with five recommended custom roles: Core, Plus, Advanced, Power, and TEST. Use the matrices below to choose each role’s permissions, then set model access and usage limits separately.

The permission labels and section order follow Edu Admin Console views reviewed on October 19 and 21, 2026. The values are recommended settings, not a copy of that workspace’s configuration. Feature availability can differ by workspace and rollout.

Choose the recommended roles

These are suggested names for custom roles your institution can create. Plus here is not the ChatGPT Plus subscription, and none of these names refers to an Edu plan or built-in admin role. Choose a role based on the work a person needs to do; a professor, student, or staff member can qualify for any appropriate level.

Keep most people in the built-in Member role. Assign built-in administrative authority separately:

Have a workspace Owner create and assign custom roles. A custom role does not confer Owner or Admin authority. See workspace roles.

Apply the matrix

Open Admin Console, select the intended Edu workspace, then go to Policy & security → Permissions. Use Workspace default for the campus baseline and Roles for overrides.

Set Workspace default to match the Core column, with Review items Off until resolved. For each custom role, use Default only where the workspace value is the intended value; otherwise set an explicit On or Off. Some controls offer only On and Off.

Ordinary roles combine grants: Off in one role does not cancel On in another. Check both direct assignments and group roles. A separate Lockdown Mode restriction can still apply. Parent permissions may hide their child controls when disabled; enable an approved parent before configuring its children. How RBAC works.

Permissions by role

Choose a role to show its recommendations in every permission and model table. Select All roles to compare the full matrix. The sections follow the order in Permissions → Workspace default. The two Allow local computer access rows are distinguished by their parent section.

Chat

Keep everyday learning, research, and collaboration available across roles. Apply institutional rules for recordings, screen sharing, stored files, and network-connected code. For Review items, identify the approved course, team, workflow, and sharing audience before enabling those permissions.

Give agent-building access to people maintaining an approved workflow. Reserve workspace-wide publication for designated publishers. An agent-owned connection requires a separate review of the shared account, source data, permitted actions, and recipients; prefer users’ own connections where supported. For details, see Workspace agent administration.

Use plugins for new reusable workflows. Keep GPT creation off; grant temporary migration access only where still supported. Custom GPTs are scheduled to retire on December 11, 2026; follow the owning workspace’s notice. Migration does not transfer custom actions or sharing settings. For details, see GPT migration guidance.

Work

This follows the recommended setup’s broad Work access for eligible members. Local work, cloud work, and a cloud task’s access to a connected computer remain separate decisions. Enable Allow local computer access only for approved files, applications, and devices, with the applicable Agent security configuration.

For event-triggered tasks, approve the trigger, connected app, allowed actions, owner, and monitoring. Members also need Work and app access. Sharing scheduled tasks is controlled separately in Chat. Work and Codex availability · Scheduled-task controls.

Codex

Provide coding access across eligible roles, including students in coding courses. Review repository access, local runtime policy, and cloud environments separately. Device-code sign-in affects all four products named in the control.

Review Computer History capture and user opt-in before granting access to Computer History. Grant Manage workspace environments, Administer Codex, and Administer Codex Security through the specific responsibility roles below. A Power or TEST assignment should not automatically grant service administration. For details, see Codex permission boundaries.

Workspace capabilities—Let agents use cloud computers

Before enabling a control, review how it affects Work Cloud, dots, and team automations. Browser access, network access, and computer use are separate controls. Approve required network destinations and applications for each workflow.

Workspace capabilities—dots

Dots is labeled Beta in the inspected console. Approve the ongoing responsibilities, messaging destinations, and rules before enabling it. The Allow local computer access row here is the dots permission; it is separate from the identically named Work control. Read the dots guidance.

Workspace capabilities—plugins and skills

Use Plugins → Plugins and Plugins → Skills to approve individual items and their audiences. MCP-backed plugins require an integration owner, reviewed authentication, and approved data access and actions. Use the additional roles below to assign responsibility for publishing items to the workspace and installing them for other people.

Plugin access does not authorize included apps or broaden permissions in the connected service. Review required apps and account authorization separately. For details, see Plugin and app controls.

Workspace capabilities—Sites

Review site ownership, permitted content, and the displayed Sites terms before enabling those permissions. Grant permission to publish sites to the public internet through the institution’s publishing process. Treat the two private-tunnel controls as separate grants for approved technical integrations; keep them off in the general campus roles. Their presence in a demo workspace does not establish availability in every Edu workspace.

Check the supported Sites scope for your workspace and region before enabling Sites. New Sites in US or EU data residency workspaces use that region for supported storage and hosting; existing Sites are not automatically migrated. Sites hosting is separate from inference residency. See Sites administration.

Workspace capabilities—teams, memory, and credentials

Assign an accountable owner to each team and team task. Define which institutional information may be retained in memory and whether the directory should be visible to the intended population. If institutional policy requires either feature to be off, change the corresponding row for every affected role.

Review password-manager use with IT. Allow personal access tokens only for approved integrations with an owner, the minimum necessary scope, and an expiration or revocation process. A token permission does not grant workspace Admin keys.

Data export

Decide how students, faculty, and staff take permitted work with them when leaving. This permission covers members’ own data. Edu workspaces with a data residency configuration are not eligible for member export. For details, see Edu export requirements.

Teen experiences

Choose the setting based on the actual population, including under-18 students. A role name, credit allowance, or filter setting does not determine eligibility to use ChatGPT.

Space sharing

Allow collaboration with approved recipients. Review whether workspace links fit the audience for course materials, research, and departmental files. The sharing permission controls creating shares and changing access; turning it off does not remove access to content already shared with a member.

Assign publishing and administration responsibilities

Assign narrowly scoped roles to the appropriate people instead of granting these capabilities to everyone in Power or TEST. Keep unrelated permissions Off in each additional role so it does not inherit broader workspace grants.

For example, a faculty member may receive Plus and Workspace publisher, while a student in a programming course receives Core with Codex access. Increasing a researcher’s credit allowance does not require giving them publishing or administration permissions.

Model access by role

Open Policy & security → Models. Configure Workspace default, then use Roles for role-specific settings. The table uses the model names and preference labels shown in the console we inspected. Enable only models available to your workspace.

Model recommendations: Keep 5.6 Sol available for ordinary Chat and 6 Luna for routine Work and Codex. Keep 5.6 Luna as a fallback where needed. Enable 6.1 Sol and 6 Sol for Power workflows, and review them for Advanced users. Approve Astra/Pro access and faster modes based on the expected work and budget. Keep Daybreak Blue outside general campus roles; consider a separately approved security role only where eligible.

A model being listed or enabled in the demo does not establish access for every Edu workspace or every product. In particular, 6.1 Sol and 6 Luna are Work and Codex options, not regular Chat defaults. Use Models → Test to check model access for the intended member. See current model availability.

Defaults by product

A starting default does not grant model access. Allow medium/high/extra high effort and Allow Pro models apply to Chat; Allow fast mode and Allow Ultra Fast mode apply to Work & Codex. Members can select other permitted options. Review role overrides for each product separately.

Set usage limits independently

Use Billing → Usage limits to configure member limits through workspace defaults, group defaults, and user overrides. Review the shared credit pool and workspace overage limit separately in Billing. The amounts below illustrate credit-based limits; approve them based on your institution’s agreement, purchased credits, expected activity, and the displayed limit period.

A group’s usage limit does not create a permission role or grant features. Use corresponding groups when membership matches, and separate groups when access and budget needs differ. Set the fallback for unassigned users to the intended campus baseline.

For credit-based agreements, keep workspace overages at 0 unless additional spending is approved. User overrides take precedence over group limits; otherwise, the highest applicable group limit takes precedence over the workspace default. Alerts notify recipients but do not stop usage. Running work can settle after a limit is reached. See Usage limits and overages.

Use the current rate card for included allowances and chargeable usage.

Use the Admin plugin to prepare and check changes

The Admin plugin can review roles and permissions and, after confirmation, assign an existing role to an existing group. It cannot create roles or edit their permissions. Configure the roles and permissions in Admin Console first. See Admin plugin scope.

Attach your institution’s approved matrix, resolve every Review item, and replace the placeholders below.

Compare the workspace with the matrix

Assign a configured role to a group

Verify assignments and overlaps

Configure and verify

1. In Identity & access → Groups & roles → Roles, select Add role. Enter a role name and description, then select Create role. Create only the roles your institution needs.
2. In Policy & security → Permissions → Workspace default, apply the Core baseline. In Roles, open each role and apply the approved matrix values. Select Save changes.
3. In Groups & roles → Roles, open the role. Use Role groups → Add group to assign the intended groups. Manage SCIM-synchronized membership in the identity provider.
4. Configure Models → Workspace default and Models → Roles, then set usage limits. Approve individual plugins, apps, skills, and source-system access separately.
5. Use Permissions → Permissions by roles to compare assignments and Test to inspect effective access. Allow up to five minutes for permission updates. Use Models → Test to check model access.
6. Verify actual workflows with representative members, including someone with overlapping roles. Use the TEST custom role to exercise allowed actions and attempt intentionally blocked actions, then remove temporary grants.

The comparison view can retain older labels that differ from the editable permission page. Configure shared cloud-computer access in Workspace capabilities → Let agents use cloud computers using Use a browser, Allow network access, and Allow computer use.

Review roles each term and whenever a new permission appears. Where Admin preview is offered, decide preview access and launch access separately. General workspace settings, identity policies, Agent security, app actions, and retention remain separate from these role matrices.