Coming Soon! Projects, User Groups, System of Record Management, and Sensitive Field Support
We are excited to announce a number of new features and improvements that will be available the week of July 7th. In this post, learn about these new features and what you can to do prepare for their release.
- New Projects Feature
- Streamline User Management with Groups
- Protect Sensitive Data
- Updated Viewer Permissions
- Improved System of Record Management
New Projects Feature
Our new projects feature will provide improved organization and access control for resources and objects in Tamr Cloud.
A project is a collection of data products, sources, and jobs. If you are using Tamr Realtime, projects also include workflows and destinations. These resources cannot be shared across projects. For example, when configuring a data product, you can only add sources that have been added to the same project.
You may want to create separate projects for each business unit or project team using Tamr Cloud.
The following diagram illustrates tenant-level and project-level resources.

Project Roles
In addition to tenant roles and data product roles, the project feature will add a new level of user permissions: project roles.

Tenant admins will be able to add projects and assign project roles to control access to a project and its resources.
The following table defines the actions that will be allowed by each project role: Admin, Editor, and Viewer.
Project Roles | |||
Action | Admin | Editor | Viewer |
Projects | |||
Assign project roles | ✅ | ❌ | ❌ |
View all projects | ✅ | ✅ | ❌ |
Edit project metadata | ✅ | ✅ | ❌ |
Delete projects | ✅ | ❌ | ❌ |
Sources | |||
Add sources | ✅ | ✅ | ❌ |
View all sources | ✅ | ✅ | ❌ |
Edit sources | ✅ | ✅ | ❌ |
Delete sources | ✅ | ❌ | ❌ |
Data Products | |||
Add data products | ✅ | ✅ | ❌ |
All other data product actions | Determined by data product role. | ||
Workflows | |||
Add, view, and manage workflows | ✅ | ❌ | ❌ |
Destinations | |||
Add, view, and manage destinations | ✅ | ❌ | ❌ |
A user’s project role will determine their default (inherited) data product roles for the data products that belong to that project.
Project Role | Inherited Data Product Roles | |||
Admin | Developer | Curator | Viewer | |
Admin | ✅ | ✅ | ✅ | ✅ |
Editor | ❌ | ✅ | ✅ | ✅ |
Viewer | ❌ | ❌ | ❌ | ✅ |
No role | ❌ | ❌ | ❌ | ❌ |
Preparing for Projects
When projects is released, all existing data products, sources, jobs, workflows, and destinations will be organized into the Default Project.
You will not be able to move data products, sources, and other resources out of this default project, but you will be able to create new projects going forward.
Users’ project roles will be inherited from their current tenant role.
Streamline User Management with Groups
You will soon be able to organize Tamr Cloud users into groups.

You will be able to:
- Assign tenant roles to groups instead of individual users.
- Share projects and data products with groups, assigning groups to specific roles in each project and data product.
- If your tenant is configured for Single Sign-On (SSO), associate Tamr Cloud user groups with external groups in your organization's identity provider (IdP). You’ll then manage group membership in your IdP.
Preparing for Groups
If you plan to take advantage of the groups feature:
- Review your current list of tenant users and their tenant-level role and data product roles. Consider the best way to organize your users into logical groups. For example, you may want user groups for:
- Administrators, who need full tenant access.
- Department project managers, who need full access to the data products, sources, and other resources in their department’s Tamr Cloud project.
- Department curators, who need curator access to data products in a specific project.
- Department business analysis, who need view access for data product 360 pages in a specific project.
- After organizing existing users into groups in Tamr Cloud, you may want to change the user’s individual role on the tenant to No Role (--) and remove their individually granted roles for each project and data product. This way, their tenant, project, and data project roles will be determined by the groups to which they belong.
- If you are using SSO, investigate whether associating groups with existing or new groups in your IdP would be useful for managing permissions in your tenant. If so, ensure users are organized into logical groups for assigning tenant-level, project-level, and/or data product-level roles.
Keep in mind that a user will have the highest granted role on the tenant. For example, if the user is granted the Editor role on the Users page, and is assigned to a group with the Admin role, the user will have Admin permissions on the tenant.
The user will also have all granted data product and project roles, whether they are granted to the user individually or as a group. For example, if the user is individually granted Curator and Viewer roles for a data product, and belongs to a group that is granted Developer access to the data product, the user will have Developer, Curator, and Viewer permission on the data product.
Protect Sensitive Data
In all data products, you will be able to mark attributes as containing sensitive information. Tamr will hide the data in these attributes from users with data product Viewer access. Users with other access will continue to see these values.
For example, you may want to mark birth date, national ID, mobile phone, or other fields as sensitive.
On the Configure Data Product page, you will be able to mark any pre-defined or custom attribute as sensitive. Unlike other data product configure changes, marking a field as sensitive will take effect immediately on the Browse Data and 360 View pages.

In the Browse > Data pages and in 360 View pages, sensitive field values will be replaced with “Restricted” for uses with only Viewer access.
For example, in the data product below, the phone and email attributes are marked as sensitive.

Browse Data page

360 View page
Preparing for Sensitive Attributes
Review your data products to determine if any attributes contain sensitive data that you do not want shown to users with only Viewer permission.
Updated Viewer Permissions
As part of the new feature to mark attributes with sensitive data, the Viewer role is becoming more restrictive.
Viewers will have view access to ONLY the 360 View pages for the data products to which they have access. This change will impact all users currently assigned the Viewer tenant role and/or Viewer data product role.
See Data Product Permissions for the full list of current Viewer permissions.
Preparing for Updated Viewer Permissions
Review users that have the Viewer tenant role and the Viewer data product role. Alert these users to the upcoming change. If necessary, assign users to different roles within the tenant or individual data products to allow them to continue accessing the pages that they need as part of their job.
Improved System of Record Management
We will be releasing a new System of Record Management page, replacing both the existing RealTime Settings page and the update System of Record workflow for each data product.
On this new page, you’ll create the System of Record for your data product.

You’ll then be able to run the new Stage Changes workflow to review the types and number of changes from your batch data product run before promoting them to the System of Record. When you are ready to promote the changes to the System of Record, you’ll run the Apply Changes workflow. Both of these workflows can be run in the UI and via the Jobs API.

Preparing for Improved SOR Management
If you have automated system of record updates through the Jobs API, you will need to update your scripts to run the new Stage Changes to the System of Record and Apply Changes to the System of Record workflows instead of your existing Refresh System of Record workflow.