Overview
Manage user access and organization by adding new users, assigning them to functional groups, and configuring user settings.
Users
Individual users are created in Mirata using their first name, last name, and email address. Each user must have a unique email address.
User settings determine how the user can log into the Mirata platform. The user management provider can either be the Mirata provider “Cognito” or another provider specific to that Mirata org that provides access through the company’s SSO (i.e. Azure).
External System User IDs are used for integration with SAP so that transactions a user makes back to SAP can use their individual external user ID instead of a generic one for all transactions.
Groups
Groups are used to group users together who should all have the ability to perform a set of actions in the system.
A user can be part of multiple groups and groups can have multiple users in them.
Rights to perform actions in the system are assigned to a group for a particular form type.
Mirata provides you with a set of standard groups initially:
Standard Groups:
Group Name | Description |
Assembler Group | Assemble forms, incorporating additional components such as backend actions, data tables, templates, etc. |
Designer Group | Create forms, workflows, and templates in the designer |
System Administrator Group | Admin access to all components |
User Administrator Group | Create/modify users |
Inactive Users Group | Group with no rights to perform any actions in the system or log into the inbox, designer, or admin tool. Used for non-Mirata users to deactivate them |
Roles
Role privileges consist of a user role and the rights needed to perform that role.
The list of rights is divided into three different categories of rights as follows:
Regular rights - These are rights not associated with a group or a form type.
Group rights - These are rights needed to interact with groups and/or users.
Form Type rights - These are rights needed to interact with objects that are associated with a form type such as a Form Definition, or a Form Workflow.
Assigning Roles to a Group or User
Form roles are assigned to a user or group to provide that user or group with rights included in that role.
If a group is specified in the form role, then the rights apply to that specific group and all child groups.
If a form type is specified in the form role, then the rights apply to that specific form type.
A wildcard can be specified for the form type on the form role which will append a “*” to the form type for the rights apply to the specific form type and all children of that form type.
Mirata provides you with standard roles that should suffice for most use cases. We recommend using these provided roles unless your scenario is exceptionally complex.
Standard Roles:
Role Right | Description | Standard Group Assignment |
System Administrator | Administrator role, superuser rights | System Administrator |
Designer | Form developer role to configure forms and workflows | Designer |
Assembler | Form developer role to configure data tables, backend actions, etc. and add them to forms | Assembler |
Form User | Form user role, rights to create and update form submissions | N/A |
Form Reader | Form user role, ability to view form submissions | N/A |
Group Administrator | Administrator role, ability to add new groups and users | User Administrator |
Form Types
Every form must have one and only one form type. You set the form type when you create a form and you can later change the form type in the Admin Tool if needed.
By assigning roles to users, you define which users have access to which forms based on the form type assigned to that form.
For types are hierarchical, so you can have parent and child form types.
Example: Security Setup for Work Clearance Management
For example, if you’re creating forms for a Work Clearance Management (WCM) process, you could set up your groups, roles, and form types like this . . .
Create one Form Type called “WCM Forms” under your organization’s default parent form type (If you work at Acme, this would be called “Acme Form Type”).
Create three Groups: “Work Clearance Management” is the parent group and “Work Clearance Management - Supervisors” and “Work Clearance Management - Technicians” are child groups under it.
Assign the standard “Form User” and “Form Reader” Roles for the “WCM Forms” Form Type to both the Technicians and Supervisors groups; it should look like this for both groups:
Group Name | Description |
Work Clearance Management | This overarching group serves as the foundation. It encompasses all involved personnel and activities in the Work Clearance Management process. |
Work Clearance Management - Technicians | Specific to technicians or inspectors, this subgroup comprises those responsible for initial activities within the process. |
Work Clearance Management - Supervisors | For managers and approvers, this subgroup enables final oversight and approval. |
By organizing users like this, you can build your Work Clearance Management forms with these features:
Control From Creation Permissions: Ability to create Work Clearance Management forms is limited to those who have access to the “WCM Forms” Form Type.
Task Handover: Transition from Technicians to Supervisors easily. Once Technicians complete their portion, automatically hand over the form to the Supervisors group using workflow form assignments, so a supervisor can complete the approval stage.
Role-Specific Permissions Within the Form: Control who is authorized to complete certain actions in the form, such as limiting final form approval actions to those in the Supervisors group.