Access and permissions

Your session has one active organisation. Its type catalogue gives projects a shared vocabulary; project grants control the engineering data you can work with. Select the intended organisation and project before acting in the workspace or attaching the CLI.

Where changes live

Work	Scope and approval
Read or edit objects and relationships	Project access and the selected engineering branch; protected work has additional rules
Create branches and review proposals	Project capabilities, including separate authority to merge
Publish types and views	Organisation catalogue change set; permission to publish is separate from object editing
Create projects and manage membership	Administration capabilities in the relevant scope
Create service identities and issue credentials	Organisation administration; the identity needs its own grants to read or write data

Roles bundle capabilities. The available roles and their permissions come from the deployment; a familiar role label alone is not a guarantee that a particular operation is allowed. An organisation-level membership reaches its projects; a project-level membership confines that grant to that project.

Reading a project does not imply permission to edit, publish types, administer members or merge. A relationship to another project’s object does not grant access to that object’s properties.

Manage membership in the workspace

An administrator opens Admin and chooses Organisation members. Under Grant a role, choose the Member identity, select the Scope and Role, then choose Grant role. Use project scope when the grant should apply to one project. The table shows the current scope and role for each membership.

To change an existing membership, select its role in the row and choose Change role. Revoke removes that membership. The platform checks your authority to grant or change the role; administration does not let you grant a role above your own authority.

The current picker only lists identities already represented in the organisation’s member list. Use the Administration SDK or CLI grantMembership operation for an initial grant to another existing platform identity, including a new service identity. Membership grants are separate from identity creation, email invitations and public sign-up.

Understand unavailable controls and refusals

Check the active organisation, project and branch first. A control may be absent because your identity lacks the operation’s authority or that action is not available for the current state. A displayed control can still produce a refusal when permissions or data have changed.

Preserve your draft, read the reason, and ask the instance administrator for the capability required by the operation. Do not use another person’s credential to bypass a refusal. If a write’s outcome is uncertain, inspect or recover it before repeating it.

Agents and integrations

The in-product agents act with delegated authority from the signed-in person. Plan approval narrows what a run may do; it does not add permissions the person lacks. The ontology agent drafts and validates; you publish its change set. External coding agents using your CLI or SDK session can call operations that your identity may perform, including publication, so give them explicit approval boundaries.

A service identity acts as a program with its own grants. It does not impersonate each user of an external app. See the experimental external app guide for setup and the current per-user sign-in limitation.