A university web platform can carry several hundred editors: faculty administrators, department secretaries, communications officers, librarians and student assistants. Drupal groups what each of them can do into roles, and grants permissions to those roles rather than to individuals. In this article we set out a role structure that matches how a campus is organised, how to give each department editorial control over its own pages, which permissions grant far more than their names suggest, and how to take access away when people move on.
Most guidance on this subject explains the mechanics well enough and then stops at a generic example. That leaves the harder question unanswered: how do you translate an organisation with faculties, departments, research centres and rotating student staff into a permission scheme that a small central team can actually maintain? Below we work through that translation, naming the core permissions and contributed modules involved at each step.
How roles and permissions work in Drupal
Every action on a Drupal site is governed by a permission. Each permission covers one action or a small group of actions, and permissions are defined by the modules that provide those actions. Rather than granting permissions to individual accounts, Drupal groups them into roles and grants the role.
That distinction matters at university scale. When a department secretary leaves, you remove a role from one account rather than auditing a list of individual permissions. When the communications office decides editors should no longer delete pages, you change one role and the decision applies to everyone holding it.
The three roles every site starts with
A new Drupal site has an anonymous user role for visitors who are not logged in and an authenticated user role that every logged-in account receives automatically. Depending on the installation profile, there is also an administrator role that is assigned every permission on the site.
Two habits follow from this. Permissions granted to the authenticated user role apply to every account you will ever create, so that role should stay close to empty on a platform with hundreds of editors. And the administrator role should be treated as a small, named group rather than a convenience for anyone who needs to get something done quickly.
The user 1 account and why nobody should work in it
The first account created during installation has the internal ID 1, and it is unlike every other account. Whatever roles it holds or does not hold, user 1 can perform every action on the site: viewing and editing all content, editing any account, changing configuration, installing and uninstalling modules and running the update script. Drupal's own documentation compares it to the root account on a Linux server. It also cannot be deleted through the administrative interface.
Drupal's documentation gives four reasons to create separate administrative accounts instead of sharing this one, and each of them lands harder at a university than at a small site.
- Actions on the site are logged. If the whole web team shares one account, the log cannot tell you who changed the homepage.
- The administrator role can be configured more safely than user 1, so a mistaken click cannot uninstall a module.
- People's responsibilities change. Roles can be added and removed from an ordinary account; shared credentials cannot be revoked from one person.
- Content authorship is recorded and often displayed. Shared accounts make it impossible to trace who wrote a page.
The practical rule is to keep user 1 credentials in the institution's password vault, use it only for recovery and platform maintenance, and give every administrator a named account with the administrator role.
Roles add up, they never subtract
A user can hold several roles at once, and permissions from those roles accumulate. There is no mechanism in core for one role to withdraw a permission granted by another.
This catches teams out regularly. A site has an editor role that can delete content, and someone decides new staff should not delete anything, so they create a restricted editor role and assign it alongside the existing one. The person now holds both, and the delete permission is still there. The only way to withhold a permission is to build a role that never had it. When a scheme starts needing subtractive logic, that is the signal to redesign the roles rather than add another one.
A role model that matches how a university actually works
Campus role structures tend to fail in one of two directions. Either there are four roles and every faculty complains that it cannot do its own work, or there are sixty roles created one request at a time and nobody remembers what half of them grant.
A structure that holds up over time usually separates two questions that are easy to conflate. What kind of work does this person do, and which part of the site do they do it in? Drupal roles answer the first question well and the second one badly, which is why the section covering editorial territory below exists.
On the first question, five levels cover most institutions:
- Platform administrator. A named group of two to four people in central IT who hold the administrator role and own configuration, modules and updates.
- Central editor. Communications and marketing staff who publish across the whole site, including the homepage and institution-level pages.
- Unit editor. Faculty and department staff who create and publish within their own area. This is the largest group by far.
- Contributor. Academics, student assistants and occasional contributors who draft content for someone else to publish.
- Viewer. Accounts that exist for access to restricted pages rather than for editing, such as staff-only policy documents.
Two tests are worth applying before adding a sixth level. Would a new role differ from an existing one by more than two permissions? And will anyone besides the requester ever hold it? A role created for one person is a permission grant with extra steps, and it will still be there years after that person has left.
Giving departments their own editorial territory
Roles answer what someone can do but not where they can do it. A unit editor role that grants edit any page will let the biology department edit the admissions pages. Solving that requires a second layer, and Drupal offers two established approaches.
Section-based access with Workbench Access
The Workbench Access module creates editorial access control based on a hierarchy you already have, typically a taxonomy of faculties and departments or the site's menu structure. Content is placed in an editorial section when it is created, users are assigned to sections by account or by role, and they can only act on content within their sections or the sections beneath them. Version 2.0.5 was released in September 2026 and supports Drupal 9, 10 and 11. Roughly eight thousand sites report using it, and its development has been sponsored by Palantir.net with support from Charles Darwin University.
Two limits in its own documentation are worth reading carefully before building around it. The module does not grant editorial privileges; it only restricts the content a user may act on, so the underlying create and edit permissions still have to be granted through roles. And it controls editing access only, not who can view published content.
The hierarchy is what makes this fit higher education. A faculty communications officer assigned to the faculty section inherits every department beneath it, while a department secretary assigned to one department sees only that. When a new research centre is created, it is added to the hierarchy rather than requiring a new role.
When Group fits better than sections
The Group module takes a different approach. Instead of placing content in a hierarchy, it creates collections that have their own membership and their own roles inside them. Someone can be an administrator of one group and a plain member of another, and group roles are separate from site-wide roles. It is used on around eighteen thousand sites.
Group suits cases where the boundary is membership rather than organisational position: a research project with named collaborators from three faculties, a conference committee, an alumni community with private content. Where the boundary follows the org chart, sections are simpler to operate.
Version choice needs care as of late 2026. The 2.x and 3.x branches support Drupal 10 and 11, the 8.x-1.x branch reached end of life alongside Drupal 10 in mid-2026, and a 4.x branch for Drupal 11.4 and above is in alpha. A platform starting now should not begin on the oldest branch.
Roles across a multisite platform
On a platform where each faculty runs its own site from one codebase, roles and users are not shared between those sites by default. Each site has its own accounts and its own role configuration, which is an advantage for autonomy and a burden for consistency: a role definition improved on one site does not improve anywhere else. Exporting role configuration and deploying it across sites keeps the definitions identical even though the accounts stay separate. We covered the wider trade-offs of that architecture in managing university websites with Drupal multisite.
This is also the point where the choice between multisite and sections becomes visible. If departments need separate sites, roles live per site. If they need separate territory within one site, sections do the work.
Permissions that quietly grant everything
Some permissions read like narrow administrative conveniences and are in practice equivalent to handing over the site. Drupal flags the most dangerous ones itself: a permission can be declared with a restricted access flag in its module definition, which makes the permissions page display a standard security warning next to it. Core uses this for permissions such as administering text formats and filters.
The warning is easy to scroll past on a page with several hundred checkboxes, so these deserve naming.
- Administer permissions. Anyone holding it can grant themselves or anyone else any permission on the site, including this one.
- Administer users. Allows editing any account. Combined with the permission above, or on a site where an administrator account can be edited, it is a route to full control.
- Administer text formats and filters. Controls which HTML is allowed and which roles may use which format. Loosening a format is how script injection gets into a site through the editor.
- Bypass content access control. Overrides every other content permission, including anything Workbench Access or Group is enforcing.
- Administer site configuration. Reaches settings that affect the whole platform, not one site section.
- Administer modules. Installing code is the most direct path to running arbitrary code on the server.
The rule that follows is short. These belong to the platform administrator role and nowhere else. When a request arrives for one of them, the useful reply is to ask what the person is actually trying to do, because the answer is almost always a narrower permission or a section assignment.
It is worth correcting one claim that circulates in older writing on this subject: that contributed modules are inherently less secure than core. Contributed modules with stable releases are covered by the Drupal security advisory policy, and the modules named in this article all carry that coverage. What does vary is maintenance status, which is stated on each project page and is the thing to check.
Letting departments manage their own people
At a few hundred editors, every account change routed through central IT becomes a queue. A department hires an administrator in September and waits a week for editing access. The instinctive fix is to give the department head the ability to manage users, which means granting administer users and administer permissions, which means the department head can now grant themselves anything.
The Role Delegation module exists for this. It creates a separate assign permission for each role on the site, so a faculty administrator can be given the ability to assign the contributor role and nothing else. They see a role assignment widget on account forms and bulk operations on the user list, without holding administer permissions at all. It is reported on more than fifty thousand sites and its current release supports Drupal 10.3 and 11.
Delegation works best with a rule about which roles can be delegated: unit editor and contributor yes, central editor and platform administrator no. That keeps day-to-day onboarding local while the roles that carry real power stay with the central team.
Assigning roles from the campus identity system
Manual assignment does not scale on a campus, and it does not need to. When staff sign in through the institution's identity provider, the attributes released in that login can drive role assignment directly, so that membership of a directory group becomes a Drupal role without anyone touching the account. We covered the authentication side in SSO integration with SAML, Shibboleth, LDAP and CAS; what follows is what happens after the identity arrives.
Two module families provide this. The simpleSAMLphp Authentication module offers just-in-time account provisioning and automatic role assignment from SAML attributes, and is still widely deployed. Its project page now carries a minimally maintained status, and its own maintainer recommends evaluating the SAML Authentication module instead, which has a much smaller dependency chain. That second module handles role assignment through its user roles submodule, and a companion module maps SAML attributes to Group membership for institutions using groups rather than sections.
Whichever route you take, three design decisions matter more than the module choice. Decide which attribute is authoritative, usually a directory group rather than a job title field. Decide what happens on each login: whether roles are recalculated every time, which makes removal automatic, or assigned once at account creation, which does not. And keep a small set of roles outside the automated mapping, because platform administrator should be a deliberate act rather than a consequence of a directory change.
The part most institutions skip: removing access
Permission schemes are designed at launch and then only ever added to. Access accumulates: the student assistant who graduated, the officer who moved to another faculty, the agency that built the site three years ago. Every one of those accounts is still a way in.
A university has a particular version of this problem because turnover is seasonal and predictable. Student staff change each term. Academic administrative duties rotate annually. Departments merge. None of it produces a notification to the web team.
Three habits cover most of the risk.
- Tie deactivation to the identity system. If accounts are provisioned from the directory and roles are recalculated at each login, a person who loses their directory group loses their editing rights without anyone filing a request.
- Review roles on the academic calendar rather than an arbitrary date. A check at the start of each term catches student turnover while the change is recent.
- Block accounts rather than deleting them. Blocking removes access while keeping authorship intact, so the history of who wrote what survives.
A short list of who holds the platform administrator and central editor roles, reviewed once a term by a named person, is worth more than any amount of policy documentation.
Personal data and the permission layer
Once a site holds application forms, event registrations or student records pulled from another system, the permission scheme becomes a data protection control rather than an editorial convenience.
In the United States, FERPA distinguishes education records from directory information, and which fields fall into which category is a decision for the registrar rather than the web team. In the European Union and the United Kingdom, the data minimisation principle in GDPR points the same way: people should reach the data their work requires and no more.
Three implementation points follow. Field-level permission control lets a form collect a field that most editors cannot read back, which is the right shape for contact details on an enquiry form. Access to submission data should be a separate role from the ability to edit the page containing the form, because the person who maintains a programme page rarely needs the applications. And the permission to view unpublished content is broader than it looks, since drafts often contain exactly the material that has not yet been cleared for release.
Reviewing and testing a permission scheme
A permission scheme is configuration, which means it can be exported, reviewed in the same way as code and deployed rather than clicked into place on the live site. Institutions that treat it that way can answer the question of what changed, and when, months later.
Testing is the step that gets skipped. The only reliable check is to hold a test account for each role, log in as that account and try the things the role should not be able to do. Reading the permissions page tells you what you configured; using the account tells you what you built. It is worth keeping one dormant test account per role on the platform for exactly this purpose.
One boundary is worth stating clearly because it causes confusion. Permissions decide what a person is allowed to do. Editorial workflow decides what state a piece of content is in and who moves it to the next one. A contributor who can create a page but not publish it is a permission decision; a page that sits in review until an editor approves it is a workflow decision. The two work together, and we covered the second in content approval workflows for universities.
Planning your role structure
The work that determines whether a permission scheme survives is not configuration. It is deciding which units own which parts of the site, who may publish without review, which roles a faculty can assign for itself and what happens when someone leaves. Those answers come from the institution, and Drupal enforces them afterwards.
A reasonable sequence is to map existing content ownership first, define the smallest set of roles that covers the work, add a section hierarchy so those roles apply only within a unit, delegate the two lowest roles to faculties, wire assignment to the identity system, and set a review date on the academic calendar before the platform goes live rather than after.
The Drupal platforms that the Drupal4edu team at Drupart has built for institutions such as Sabanci University, METU and Yildiz Technical University are designed around exactly this layer, where a small central team keeps the platform consistent while each faculty edits its own pages. You can read more about our approach on the Drupal for education page.
Frequently asked questions about Drupal roles and permissions
What are the default user roles in Drupal?
A new Drupal site has three. The anonymous user role applies to visitors who are not logged in. The authenticated user role is given automatically to every account that logs in, and its permissions therefore apply to every user on the site. Depending on the installation profile used, there is also an administrator role that holds every permission. On a university platform, the authenticated user role should be kept almost empty and additional roles created for each kind of editorial work, because anything granted there applies to hundreds of accounts at once.
What is the user 1 account and should we use it?
User 1 is the first account created when the site is installed. It can perform every action on the site regardless of which roles it holds, which is why it is often compared to a root account, and it cannot be deleted through the administrative interface. It should not be used for daily work. Shared use of it destroys the audit trail, makes content authorship meaningless and cannot be revoked from an individual. Keep the credentials in the institution's password vault for recovery and maintenance, and give each administrator a named account with the administrator role.
How do I let editors edit only their own department's pages?
Site-wide roles cannot express this on their own, because a role that grants editing grants it everywhere. The usual solution is the Workbench Access module, which builds editorial sections from a hierarchy such as a faculty and department taxonomy. Content is assigned to a section, users are assigned to sections by account or by role, and each person can act only within their own section and those below it. The module restricts which content a user may act on rather than granting privileges, so the underlying edit permissions still come from the role.
Can Drupal roles be assigned automatically from single sign-on?
Yes, and at campus scale this is the practical approach. When a user authenticates through the institution's identity provider, attributes released in that login, typically directory group membership, can be mapped to Drupal roles so accounts are provisioned and roles assigned without manual work. The SAML Authentication module handles this through its user roles submodule, and a companion module maps attributes to Group membership. The older simpleSAMLphp Authentication module offers the same capability but is now marked minimally maintained, and its maintainer suggests evaluating the alternative.
Which Drupal permissions should never be given to editors?
Administer permissions, administer users, administer text formats and filters, bypass content access control, administer site configuration and administer modules. Each of these either grants control over the permission system itself or overrides the restrictions everything else depends on, so granting one is close to granting the administrator role. Drupal marks the most sensitive of them with a security warning on the permissions page, but that warning is easy to miss among hundreds of checkboxes. Keep them with a small named group of platform administrators, and when someone requests one, establish what task they are trying to complete first.