Managing people means managing their relationship with a specific company. A person may belong to several companies, with a different membership, role, and status in each. To assign access, distinguish tenant role, capability, and scope.
Before you start
- Role: The Administrator manages people and access for their company through
access.manage. The Superadministrator uses permitted platform authorizations; this does not make them a tenant role or bypass tenant guards. - Module: Access and Governance. Actions on governed objects remain subject to the applicable module.
- Prerequisites: Work with the effective company and an active membership. Identify in advance the Domains, Subdomains, or Repositories that will form the scope. A company that is not active must not operate normally.
The backend calculates the company, membership, capabilities, and scope from the session and registered objects, not from values sent by the browser.
The difference between role, capability, and scope
The tenant role expresses a base responsibility. There are five roles: User, Data Steward, Data Owner, Data Engineer, and Administrator. Capabilities are the authorized actions; scope defines the Domains, Subdomains, or Repositories where they may be exercised.
| Role | Main responsibility | Documented operational scope |
|---|---|---|
| User | Consultation and participation in authorized tasks. | According to the views and requests permitted by the company. |
| Data Steward | Maintain business definitions and objects; handle stewardship. | Assigned Domains and Subdomains. |
| Data Owner | Be accountable for governance in their scope and approve decisions. | Assigned Domains and Subdomains; may be global where applicable. |
| Data Engineer | Manage connectors, repositories, metadata, snapshots, and schedules. | Only Repositories with an assigned technical scope. |
| Administrator | Manage people, access, taxonomy, governance, and tenant configuration. | Global within the active company. |
An Owner or Steward may be able to view more than they can edit: creating, editing, associating, or approving requires authorized capability and scope. Data engineering operates through Repository scopes, not through general business scope.
A governance Role represents an Owner, Steward, or other catalog responsibility in a Domain or Entity, and may be related to Data Products, Data Contracts, or Workflows. It is not the membership role that authorizes the session.
Recommended workflow
- Determine the responsibility. Choose the role for participation, stewardship, ownership, data engineering, or administration. Roles and their base capabilities are the current contract; capabilities cannot be freely edited for each person.
- Assign the correct membership. Add or update the person in the target tenant. Membership does not grant access to other companies.
- Define the scope. Assign Domains/Subdomains to an Owner or Steward, or Repositories to Data Engineering. Assignments may have a status and validity period; use active assignments.
- Record the responsibility where applicable. Link the Owner or Steward to the taxonomy node if they need to appear in the catalog. This complements, but does not replace, the role or session controls.
- Review modules and impact. A person cannot operate a disabled module. Check the company, scope, and object; a visible button does not prove authorization.
- Treat changes as sensitive. Role or scope changes revoke sessions. The person must continue with a valid session; no specific duration is documented.
Synthetic example: Lucía is assigned the Data Steward role and the “Citizen Services” Domain. She can maintain objects there if the module and capability allow it. A request from another Domain does not expand her authorization: a registered assignment is required.
Assignment controls and limits
The company can assign Domains, Subdomains, and Repositories, create responsibilities, and define roles for Workflows. These are not arbitrary permissions: base backend capabilities remain unchanged. Temporary views are read-only, except for permitted mutations of access requests.
Active membership, company status, and module are checked in addition to capability and scope. A shared identifier or name does not authorize an action; a high-level link does not associate or authorize all fields of a source.
Expected outcome
Each person has a valid membership, an appropriate role, and an explicit business or technical scope. Visible responsibilities complement, but do not replace, authorization. Writes are limited to the effective scope and the correct company.