In my previous two posts I described the reasoning behind privileges and then gave more detail and background on each privilege and how they behave. In this post, I'll share some of our personas how you might assign them certain privileges.

• Sam, a System Administrator
• Oscar, an Application Manager
• Elaine, a Chief Content Editor
• Anna, an Author

System Administrator

Sam fills the role of a system administrator and is responsible for maintaining technical aspects of the system. He should be able to make any changes within the CMS including system settings, content, and pages.

In previous versions (SDL Web 8 and before) of Tridion, he would have the System Administration checkbox set. Now he and others administrators belong to the System Administrator group which has the System Administration privilege set.

In an upgrade, admins will be automatically migrated to this new arrangement.

Though you could technically create additional system administrator groups, in practice I'd imagine most implementations will have just the default group for admins. You might create a separate group or inherit from this group for those that perform the admin role temporarily (e.g. developers or partners at the start of a project or on the DEV environment).

Application Manager

Oscar is an Application Manager and is responsible for  configuring the system but should have select access to the the Publications, content, and pages. For example, he should be able to add a new Multimedia Type or modify the publishing queue, but only read permissions to the company's latest Press Release components.

In this setup he belongs to a new Applicaiton Manager Group that has privilege management, approval status management, multimedia type management, and Publish Transaction Management.

You might choose to give the group read permissions in folders at the top of your BluePrint and adjust scope to select Publications.

Chief Content Editor

As a Chief Content Editor, Elaine works regularly with several authors. She is responsible for making requests to IT to enable new users as well as set their group membership and scope. She would also request new Publications for campaign landing sites or new translated language or localized versions of existing webistes.

By having IT give her group the Group Management privilege, she can now manage groups and their members, including scope across the BluePrint. She cannot grant herself or others administrator access. In addition, through the Child Publication Creation privilege, she can use the Site Wizard to create new translation or campaign Publications .

If technically oriented, she could also Create Child Publications Manually in the Content Manager Explorer, outside of the Site Wizard. The settings are the same, but presented in a friendly step-by-step guide in the Wizard.

Alternatively, Oscar could instead have the Group Management privilege or perhaps Elaine would have Publish Transaction Management.

Content Author

Finally, Anna belongs to the Author group which has its own scope, rights, and permission settings but no specific privileges as seen below.

You may want to let authors create child publications, but typically they wouldn't need to change privileges, maintain system lists, nor manage groups or privileges.

Ways to Get Started

As with the authorization settings, I would take a gradual implementation based on one of a few approaches:

• Start small. For smaller teams where speed, flexibility, and self-service are important, create fewer groups with more privileges. Perhaps the Application Manager group might have all privileges except System Administration. And maybe select power users could also belong to this group. The SDL Web implementer refers to "not turning all the dials at once" (often cited by implementer Dominic Cronin), which is a good approach when first working with privileges.
• Pick a privilege or two. For larger organizations where auditing and stricter access are important, consider taking your time when adding privileges and starting with the biggest pain points. For example, maybe it's important to have groups managed within an internal service group that has the Group Management privilege but shouldn't have complete Administrative access.
• Introduce groups as needed. If you've delayed on creating a complete authorization model and find yourself with users that are admins, consider two changes:
  • Give users that should manage content, pages, and organization items on a day-to-day basis the new Publication Management Right. They could help when people inadvertently leaving items checked out.
  • Give analysts and technicals that should manage the application all privileges except System Adminstration. Optionally give them Publication Management Right to select Publications.

Note: when we talk about giving privileges and group membership, remember that this is by first having a group with the privileges and then adding that group as a parent to other groups or users. Read about these settings in my post on the difference between Tridion designs and settings. 

These are just examples based on my own experience and understanding of Tridion projects and customers. Much thanks to our Cloud, R&D, and QA teams for implementing both the desired functionality as well as an extendable framework we (and our community) could build on. And thanks to the docs team for explaining everything in time for the cloud release (and guidance on the best ways to describe the feature in the UI).

We'd love to hear how implementers and customers are applying this feature in practice as well as what other privileges would make it easier for your teams to go global faster. First get familiar with the latest authorization changes and then consider leaving adding an idea to SDL Web Ideas.

Update (2016-12-19): I made a video demonstrating the Group Management Privilege.