Secure Access to Objects in the Model

It’s important to keep sensitive information secure. Everyone has access to the data in your model by default. To avoid exposing sensitive data, set show and hide permissions for your entire model or for individual fact tables, dimension tables, and columns.

For example, you can restrict access to certain Revenue columns to ensure only authorized users can view them. Or you can restrict access to an entire model to stop people opening the model or accesses its subject area.

  1. In Data Modeler, lock the model for editing.
  2. To restrict access to the whole model, select the Permissions tab.
    To restrict access to a specific item in the model, edit the fact table, dimension table, or column whose access you want to secure, then select the Permissions tab.
  3. To control access, click Add and select the appropriate role.

    Alternatively, in the left pane, click Roles. Then, drag and drop a role to the Permissions list. To add multiple roles, use Shift + click or Ctrl + click to make your selections before you drag and drop.

  4. Specify whether or not this object is visible to users with that role by selecting either Visible or Hidden.
    • Models — If you hide a model, users with that role can’t open the model or its subject area.

    • Model objects — If you hide a fact table, dimension table, or column, users with that role can’t see the object in reports.

      The same users will see the object in Data Modeler if they have the BI Data Model Author role and have access to the model.

  5. To remove roles from the Permissions list (you can’t remove the Everyone role), do one of the following:
    • Right-click a role and select Remove.

    • Select Remove from the Actions menu for that role.

    • Select multiple roles using Shift + click or Ctrl + click, then select Remove Selected from the Permissions Action menu.

    • Remove all roles by selecting Remove All from the Permissions Action menu.

About Permission Inheritance

When multiple application roles act on a user or role with conflicting security attributes, the user or role is granted the least restrictive security attribute. Also, any explicit permissions acting on a user take precedence over any permissions on the same objects granted to that user through application roles.


If you deny access to a table, access to all columns in that table is implicitly denied as well.