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.
Users are members of the organization or its external partners who need access to Omniata platform. Here you can:
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:
The selected users will receive an email with login instructions.
To delete an user, select ‘Remove’ from Actions in the Accounts section from User Management.
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:
Built-in Roles cannot be edited or deleted. Their Permission settings can be edited. The built-in Roles are the following:
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 apply on a global basis and are linked to roles. The permissions are divided per panel objects categories, the categories are:
|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.|
|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.
|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.|
|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.|
|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].|
|Organization Settings||Allows to modify organization settings.|
|Manage All Lookup Tables||Allows to modify, create and delete items in Lookup Tables.|
|Manage All||Allows edits to Applications.|
|Read All||Only view rights.|
|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.
|Viewer||Can view Widgets and Dashboards
Can view all other application objects.
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.
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.
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:
In order to edit Engager materials, a Role needs to be set Engager permissions on the Global Level.
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.