Design roles | Kontent.ai Learn

Let’s design the role table

When designing roles, take your content model into account as well.

Let's design the roles using a table to visualize how the roles would look. If suitable, modify the model to reflect the creation flow. The goal is to create a three-column table like this:

Role

Can do

Cannot do

Then, go through each answer you gave for the questions above and create a new row in the table or specify an existing row based on the information in the answer. For example, from this answer: "There are 2 team managers who review the content and manage metadata. Neither of them, however, manages the navigation. The navigation is only edited by the company’s developers." You can get two rows:

Role	Can do	Cannot do
Team manager	View, edit, create, and delete all content items	Delete, create, edit, and view metadata and navigation items
Developers	View, edit, create, and delete all navigation items

This table says that the first role will be able to view, edit, create, and delete all content items except metadata and navigation items. They won't see those at all. The second role will be able to view, edit, create, and delete all navigation items. That means other content items won't be visible to them without stating it in the Cannot do column.

Role naming

There are multiple approaches you can choose from. You can pick what will serve your company the most. For example, it can mimic your RBAC model; it can be loosely based on the people's positions in the organization or express the permissions that roles possess. You can also use a hybrid naming where you combine more approaches.

Based on the position in your organization

You can name your roles based on people's roles at your company. For example, if a person is a Copywriter, you can create a Copywriter role. The advantage of this approach is that you don't need to maintain organization charts. The disadvantage of this approach is that often, there are exceptions. For example, a team member should be allowed to do more as they're the substitute of a team leader, yet they are in the same position as the others.

Based on role permissions

Going from the other side, you can group people based on what they're allowed to do. For example, if there are eight Copywriters and three Editors, not only can they create a soccer team, but they can also share one role, such as View, edit, create, and delete all. The advantage of this approach is that you immediately know from the user's role what they're allowed to do. The disadvantage of this approach is that when changing permissions for a team, you need to go through all the users from different teams, as they have the same set of permissions.