User Management: Have the User Rights Under Control

Collaboration is one of the Lumeer’s most important features. You can add other users to your organizations and projects and decide what they are allowed to see, change or add. You can also organize users in teams. See how user and team management works in Lumeer.

The user management in Lumeer is implemented in the way of Role Based Access Control. If you are familiar with that principles, you might just check the rights overview at the bottom of this article.

For details on how information are organized in Lumeer, check out Basic Principles.

Organizations and Projects

All users and teams are bound to an organization (or multiple organizations). All users always need to join your organization when you want to collaborate with them.

Teams are also defined at the organization level.

Within organizations, there are projects. While data among project are separated, they share the same users and teams within an organization.

In projects, there are tables, link types, and views.

Teams

Teams are only supported in the Business plan.

Users can join any number of teams. They can have no teams assigned, they can have (in theory) an unlimited number of teams.

The resulting user rights are computed as a union of all rights:

• given directly to that user,
• given directly to teams the user is member of,
• the user obtained from the upper hierarchical levels (from project, or organization)
• the teams (the user is member of) obtained from the upper hierarchical levels (from project, or organization)

Teams are very similar to users. You can think of Teams as sample users.

The recommended approach is to create Teams that represent individual organizational roles. Always think of a Team as of a sample user. Then assign that sample user (Team) the corresponding rights.

For example, Finance team should have necessary read and write access rights to specific tables and views. Then assign all users who work in the Finance team in your real organization to this team in Lumeer.

Later, when the needs of the Finance team change (they will need access to another table), you simply grant the corresponding right on that table to this team. All team members will be taken care of.

Please note that teams do not need to grant Join rights to an organization or project. It is a good practice to mostly keep the team rights as fine grained and possible and really limited to tables and views. With an exception of a few teams spreading the users across projects in the organization.

User Rights Hierarchy

User rights are configured separately for each of the units – organizations, projects, tables, and views. However, they need to follow a certain hierarchy.

For example, a user always need to have at least the Join right at the organization and project level to be able to see tables and views in that particular project.

When the Join right at the organization and project level were missing, a user won’t be able to see the table. This is because they won’t be able to access the project.

It is possible to gain some rights from an upper hierarchical level. At the bottom of this article, there is an overview of all the user rights and their ability to be inherited.

This inheritance means that users might get rights to all tables, all views, all projects etc.

Let’s see an example. In the following diagram, we can see the Read Records right that the user or team has directly assigned at the table level. This gives a user an access to that specific table.

Another option is to have the Read Everything right assigned to the user or team at the project level. This gives the user an access to all tables and views in this particular project (including the table).

Finally, the user or team can have the Read Everything right assigned at the organization level. This gives them an access to all tables and views in all projects.

In Lumeer, user rights shown in green are always directly assigned. Those in gray are obtained from an upper hierarchical level (from a project, or organization).

In case of views, rights can be also inherited from tables. For example, a read only view becomes read and write for users who have write access to the underlying table anyway.

User Management In an Organization

To enter the user management screen, click on the organization code and select Configure.

This is the main place where new users are added. There are couple more ways to add users to the organization (mentioned later), nevertheless, they always need to be present here. It is not possible to have a user just at the project level.

On the Users tab, you can see the list of the existing users and a field for inviting new users.

When you add a user to the organization, they are automatically visible on Users tab in all projects. However, this does not grant them any rights (i.e. the newly added user does not see any project nor organization).

A user need to have at least the Join right to see an organization, project, table, link type, or view.

New users are always added with no rights assigned.

To remove a user from an organization (and all its projects), click on the red bin icon.

It is also possible to assign users to teams here (use the Add Teams button).

Team Management In an Organization

Teams are only created at the organizational level. However, their rights are configured separately at all levels (organization, project, table, link type, view).

As we have already mentioned, you can think of a team as a template user. This gives you a better idea of what rights need to be configured where.

Sometimes, it is possible to choose an opposite approach. Companies just invite a few users from various groups. They setup their roles and fine tune the system. Then they create teams that correspond to rights of those individual users. Other employees are then added with appropriate team membership.

Every team has its name, description, list of users who are members of the team, and rights of the team.

User Management In a Project

Managing users on a project level is very similar to organization level. Click on the project code and select Configure.

The list of existing users appears. There is no option to invite new users – that can be done only at the organization level.

Also, it is only possible to assign users to teams at the organization level. Not at the project level. However, nothing prevents you from creating teams in such a way that they only provide rights of a certain project.

All users from the organization are listed in the project, but if they are not assigned any right (at least the Join right), they don’t have access to the project (i.e. they do not see it at all).

Teams setting is very similar, again with the exception that it is not possible to assign users to the team.

User Management In a Table

To enter table settings, click on the gear icon next to the table icon:

And switch to the Users tab.

Inviting Users

In addition to directly adding users in the organization settings, it is possible to invite them directly into a project using the invite button in the upper right corner.

First, you must specify emails of the users you want to invite.

Next, you just select the rights of the new colleagues.

This will just grant users some basic rights so that they can primarily work with user data in Lumeer. For additional rights, you must further tweak their rights settings.

Another option is to specify an email of a colleague who is not present in your organization directly when sharing a view.

That way a user is added to the organization and project (using the Join right), and they you can fine tune their specific rights for that particular view.

User Rights

The user rights are quite fine grained to allow a very detailed control of what each individual can see and do in the system.

To allow that, the user rights mostly overlap but there are slight differences on each level (organization, project, table, link type and view).

Moreover, some user rights implicate inherited rights at lower levels. For example Read Everything at the project level automatically gives Read Records on all tables in the project.

Let’s see what rights are available at each level, what is their purpose (what do they control), and what impact they have on lower levels.

Organization User Rights

Project User Rights

Project user rights are very similar to those at the organization level. They just cannot grant rights for all the projects. Only for the current one and its content (tables, link types, and views).

Tables Link Type, and View Rights

Rights at this level do not have any further inheritance or any influence on other units of the information model (tables, link types, views).

View Rights Limitations

There is a special case with limited rights on Views. Nobody can ever gain more rights on a View than the original View author.

This is due to security reason, so that someone could not share a View with their colleague in another team and gain undesired access to, for instance, sensitive data.

Rights Inheritance In Detail

To give you a better idea about inheritance of individual rights, we provide the following table. In this table, you can see a list of user rights that can be inherited, and how they are called on individual levels.

The flow of inheritance is from left to right. For example, on the first row, we can see Manage All Users. When set on the organization level, it implicates everything to the right (project, table, link type, view). When set on the project level, it again implicates everything to the right from that level (table, link type, view). No inheritance happens from the Table, Link Type and View levels.

Example User Rights Settings

Let’s have a look at a typical scenario and what user rights we’ll need to set up. We can create both users with the roles, or teams with the roles and assign the users to teams.

For the simplicity of this demonstration, we’ll configure the rights for users directly.

In the example, we have the following five users:

• a super user who can do anything (typically an organization owner)
• next, there is a solution architect who configures the platform and builds solutions,
• we also need a system administrator who does not see any data but manages users and settings,
• then a user with data read and write access,
• and finally a read only user (a temporary intern for example).

The Super User

As the company owner, they can have all the possible rights. It is sufficient to set the rights at the organization level. They will get automatically distributed (due to inheritance) throughout all projects, tables, link types, and views.

The Solution Architect

The solution architect is allowed to create projects, tables, link types, views, configure the whole information model, fill in data, and develop automations.

It depends whether we have a single solution architect in the company, or we have multiple solution architects who are dedicated to specific projects.

If we have only one solution architect, we can set their rights at the organization level. If we have solution architects per project, we give them just the Join right at the organization level and configure the rights at the project level.

To make it easier, we can just list the rights that are left out: Manage, User Management.

The System Administrator

The system administrator complements the solution architect in the user rights. We should have at least one system administrator at the organization level so that they are able to add new users.

A Generic Employee

Most of the employees will have the right to Join the organization and project and work with data in selected tables and view.

This is what their settings need to look at least at the organization and project level:

Now we have several options. We can allow the employees to read and write all tables and views at the project level.

Or we can turn on the necessary rights at individual tables and views like follows:

Of course we can decide not to give users the rights to Configure View, or Manage Query.

Btw. whenever you hover the mouse cursor over a user right, you can see a tooltip explaining the right’s purpose.

An Intern

For interns, temporary employees etc. we follow the same approach as with a generic employee. So we make sure they have the Join right at the organization and project level.

We typically do not give them more rights at the top levels as we do not want these colleagues to automatically get any rights.

We just carefully select what they are allowed to do with individual views. Typically, we do not share tables directly as views provide much better control over what part of data is visible.

Sometimes, just a few rights can do the job.

Conclusion

Should you have any question and needed any help configuring the user rights for your organization, just contact us.

Also if you needed another user right that is not yet available, get in touch and we’ll consider implementing it.