Setting up appropriate security groups for your TMS instance is an important, and often overlooked, function of the system administrator. I have heard of many institutions that operate TMS using only the default groups, meaning that every user has system administrator privileges. Setting up security groups is more tedium than anything else; but requires two pre-requisites: conceptualizing your security groups and settling on a naming convention.

Years ago, I set out to create a naming convention that could codify the encapsulated permissions. It was based upon the Unix system of file permissions: the permissions are expressed as a single digit, and there is a digit for each top level hierarchy node. In this system, a security group might be expressed as “7467647440”. It has two shortcomings: 1) it cannot differentiate between two security groups that have permissions to edit different sets of fields in the same module, and 2) the names become quite illegible in a drop down list.

My current schema is much simpler to use and understand.

Basic Security Groups

It starts with three basic security groups that you should be familiar with:

System Administrator	The default security group that comes with TMS.
View Only	The default security group, modified to exclude any sensitive data. These accounts do have the rights to create and modify packages and their contents.
No Rights	This is not a default security group, but it is easy enough to create. Assigning this group denotes that that admin has determined the user should not have access to a given department, whereas “(not assigned)” leaves ambiguity.

Power Series

The Power series of security groups provides users with broad access. Users have access to all fields (except those not currently in use at the institution), but do not have access to system administration functions, and cannot define new thesaurus xref types or text types. Users are also restricted from deleted top level records (ie, an object, constituent, or loan). While these groups are virtually identical, the split allows for differentiated access to packages, reports, and flex fields.

Power – Conservation	Used by conservators.
Power – Curatorial	Used by curators.
Power – Registration	Used by registrars.

Super Series

The Super series of security groups supplies superusers with broader rights than the Power series. This encompasses the ability to manage authorities and delete top level records.

Super – Conservation	Used by superusers in conservation.
Super – Curatorial	Used by superusers in curatorial.
Super – Registration	Used by superusers in registration.

Role Series

The Role series of security groups focuses on a particular role that a user will fulfill while accessing TMS. Each group here is unique, and only provides access to the fields as needed.

Role – Curatorial Intern	Most interns have permission to edit a standard number of fields.
Role – Data Scrubbing	Used by volunteers working with the system administrator to provide data scrubbing. The permissions change weekly depending upon the needs of the projects being worked on.
Role – Director’s Assistant	This security group is based upon “View Only”, but has been modified to allow the Administrative Assistant to the Director to modify certain flex fields as the Director’s proxy.
Role – Media Manager	This security group is based upon “View Only”, but permits IR staff to maintain media xrefs and object rights.

Function Series

Finally the Function series provides discrete access to perform a specific task. Whereas the Role series tend to be tied to a particular job title and duties, the Function series is reusable across a number of job titles.

Function – Create Media	Exclusively used for media departments, and allows users to create and modify media records.
Function – Unarchive	When certain departments are designated as “Archived” the majority of users have “View Only” permissions. This security group is based upon “View Only”, but permits the user to change the department.

Conclusion

The prefixes of the series provide instantaneous information about the scope of the permissions included. For instance, I can deduce that “Power – Marketing” has far greater access than “Role – Marketing”, and that “Super – Marketing” has far greater access than either of the former groups. The level of access is readily conveyed, unlike a group simply named “Marketing”.

While this may not be a system that can be universally applied to every institution, I think it provides a decent framework that is easily modified to meet the needs of most institutions. What do you think? How does this compare to your naming convention for security groups?

Thanks for taking the time to read my post – I hope you found it helpful.
Leave feedback in the comments below.

If this post save you time, then consider sharing it with your friends and colleagues. If it saved you some money, then please consider buying me a coffee. If you want to know when I publish new content, then subscribe to my feed. Your support encourages me to write more. Thanks!