Entity Resolution Check Permissions
This page covers the team permissions required to view, create, edit, archive, and delete an Entity Resolution check on a source datastore. For the full reference of user roles, see User Roles. For the canonical matrix of every team-permission-gated action, see Team Permissions Overview.
Permission Matrix
The table below shows which team permissions can perform each action on a datastore the user has access to:
Key Details
- Viewing is available to all team permissions, including Reporter and Viewer.
- Draft work is available from the Drafter permission upward: creating a check as Draft, editing it while it stays Draft, and restoring an archived check as Draft.
- Anything that puts a check into evaluation requires at least the Author permission: creating or activating an Active check, editing an Active check, archiving, restoring as Active, and deleting permanently.
- The same rules apply through the API. The API page lists the permission each endpoint requires.
- Admins bypass team permissions and can manage checks on every datastore in the workspace. Managers do not bypass team permissions: like Members, they need the required permission in at least one team assigned to the datastore.
Team Context
Permissions are evaluated against the datastore's team assignments. A user must have the required team permission in at least one team that the datastore belongs to. For more details on how teams work, see the Team Permissions page.
See Also
-
How It Works
The complete reference: definition, field scope, field roles, comparison types, weights, threshold, and clustering.
-
Anomaly Reporting
The anomaly message the check produces, what each number means, and how non-compliant clusters appear in Source Records.
-
Examples
Production scenarios with sample records, cluster outcomes, and the resulting anomaly messages.
-
Best Practices
Guidelines for blocking, weighting, tuning the threshold, and normalizing values before resolution.