Select the context
The Tenant, Domain and Environment summary appears in the bottom operational status bar of Dova and Administrator. Click the summary to open the user menu with all three selectors. It retains the environment badge and color without a top strip or duplicate fields.
The user menu combines Tenant, Domain and Environment. The initial context is Development. Canonical environments are Development, Test, Stage and Production; Stage appears according to configuration and permissions. A Domain/Folder location organizes ownership and access, while the environment separates definitions and executions. Sharing a Domain does not grant access to another environment.
- Confirm the authorized Tenant.
- Select the Domain in the user menu.
- Choose Environment and wait for context loading to finish.
- Check the DEV, TEST, STAGE or PROD badge before editing or running.
Mappings, Sessions, Workflows, Connections and Monitor read the selected context. The editor’s Domain identifies the owner and is locked; Folder belongs to that owner. Use the explicit Move operation and its permissions to change location.
Save, publish and run
Save draft in DEV saves a Development draft. Publish in DEV publishes that version in the same environment. Promote to Test opens a separate destination review. Labels reflect the current environment; saving or publishing neither moves a definition between environments nor executes its data.
Authorization combines module permission, Domain access and environment and artifact capabilities. Production is read only unless explicitly authorized. An operator can have run permission without edit permission. Environment names do not grant capabilities.
Switch without mixing drafts
Tabs, filters, selection, drafts and positions are retained for each Tenant, Domain and Environment. A switch cancels previous reads and discards stale responses. The context cannot change while a write is in flight. Recovery verifies the artifact and its authorization before restoring a dirty editor.
Changing environment preserves local work without saving or publishing it to the server. Password fields and selected files are not transferred to another context. Save or close a dirty Session before changing Tenant. When the server cannot confirm the context, the platform becomes read only and offers Retry context.
Earlier definitions and recovery
The upgrade does not automatically assign all earlier artifacts to Development. Shared dependencies and published versions can remain through verified membership and exact references. An ambiguous or shared artifact can be read only; earlier local drafts remain pending recovery.
Use Fork to Development to create an editable copy. Its review includes indirect Mapping, Session or Workflow dependencies. Bind each source Connection to a compatible Connection already owned by Development. Dova does not copy credentials. The server rechecks the revision and rejects source or destination changes since preview. The copy is a draft; Open in Development is a separate explicit action. Review and publish it before execution.
See the promotion guide for the forward path to Test and Production.
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.
Public Trial: platform-managed Development pool
An eligible public Trial without an explicit Development policy can automatically use a platform-managed public Development pool. It includes only verified public shared workers authorized for that Trial; private workers and workers assigned to other configured pools are excluded. It neither saves a Runtime policy nor grants permission to manage one.
An explicit Development policy, including an empty policy, takes precedence over this automatic option. Test, Stage and Production retain their policies. Capacity remains subject to availability, profiles, quotas and concurrency; eligibility does not guarantee an available worker.
GitOps kit per workspace
The GitOps kit 1.1.2 binds Tenant, Domain and Environment for queries, draft reservations, publications and leases. Use source.environment and source.domainId for exports; target.environment and bindings.domainId for imports. Defaults are Development and General; preserve state per target. See the Finance example and state recovery. Direct Production authoring requires governed promotion rather than the import command.
Before stopping or retiring capacity
Pause VM and Stop VM retain active-work, default-worker and shared-capacity checks; review references and impact before using them. Pause scheduling stops new assignments and lets current work finish. To retire the VM permanently, use Remove VM and unlink and review its confirmation: after verifying cloud absence, Dova clears assignments and shows Unassigned without deleting definitions or published versions. Assign compatible capacity explicitly before running again.
Actions require the module permission and the relevant environment’s Runtime capability, or an explicitly granted global permission. A shared VM requires authorization across all its environments.