Manifest - Best Practices

A list of best practices we recommend manifest users to follow


  • Use groups for privileges, instead of adding users individually

    It is advisable to put users in groups, and assign privileges to those groups whenever possible. Often times, new users are given privileges individually. This makes managing privileges difficult in the future. In contrast, adding or (especially) removing people to a group then giving them rights to a bunch of things is far easier than adding the person to each of those things individually. In addition, this also saves the admin the trouble of having to remember what to add or to remove every time they have to add or remove someone.

  • Designate a backup administrator for your group right away to prevent abandoned or orphaned groups upon your transfer from the department or school, or departure from the University.

Abandoned groups, defined as groups without any administrators, or orphaned groups, defined as a group all of whose administrator(s) has/have left the University, may be deleted in order to maintain efficiency of the service.


  • Create subfolders instead of requesting more folders from top level

    While main folders Manifest can only be created by Manifest Service administrators, subfolders can be created by anyone with admin access to the folder it resides in. This means that subfolders can be created anytime without having to go through the approval process from the admins at Manifest Services. In addition, this helps ensure that folders are created in the right path and domain, making further management easier while also keeping organizational relationships clear.

    See Manifest - Working With Folders for more details.

  • Only request for top level folder when necessary

    It is desirable to reduce confusion and understand organizational relationships that we try to reduce the number of top level stems to make browsing more understandable. For example, conceptually separate items make sense to separate ( doesn't have to be part of, but we don't want to proliferate stems that are logically part of another (we wouldn't want to create uw:org:comp_sci_firewall_acls, but perhaps uw:org:cs_building_network_admin does make sense, as DoIT and Computer Sciences staff both have roles.)


  • Group ID - Use lowercase and underscore, and avoid having spaces

    Having spaces in Group ID may cause problems because it will result in pathing issue. We recommend using underscores to replace spaces and use lowercase only to adhere to proper computing practices

    E.g. Instead of Bucky Badger, use bucky_badger

    Note: Do no confuse group name with Group ID. Group name is the name that will be displayed for the group. Hence, it can be anything and have spaces and other characters. See Manifest - Create a Group for more details.

  • Make reusable groups. Or use past groups

    Create a group with reusability in mind. In other words, refrain from having to constantly create new groups for short term use. Similarly, users should look into past/old groups that they may reuse or repurpose before creating new groups. This is to prevent the Manifest folder from getting too cluttered with too many groups

    It also helps to manage access for users when they don't have to be in too many groups. If users are grouped in 'roles' and given access accordingly, it will be easier to manage adding and removing access for anyone later on, without having to worry about missing anything. In fact, these 'roles' should be combined with other 'access policy' groups that actually are used for end applications. For more information about the Access Control Model in Grouper, please refer to Access Control Models

  • Use data to formulate groups when possible

    For example, instead of creating a group for a department and adding everyone by hand, use UDDS groups and then add any exceptions by hand.

    Data driven groups for HR and students are available. For reference on data-driven group, see Manifest - Data Driven Groups

Keywordsmanifest subfolders subfolder naming advice privileges groups group folder folders access control models data driven   Doc ID103461
OwnerMST SupportGroupIdentity and Access Management
Created2020-06-30 09:38:43Updated2024-04-22 13:33:31
SitesIdentity and Access Management
Feedback  0   0