I need to set up a role hierarchy like this:

  • Super Admin - Full permissions, can manage all users and content

    • Regional Manager - can manage only his/her own Store Managers; cannot manage another regional manager's Store Managers. Can manage those users' content as well.
      • Store Manager - can manage only his/her own employees; cannot manage another store manager's employees. Can manage those users' content as well.
        • Employee - the low-end of the totem pole. All they can do is create content of a certain type.

How can I go about setting that up?


  • is there any workflow involved or just permissions?
    – Aboodred1
    May 4, 2013 at 15:04
  • @Aboodred1 no workflow... It's going to be an internal website so publishing of content is not something that really needs to be controlled. The only content type that will be published/unpublished by non-super-admins will be a "new lead" content type.
    – hockey2112
    May 4, 2013 at 18:34
  • @Aboodred1 did you have any further feedback on this item? Thanks!
    – hockey2112
    May 15, 2013 at 12:05
  • check this module Role Delegation
    – Aboodred1
    May 15, 2013 at 18:41

3 Answers 3


Drupal Role Hierarchy

Drupal has a robust and modular permission system. You create roles, give permissions to roles and assign users one or more roles. The modules that give the site different functionalities define the permissions and use the user_access() function to ask Drupal if the current user has a specific permission. To clarify how Drupal manages permissions lets set an example:

We have a very basic site that uses the taxonomy module, this module lets users categorize the content. Lets say we have a user called john assigned a role called Editor. Drupal uses a static variable called $perm, this variable is an array of the different permissions the current logged in user has. When we execute user_access Drupal only checks if the $perm array contains the permission we send as a parameter.

The taxonomy module only defines one permission called “Administer taxonomy”, if the Editor role has this permission then john’s $perm variable will include the string “Administer taxonomy”. When we try to access the administer taxonomy page the taxonomy module will call the user_access function sending ‘Administer taxonomy’ as the parameter. If we log in as john the function will return true and we will be able to access that page. This is a very simple example and will meet all the requirements a basic site needs because these kind of sites usually just have one or two editors.

When developing sites that are managed by more people the permissions need to be handled in a more complex way. We wish we could have a hierarchy of roles so that permissions can be inherited and we can move roles around the hierarchy tree just like we can with taxonomy terms. This is not a feature that Drupal has out of the box. Drupal only has two levels in their core role hierarchy and the permissions are inherited throughout these roles. Some of you that have used Drupal long enough know this already. The first level of Drupal roles are the default core Drupal roles that cannot be edited or removed: Anonymous and Authenthicated. Any new role created will be created as child of the authenticated role and permissions given to this role will be inherited automatically by any new role created.

I’m yet to find a module that lets the administrator handle the roles in a hierarchical way and I believe the reason for this is because Drupal does not implement the db_sql_rewrite function when pulling permissions. This means that no other modules can rewrite the query that Drupal uses when loading the permissions. Want this in your site?? A module is on its way with it’s corresponding patch file.

This just started development and it will be available in the community in a short time. But just so you know, this change has also been suggested for Drupal 7 tho I am not sure if its gonna be considered.


You could try to use Organic Groups, it's a module used in many distributions, Open Atrium probably would be the most popular.

With OG you could create groups and assign permissions to create/update content only in those groups.


This sounds like a perfect usecase for the Group module, especially in combination with its Subgroup submodule, which allows a group to belong to another group.

Some more details (from the Community documentation about subgroups):

After the subgroup module has been activated you can use it by going to the group type config page (/admin/group/type), clicking 'config' on a group type (/admin/group/type/manage/GROUPTYPE/config), and then clicking on the small 'Subgroups' tab that appears (/admin/group/type/manage/GROUPTYPE/config/subgroup) as shown in this image also:

enter image description here

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.