Close

User Management

Omniata allows specific user access control over tools and content in the panel. The access rights are determined by user Roles. There is no limit for the number of different Roles in the organization or for the number of Roles per user. If one User has several Roles with different Permissions levels, the permission level applied is the broadest access given by the current Roles.

Access control is managed under User Management that can be accessed by selecting the main navigation on the left top corner, selecting Global Settings -> User Management section. Within the section you can see first assigned Roles per account, manage Roles, and define Permissions.

Permissions can be set on several different levels, like Environment, Application, Project and Dashboard Group. Permissions can also be set per each Environment/Project/Application separately or to all Environments/Projects/Applications at the same time. There are also Permissions for controlling organization administration.

Content:

Accounts

Users are members of the organization or its external partners who need access to Omniata platform. Here you can:

  • Add new users by sending email invites.
  • Add and edit roles to current users.
  • Edit Role access.
  • Delete user by removing that user from the Organization.

Adding New Users

New users are added by sending them email invitations to the organization. To send an invitation to the organization, navigate to Global Settings -> User Management -> Accounts and follow the steps:

  1. Select “Invite New User”.
  2. Enter the email(s) of the people to invite, separated by comma, semicolon or in separate lines.
  3. Select the Role(s) that you’d like to give to the people you are inviting. This setting can be changed later if necessary.
  4. Click “Send Invites”.

The selected users will receive an email with login instructions.

Removing Users

To delete an user, select ‘Remove’ from Actions in the Accounts section from User Management.

Roles

Roles are groups of users that share the same access privileges. There are some built-in roles in Omniata, and you can create new roles in order to limit the access that people should have according to your policies. Roles can be created for example for different projects or different user levels.

On this panel you can:

  • Edit the Permissions of the Role.
  • Edit the Role.
  • Delete the Role.
  • Create new Role.

Built-in Roles cannot be edited or deleted. Their Permission settings can be edited. The built-in Roles are the following:

All Users
Access to everything, excluding admin rights.
Omniata Organization Admin
Access to everything, including admin rights.

Managing Roles

Managing roles is straightforward, select “New Role” to create new roles and the Actions menu will give you access to edit or delete existing roles. When deleting a role it will not remove users linked to the role from the panel.

Permissions

Global Permissions

Permissions apply on a global basis and are linked to roles. The permissions are divided per panel objects categories, the categories are:

Object Name Description
People Access control over user management tasks.
Engager Control over edit and creation of objects in the Engager module.
Environments Control over querying data per environment.
Billing Controls who can access and view billing information for the organization.
Configuration Access to organization options and edition of Lookup Tables.
Applications Deprecated.
Projects Limits the access to see and manage all applications. Access control for individual applications is controlled in the application’s settings.

The following permissions can be set.

Category Option Description
People
Invite People to Organization Allows to invite additional users to Omniata.
Remove Members from Organization Allows to revoke user’s access from Omniata.
Manage Roles Allows to create, modify and delete roles.
Manage Role Permissions Allows to change the permissions of a role.
Update Member’s Roles Allows to change another user’s role.
Send Notifications to Users Allows to send a notification to other users.
Engager
Manage Channels Allows to modify, create and delete channels in the Engager.
Manage Segments Allows to modify, create and delete segments in the Engager.
Manage Experiments Allows to modify, create and delete experiments in the
Manage Content Allows to modify, create and delete content in the Engager.
Manage Content Types Allows to modify, create and delete content types in the Engager.
Environments
Query All Environments Allows to view data in all Environments.
Query [Your Environment A] Allows to view data in [Your Environment A].
Query [Your Environment B] Allows to view data in [Your Environment B].
Configuration
Organization Settings Allows to modify organization settings.
Manage All Lookup Tables Allows to modify, create and delete items in Lookup Tables.
Applications
Manage All Allows edits to Applications.
Read All Only view rights.
Projects
Permissions Set permissions to all Projects. For information on the different options, see below for project permissions.

Permissions on application level control what operations a Role can do with the application. These permissions affect only the application in question. Roles can be assigned in the following categories.

Categories Actions
Viewer Can view Widgets and Dashboards
Can view all other application objects.
Editor Viewer permissions.
Can edit Widgets and Dashboards.
Data Analyst Editor permissions.
Can create, edit and delete data fields and reporting tables.
Can create and edit jobs and publish data.
Can use SQL mode.
Developer Viewer permissions.
Can use Event Console.
Data Engineer Data Analyst permissions.
Can use Event Console
Data App Owner Can create, edit and delete all application objects
Can use Event Console and SQL mode
Can edit or delete the application.

On an organization level, Permissions can be set to all applications as a whole. Permissions to individual applications and global permissions are interpreted in parallel. For example, if a Role has Editor permissions to all applications and Developer permissions to one certain application, the applied Role is a combination of Editor and Developer permissions to that application and Editor permissions to all the other Projects.

Application Permissions

Permissions on Application level control what operations a Role can do with the Application. These permissions affect only the Application in question. Roles can be assigned either reading permissions or reading and writing permissions. This level of control can be configured in the Application Settings menu.

Reading permissions enable the Role to see:

  • The Application and all data assigned to it.
  • All Engager material of the Application (Channels, Segments, Experiments, Contents, Content Types).
  • Edit and delete the Application.

In order to edit Engager materials, a Role needs to be set Engager permissions on the Global Level.

Dashboard Permissions

Permissions on Dashboard Group level control what operations a Role can do with the Dashboard Group. These permissions affect only the Dashboard Group in question. Roles can be assigned either reading permissions or reading and writing permissions. Dashboard permissions are edited for one dashboard at a time. To edit the Dashboard permissions, navigate within a Dashboard to Settings.

Reading permissions enable the Role see that Dashboard Group and its Dashboards in Analyzer. Reading and writing permissions enable the Roles also edit the Dashboard Group.

By default, Dashboard Group Permissions are inherited from the Application which contains the Dashboard Group. Thus, Viewer roles or Data QA permissions in the Application have reading permissions to Dashboard Group. Roles with Editor, Data Analyst, Data Engineer or Data Model Owner permissions to the Application have reading and writing permissions to the Dashboard Groups.

Dashboard Group Permissions which are assigned manually are used instead of the default permissions, not in addition to them.

If a dashboard group has subgroups, by default, the permissions of the parent group are inherited to all the child dashboards. If a role is manually assigned permissions to a dashboard subgroup, those permissions override all the default permissions inherited from the parent group.

This article was last updated on May 3, 2017 15:07. If you didn't find your answer here, search for another article or contact our support to get in touch.