Roles & Permissions

Enterprise Edition

Managing access through roles and rights.

Entropy Data implements role-based access control (RBAC).

An organization is a logical unit (tenant) that covers the data mesh of a company. You can have multiple organizations in an Entropy Data instance, and use it to separate different environments, e.g. development and production.

Entropy Data offers the following roles for all users that are part of an organization:

Organization Roles

A user can be assigned to one or more organizations. A user is either a member or an owner of an organization.

• Organization Member (Basic Role)
  • can view data products, data contracts, policies and every other resource of the organization
  • can request access for themselves
• Organization Owner (Admin Role)
  • can view, create, edit, and delete everything
  • can edit organization members (invite new members, remove members, change roles)
  • can create and delete domains and teams
  • can create API keys that have the same rights as an organization owner
  • can create API keys that have the same rights as a team owner

Reading is not a permission. Every active member of an organization can read every resource, so there is nothing to grant. The one exception is the marketplace: a data product's visibility (public, restricted or private) and its access agreements decide who sees it there, independently of any team role.

Team Roles

An Organization Member or Organization Owner can be assigned to one or more domains or teams. Resources (data products, data contracts, semantic namespaces, tags, assets, ...) are owned by domains and teams, and it is the owning team's roles that decide who may change a resource.

A team member has one role.

Here's a list of the default roles:

• Owner
• Approver
• Editor
• Member
• Steward

Each of these default roles has different permissions for resources owned by the team:

Permission	Owner	Approver	Editor	Member	Steward
DATAPRODUCT_ADD Add data products	✅	✅	✅
DATAPRODUCT_EDIT Edit data products	✅	✅	✅
DATAPRODUCT_DELETE Delete data products	✅	✅	✅
DATAPRODUCT_CHANGE_REQUEST_SUBMIT Propose changes to data products	✅	✅	✅	✅
DATAPRODUCT_CHANGE_REQUEST_APPROVE Approve proposed changes to data products	✅	✅
DATAPRODUCT_PUBLISH Publish data products to the marketplace	✅	✅	✅
DATAPRODUCT_GIT_CONNECT Connect data products to git	✅	✅	✅
DATAPRODUCT_TEST_RESULTS_EDIT Publish test results named by data product (deprecated)	✅	✅	✅
DATACONTRACT_ADD Add data contracts	✅	✅	✅
DATACONTRACT_EDIT Edit data contracts	✅	✅	✅
DATACONTRACT_DELETE Delete data contracts	✅	✅	✅
DATACONTRACT_CHANGE_REQUEST_SUBMIT Propose changes to data contracts	✅	✅	✅	✅
DATACONTRACT_CHANGE_REQUEST_APPROVE Approve proposed changes to data contracts	✅	✅
DATACONTRACT_BRANCH_ADD Create branches of data contracts	✅	✅	✅	✅
DATACONTRACT_TEST_RUN Run a data contract's tests	✅	✅	✅	✅	✅
DATACONTRACT_TEST_RESULTS_EDIT Publish and delete test results	✅	✅	✅
DATACONTRACT_GIT_CONNECT Connect data contracts to git	✅	✅	✅
SEMANTIC_NAMESPACE_ADD Add semantic namespaces	✅	✅	✅
SEMANTIC_NAMESPACE_EDIT Edit semantic namespaces	✅	✅	✅
SEMANTIC_NAMESPACE_DELETE Delete semantic namespaces	✅	✅	✅
SEMANTIC_NAMESPACE_BRANCH_ADD Create branches of semantic namespaces	✅	✅	✅	✅
SEMANTIC_NAMESPACE_GIT_CONNECT Connect semantic namespaces to git	✅	✅	✅
MANAGED_TAG_ADD Add managed tags	✅	✅	✅
MANAGED_TAG_EDIT Edit managed tags	✅	✅	✅
MANAGED_TAG_DELETE Delete managed tags	✅	✅	✅
MANAGED_TAG_CHANGE_REQUEST_SUBMIT Propose changes to managed tags	✅	✅	✅	✅
MANAGED_TAG_CHANGE_REQUEST_APPROVE Approve proposed changes to managed tags	✅	✅
ASSET_ADD Add assets	✅	✅	✅
ASSET_EDIT Edit assets	✅	✅	✅
ASSET_DELETE Delete assets	✅	✅	✅
ASSET_CHANGE_REQUEST_SUBMIT Propose changes to assets	✅	✅	✅	✅
ASSET_CHANGE_REQUEST_APPROVE Approve proposed changes to assets	✅	✅
POLICY_CHECK_RUN Run policy checks	✅	✅	✅	✅	✅
DEFINITION_ADD Add business definitions (deprecated)	✅	✅	✅
DEFINITION_EDIT Edit business definitions (deprecated)	✅	✅	✅
DEFINITION_DELETE Delete business definitions (deprecated)	✅	✅	✅
SOURCE_SYSTEM_ADD Add source systems (deprecated)	✅	✅	✅
SOURCE_SYSTEM_EDIT Edit source systems (deprecated)	✅	✅	✅
SOURCE_SYSTEM_DELETE Delete source systems (deprecated)	✅	✅	✅
ACCESS_ADD Add access without a request	✅
ACCESS_EDIT Edit requested access on behalf of the team	✅	✅	✅		✅
ACCESS_DELETE Delete access immediately	✅				✅
ACCESS_REQUEST Request access on behalf of the team	✅	✅	✅	✅
ACCESS_APPROVE Approve access	✅	✅			✅
ACCESS_TERMINATE Terminate access	✅	✅	✅
TEAM_ADD Create subteams	✅
TEAM_EDIT Edit the team	✅
TEAM_DELETE Delete the team	✅
TEAM_API_KEY_MANAGE Manage the team's API keys	✅	✅	✅
TEAM_MEMBER_ADD Add team members	✅
TEAM_MEMBER_EDIT Edit team members and their roles	✅
TEAM_MEMBER_DELETE Remove team members	✅
INGESTION_EDIT Edit ingestions	✅

Permissions describes each permission in detail.

Roles are inherited along the domain & team hierarchy. For example, a user who is Owner of a domain is also Owner of all teams within that domain.

Governance Group

The team of type Governance Group owns the organization's policies by convention. Membership in the Governance Group, regardless of role, allows adding, editing and deleting policies and managing certifications and classifications. Organization owners can do the same, and so can users who hold an edit permission on the Governance Group through a role on a team above it. Running policy checks for the whole organization (re-running a policy, flagging false positives) takes POLICY_CHECK_RUN held in the group.

Custom Team Roles

You can create custom roles based on the supported permissions under Settings → Team Roles, or through the team roles API.

Permissions

There is one permission per resource and action. The roles pages show each permission by its technical name — the name the API and role definitions use — with a description underneath. A permission never implies another one: editing a data contract does not let you run its tests, and running tests does not let you edit the contract. Combine permissions in a role to describe what its holders may do.

Every permission applies to the resources owned by the team the role is held in (and, by inheritance, by the teams below it). A resource without an owning team (a semantic namespace can be unowned) can only be changed by organization owners.

Data Products

• DATAPRODUCT_ADD, DATAPRODUCT_EDIT, DATAPRODUCT_DELETE: Can add, edit and delete the team's data products, including their output ports, input ports and assigned assets. Editing covers the data a product carries besides its document: recording and removing costs, and publishing and retracting lineage through the API (integrations that publish for the whole organization use an organization-scoped key instead).
• DATAPRODUCT_CHANGE_REQUEST_SUBMIT, DATAPRODUCT_CHANGE_REQUEST_APPROVE: With the change process on, can propose adding, editing or deleting a data product as a change request, and approve such requests (not one's own).
• DATAPRODUCT_PUBLISH: Can publish a data product to the marketplace and take a published one back off it. Editing is deliberately not enough.
• DATAPRODUCT_GIT_CONNECT: Can connect a data product to a git repository, and pull from and push to it.
• DATAPRODUCT_TEST_RESULTS_EDIT (deprecated): Accepted for test results that only name a data product. Test results belong to the data contract — grant DATACONTRACT_TEST_RESULTS_EDIT instead.

Data Contracts

• DATACONTRACT_ADD, DATACONTRACT_EDIT, DATACONTRACT_DELETE: Can add, edit and delete the team's data contracts.
• DATACONTRACT_CHANGE_REQUEST_SUBMIT, DATACONTRACT_CHANGE_REQUEST_APPROVE: With the change process on, can propose a change to a data contract as a change request, and approve such requests.
• DATACONTRACT_BRANCH_ADD: Can create a branch of a data contract and work on it (editing the contract also allows this). Merging a branch is editing the contract, DATACONTRACT_EDIT. Branches are a way of working, not a review gate: the change-process setting has no say over them.
• DATACONTRACT_TEST_RUN: Can run the tests of the team's data contracts. Every default role holds it.
• DATACONTRACT_TEST_RESULTS_EDIT: Can publish test results for the team's data contracts, and delete them again.
• DATACONTRACT_GIT_CONNECT: Can connect a data contract to a git repository, and pull from and push to it.

Semantic Namespaces

• SEMANTIC_NAMESPACE_ADD, SEMANTIC_NAMESPACE_EDIT, SEMANTIC_NAMESPACE_DELETE: Can add, edit and delete the team's semantic namespaces and their concepts.
• SEMANTIC_NAMESPACE_BRANCH_ADD: Can create a branch of a namespace and work on it (editing the namespace also allows this). Merging a branch is editing the namespace, SEMANTIC_NAMESPACE_EDIT. A namespace is proposed to on a branch, not through a change request, so the permission is named after the branching feature; the change-process setting has no say over branches.
• SEMANTIC_NAMESPACE_GIT_CONNECT: Can connect a semantic namespace to a git repository, and pull from and push to it.

Managed tags

• MANAGED_TAG_ADD, MANAGED_TAG_EDIT, MANAGED_TAG_DELETE: Can define, edit and delete the team's managed tags. Attaching a tag to a resource is editing that resource, not a tag permission.
• MANAGED_TAG_CHANGE_REQUEST_SUBMIT, MANAGED_TAG_CHANGE_REQUEST_APPROVE: With the change process on, can propose a change to a tag as a change request, and approve such requests.

Assets

• ASSET_ADD, ASSET_EDIT, ASSET_DELETE: Can add, edit and delete the team's assets.
• ASSET_CHANGE_REQUEST_SUBMIT, ASSET_CHANGE_REQUEST_APPROVE: With the change process on, can propose a change to an asset as a change request, and approve such requests.

Policies

• POLICY_CHECK_RUN: Can run policy checks on the team's resources — or on everything, including re-running a policy and flagging false positives, when held in the Governance Group. Every default role holds it.

Business Definitions (deprecated)

• DEFINITION_ADD, DEFINITION_EDIT, DEFINITION_DELETE: Can add, edit and delete the team's business definitions.

Source Systems (deprecated)

• SOURCE_SYSTEM_ADD, SOURCE_SYSTEM_EDIT, SOURCE_SYSTEM_DELETE: Can add, edit and delete the team's source systems.

Access

• ACCESS_ADD: Can add access to a data product output port without request and approval workflow.
• ACCESS_EDIT: Can edit existing access agreements. When access has been approved, only the provider can edit the access.
• ACCESS_DELETE: Can delete existing access immediately.
• ACCESS_REQUEST: Can request access on behalf of the team or the team-owned data products.
• ACCESS_APPROVE: Can approve access requests. New access requests are emailed to the members of the providing team whose role holds this permission.
• ACCESS_TERMINATE: Can terminate access agreements as provider or consumer.

Team

• TEAM_ADD: Can create subteams.
• TEAM_EDIT: Can edit its own team. Does not include editing team members.
• TEAM_DELETE: Can delete its own team.
• TEAM_API_KEY_MANAGE: Can create and delete API keys scoped to the team.
• TEAM_MEMBER_ADD: Can add team members.
• TEAM_MEMBER_EDIT: Can edit team members and their roles.
• TEAM_MEMBER_DELETE: Can remove team members from the team.

Ingestion

• INGESTION_EDIT: Can edit the team's ingestions, including triggering and cancelling ingestion runs.

Retired permissions

RESOURCES_ADD, RESOURCES_EDIT, RESOURCES_DELETE, TEST_EXECUTE, TEST_RESULTS_WRITE, CHANGE_REQUEST_SUBMIT and CHANGE_REQUEST_APPROVE guarded every kind of resource at once and have been replaced by the permissions above. Existing custom roles were converted on upgrade, each retired permission becoming the per-resource permissions it used to stand for, so no role lost anything. The team roles API keeps accepting the retired names and expands them the same way, so role definitions kept in infrastructure-as-code keep applying unchanged; GET /api/settings/team-roles always returns the expanded names, which such a tool reports as a difference until the definition is rewritten.

Retired name	Expands to
RESOURCES_ADD	DATAPRODUCT_ADD, DATACONTRACT_ADD, SEMANTIC_NAMESPACE_ADD, MANAGED_TAG_ADD, ASSET_ADD, DEFINITION_ADD, SOURCE_SYSTEM_ADD
RESOURCES_EDIT	DATAPRODUCT_EDIT, DATACONTRACT_EDIT, SEMANTIC_NAMESPACE_EDIT, MANAGED_TAG_EDIT, ASSET_EDIT, DEFINITION_EDIT, SOURCE_SYSTEM_EDIT, DATAPRODUCT_GIT_CONNECT, DATACONTRACT_GIT_CONNECT, SEMANTIC_NAMESPACE_GIT_CONNECT, DATACONTRACT_TEST_RUN, DATACONTRACT_TEST_RESULTS_EDIT, DATAPRODUCT_TEST_RESULTS_EDIT, POLICY_CHECK_RUN, TEAM_API_KEY_MANAGE, DATACONTRACT_BRANCH_ADD
RESOURCES_DELETE	DATAPRODUCT_DELETE, DATACONTRACT_DELETE, SEMANTIC_NAMESPACE_DELETE, MANAGED_TAG_DELETE, ASSET_DELETE, DEFINITION_DELETE, SOURCE_SYSTEM_DELETE
TEST_EXECUTE	DATACONTRACT_TEST_RUN
TEST_RESULTS_WRITE	DATACONTRACT_TEST_RESULTS_EDIT, DATAPRODUCT_TEST_RESULTS_EDIT
CHANGE_REQUEST_SUBMIT	DATAPRODUCT_CHANGE_REQUEST_SUBMIT, DATACONTRACT_CHANGE_REQUEST_SUBMIT, SEMANTIC_NAMESPACE_BRANCH_ADD, MANAGED_TAG_CHANGE_REQUEST_SUBMIT, ASSET_CHANGE_REQUEST_SUBMIT, DATACONTRACT_BRANCH_ADD
CHANGE_REQUEST_APPROVE	DATAPRODUCT_CHANGE_REQUEST_APPROVE, DATACONTRACT_CHANGE_REQUEST_APPROVE, MANAGED_TAG_CHANGE_REQUEST_APPROVE, ASSET_CHANGE_REQUEST_APPROVE

API keys and permissions

An API key carries a scope, not a role:

• An organization key acts with organization-owner authority; its read-only variant reads everything and writes nothing.
• A team key acts for its team and the teams below it, without evaluating team permissions; its read-only variant reads that subtree.
• A user key acts as that user: the user's team roles and their permissions decide, exactly as in the UI.

The API writes a resource with PUT, which creates or updates: creating takes the resource's *_ADD permission on the team it is placed in, updating takes *_EDIT on the team that owns it, and moving it to another team takes both.