Authorization context
Identity, tenant membership and the selected role determine the working context. A Repository location does not replace those checks. An active account may have an inactive membership; a visible role does not automatically grant every permission. The server checks current authority for each action and may reject an operation that was previously available.
Do not confuse Administrator access with the platform's unique master identity. The master user's DovaAI quota exemption requires the persisted identity, active membership and selected platform role. It is not granted to every administrator or by matching an email address. Provider readiness and authorization controls still apply.
Review an action
| Goal | What to check |
|---|---|
| Read | Tenant, membership and module or object read permission |
| Edit | Change permission, current version and editable state |
| Publish | Saved draft, dependencies and publication permission |
| Execute | Execution permission, plan, runtime, capacity and Connections |
| Delete or purge | Scope, references, blockers and current confirmation |
Authorization does not guarantee available resources. A valid plan does not grant missing permissions either. Being able to view a Session does not mean it can be executed, and publishing a Workflow does not itself activate a schedule. Check the specific operation rather than inferring privileges from a module name.
Investigate denied access
- Inspect your identity and tenant in the current account context.
- Confirm the selected role and active membership.
- Identify the actual action: reading, editing, publishing, executing or deleting.
- Ask an administrator to review that authorization and scope without indiscriminately expanding privileges.
- Refresh the view after an accepted change and check the resource again.
For a synthetic exercise, someone who only needs to inspect Monitor should review authorized attempts and results, not receive Repository purge permission. Delegate the required action rather than a larger permission set intended to hide a configuration problem.
Tenant and execution boundaries
A public worker shares eligible capacity; it does not share other tenants' objects, conversations or data. Connections retain their own restrictions. DovaAI reads and recommends within authorized scope. It never creates, edits, publishes, runs or deletes artifacts, even when requested or confirmed; a chat instruction cannot grant new permissions.
If identity, tenant or permissions change during an operation, the context must be checked again. Do not reuse an old confirmation or treat a hidden button as the sole security control. The server response and accepted object state determine the outcome. Keep authorized audit evidence without copying credentials or another tenant's information.
Environment context
Before using this module, confirm Tenant, Domain and Environment in the user menu. The initial environment is Development. Module, Domain and environment capabilities apply together; Production is read only without explicit authorization. Switching the selector does not move artifacts or publish or execute their data. See environments and recovery and environment promotion.
Environment permissions
Authorization combines module permissions, Domain access and environment capabilities. The current catalog contains 23 environment permissions: etl.environments.view, etl.environments.{development,test,stage,production}.{view,edit,publish,run,runtime.manage}, etl.environments.promote and etl.environments.runtime.manage. Global view and Runtime grants retain their explicit scope; a grant for one environment does not grant access to all others. Module management does not replace these capabilities.
ETL Developer can work in Development, Test and Stage and has no Production access by default. Release Manager can review all four environments and publish into Test, Stage and Production for authorized promotions; this does not grant Production editing or execution. Promotion retains preview, exact published dependencies and explicit Production approval. Custom roles can grant the required capabilities per environment. A user identity is not duplicated per environment; check the active role, membership and effective permissions.
Production Mapping, Session and Workflow editors remain read only: accepted versions arrive through promotion. Configuring existing or new Production Connections is a separate capability requiring etl.connections.manage and etl.environments.production.edit; it does not unlock those three editors or legacy read-only Connections.