What's Changing in Permissions
Migration guide for the move from Curator roles to group-based permissions in Nexus
Availability depends on your school's enabled tools, provider setup, and account permissions. These settings are managed in the web workspace. A class policy may restrict a feature described here. Some options require a separately licensed feature. The presence of a guide does not unlock that feature.
Nexus permissions now use groups instead of the old Curator role model. This page is for customers migrating from Curator and Global Curator roles.
These changes apply when upgrading to Nexus v4.7 or later. For older versions, see Users and Groups before v4.7.
For the day-to-day permission model, see Understanding Permissions.
What's Being Removed#
The following legacy roles and settings are removed:
Curator role
Global Curator role
CURATORS_CANNOT_VIEW_OR_EDIT_NON_OWNED_ASSISTANTSenvironment variable
The Curator roles are removed, but the scoped management capability they provided is preserved through Group Managers.
What Replaces Curators#
The new system uses two mechanisms:
Group permissions#
Permissions granted to a group. These apply organization-wide to every member of that group.
Group Managers#
Management access granted to a specific user from a group detail page. This is scoped to that one group.
Group permissions are organization-wide. If you want one person to manage only one group's resources, make that person a Group Manager on the group detail page instead of granting a group-wide manage permission.
Before and After#
| Old system | New system |
|---|---|
| Admin role | Member of the Admin group. |
| Basic role | Member of the Basic group. |
| Curator role | Group Manager of the groups they curated. |
| Global Curator role | Group Manager in each group they managed, or a group with organization-wide permissions if broad access is intended. |
The only default groups are Basic and Admin. Custom groups can be created when you need additional permission sets.
Custom groups and configurable group permissions are an Enterprise Edition feature.
What Happens During Upgrade#
The migration handles the core role conversion automatically:
Admins move to the Admin group#
Users with the legacy Admin role are added to the Admin group and keep full workspace access.
Basic users move to Basic#
Users with the legacy Basic role are added to the Basic group and keep core workspace access.
Curators become Group Managers#
Existing Curators and Global Curators are converted to Group Managers for the groups they managed. Their scoped management access carries over.
Existing groups are preserved#
Existing custom groups, group memberships, connectors, document sets, and agents are preserved.
Document access is unchanged#
Search visibility continues to follow connector access settings: Private, Public, and Auto Sync Permissions.
The automatic Curator conversion applies to groups that exist at upgrade time. For groups created later, assign Group Managers manually from the group detail page.
What You Need to Check#
After upgrading, review the following:
Former Curators and Global Curators are Group Managers of the expected groups.
Users who need full administration are in Admin.
Regular users are in Basic.
Organization-wide permissions are granted only to groups that should have workspace-wide access.
New groups have Group Managers assigned manually when scoped management is needed.
Common Migration Questions#
What if we were not using Curators?#
If you only used Admin and Basic roles, there is little to review. Admin users move to Admin, and Basic users move to Basic.
Do existing groups and resources change?#
Existing groups, memberships, connectors, document sets, and agents are preserved. The migration changes how management permissions are represented, not the resources themselves.
Can we recreate Curator-like behavior?#
Yes. Make the user a Group Manager of the relevant group. This gives scoped management over that group's members and resources.
When should we use group permissions instead?#
Use group permissions when the access should be organization-wide. For example, grant Manage Connectors & Document Sets to an IT group only if that group should manage connectors and document sets across the workspace.
What happens to API keys and service accounts?#
Existing Admin API keys move with Admin access, and Basic API keys move with Basic access. After upgrading, you can assign service accounts to groups for more granular access.