Skip to content

Managing Personas and Permissions

Audience: Data Governors and System Administrators

Content Summary: This document outlines step-by-step instructions for creating users, adding permissions to a user, and removing users' permissions. For more information on user permissions, see the Personas and Permissions Overview.

Additional Tutorials Contents:

  • Disable Users
  • Permanently Delete Users
  • Migrate Users from Another IAM
  • Remove Permission from User
  • Manage User Impersonation (Immuta Query Engine)
  • Download Metrics
  • Show Disabled Accounts

Use Case

Compliance Requirement: Users can only interact with Dev data.

For this requirement, the User Admin should assign the GOVERNANCE permission to users on the Compliance team. This permission will allow them to create and assign tags that identify Dev, Test, and Prod data and write Global Policies that restrict data access to Dev for users.

Best Practice: Use External and Internal IAM

Use an external IAM for authentication and Immuta's internal IAM to manage attributes.

1 - Create Users

  1. Click the Admin icon in the left sidebar, and select the Users tab.
  2. Click the New User button in the top right of the page.

Add User Button


  1. Click the plus button in the top left of the Immuta console.

  2. Select the New User icon.

  3. Fill out the Full Name and Email fields in the dialog. Note: The user's email address will be used as the username and must be unique.

  4. Click the Create button.

Add User Dialog

2 - Add Permission to User

  1. Click the Admin icon in the left sidebar, and select User 1 from the Users tab.

  2. Click Add Permissions.

Add Permission Link

  1. Click the Select Permission dropdown, and select the GOVERNANCE permission.

Select Permission

  1. Click Close.


Now all Compliance team members have been added to Immuta, and they have the GOVERNANCE permission added in addition to the default permissions to create a project and create a data source in a project.


Additional Tutorials

Disable Users

  1. Click the Admin icon in the left sidebar, and then select the Users tab.

  2. Select the user you would like to disable, and click the dropdown menu button next to the user's name in the left panel.

  3. Select Disable.

    Delete User

  4. Click Disable in the confirmation dialog.

Permanently Delete Users

Note: This action permanently deletes all data associated with this user from Immuta, including data source subscriptions, and a timestamp of this event will be captured in the audit logs. The ability to create Governance Reports against this user will no longer be possible. This action cannot be undone.

  1. Click the Admin icon in the left sidebar, and then select the Users tab.

  2. Select the user you would like to delete, and click the dropdown menu button next to the user's name in the left panel.

  3. Select Permanently Delete.

    Delete User

  4. Click Permanently Delete User in the confirmation dialog.

  5. Type Delete to confirm deleting the user permanently.

    Permanently Delete User

  6. Click the Confirm Permanent Delete button.

Migrate Users from Another IAM

  1. Click the Admin icon in the left sidebar, and select the user from the Users tab.
  2. Click the dropdown menu to the right of their name and select Migrate User.

    Migrate User 2

  3. Enter their username in the modal that appears and click Migrate User.

Remove Permission from User

  1. Click the Admin icon in the left sidebar, and select the user from the Users tab.

  2. Click the delete icon on the permission you want to remove.

Remove Permission

Download Metrics

  1. Navigate to the Admin page.
  2. Click the Metrics icon in the top right corner of the page.

    Immuta Metrics

  3. Complete the Number of Days field in the dialog that appears, and then click Download to download the JSON file


Collecting Immuta usage metrics from customers helps Immuta gain insight into how customers are using Immuta (not who they are or what their data looks like) to understand what features are heavily used. These metrics guide improvements to the user experience.

What is Collected?

The metrics collected are anonymized data points that provide information on Immuta feature usage but cannot be linked to an individual user or data source. Specifically, Immuta collects what workflows the users are completing and what the users are touching in the UI.

  • Workflows Users are Completing: These workflow metrics (creating policies, data sources, projects, etc.) are aggregates, such as the number of data sources created in a day, not individual events.

  • What Users are Touching: These metrics indicate what users click in Immuta, such as the create a data source button.


  • Product Input: Input from customer metrics helps Immuta make product roadmap decisions. Providing your metrics is the best way to provide product feedback directly to Immuta.

  • Improve User Experience: Insights into the activity of different personas (governors, data owners) can be used to improve the Immuta user interface and create meaningful feedback loops.

  • Internal Insights: Gaining insights into your own Immuta use can reveal habit loops or pain points that users experience that may not be obvious. Metrics will enable those to be identified and improved.

  • Prove Value: Quantifying the areas of Immuta that you are using the most is the key to understanding the value that Immuta brings to your organization.

User Impersonation Use Cases

  • The Project Path: In this case, the user wants multiple users to use the same dashboard and needs everyone to see the same data. An Immuta project is created and equalized. Then it is exposed to a PostgreSQL connection for projects; this gives the project a single connection for all the users to impersonate. A dashboard can then be created with the project's connection. After this creation multiple users can see the same data with the correct policies enforced.
  • The Impersonation Path: This feature allows a user to identify themselves while watching a dashboard that is not their own. An identifier of the user requesting the data is presented with a special, sensitive access token. With this information the data on the dashboard can be personalized to the person viewing it, while still remaining a multi-user connection.

Configuration and Usage

  1. Grant a selected Immuta user the IMPERSONATE_USER permission.
  2. Use a tool capable of establishing a PostgreSQL-based SQL (see Analytic Tools for specifics on which tool to use) connection to connect to Immuta's Query Engine using the Immuta SQL credentials of the user with the IMPERSONATE_USER permission.
  3. Enter into the Immuta Query Engine the iamid that is associated with the Immuta user account you want to impersonate.

    The iamid is the name of the Identity and Access Management (IAM) provider that the Immuta user you want to impersonate is associated with. The image below shows where the iamid can be located.

    Finding IAMID

    For example, if using the iamid of "Okta" from above, the full SQL command would be

    SET immuta.impersonation_iamid = 'Okta';

    Note: The iamid is a case-sensitive value.

  4. Enter into the Immuta Query Engine the userid that is associated with the Immuta user account you want to impersonate.

    The userid could be an email address (if using Immuta's built-in identity manager - or bim), or it could be a shortened form of the username like a sAMAccountName in Active Directory.

    For example, to specify a userid of jdoe, run

    SET immuta.impersonation_userid = 'jdoe';

    Note: The userid is a case-sensitive value.

  5. In certain cases, it may be necessary to convert a shortened form of the username, like a sAMAccountName, to an email address in order to match it to an Immuta account. To handle this special case, Immuta has added a template capability such that the userid can be augmented by a specified template.

    For example, a sAMAccountName of jdoe can be converted into an email address at using a string template that substitutes the value of {userid} with the userid provided. The resulting value would be

    SET immuta.impersonation_userid_template = '{userid}';
  6. Now that your Immuta Query Engine session is configured to impersonate the desired Immuta user, as long as your session remains active, you queries will be executed as the impersonated user.

Notes and Caveats

  • The Immuta user account with the IMPERSONATE_USER permission must have valid SQL credentials configured in order to conduct user impersonation via the Immuta Query Engine.
  • Once impersonation is set, all subsequent SQL calls will be made as the impersonated user.
  • User impersonation lasts the duration of the SQL connection. To stop impersonating a user simply close the connection.
  • It is not possible to switch impersonated users within a single SQL connection. Each connection supports at most one impersonation setting. After user impersonation has been enabled, attempts to set a different user to impersonate will fail.

Show Disabled Accounts

Once an account has been disabled, it will not appear in the list of current Immuta users. To show the disabled accounts,

  1. Navigate to the Admin page.
  2. Click the dropdown menu in the top right corner of the page and select Include Disabled Accounts.

    Include Disabled Accounts

What's Next

Now that you've managed the user's permissions, continue to the next page or to this tutorial: Manage Attributes and Groups.