Configuration brings together Dova Integration Runtime, Execution profiles, Workflow Scheduler, Runtime health and Promotions. Policies select authorized capacity; profiles express limits; calendars schedule future orchestration; health describes current observations. Saving a policy does not establish that a worker is available or that an attempt completed successfully.
Before you begin
Confirm tenant and permissions before saving. Record the baseline so laboratory changes can be restored. Distinguish the default worker from a Session override and schedule timezone from Profile display timezone.
Procedure
- Open Configuration and identify which of its areas addresses your need. Inspect before editing.
- In Dova Integration Runtime, review the default worker and offered selection or affinity options. Check eligibility in Workers.
- Compare a Session using Use tenant default with one using a permitted override. An override does not change the default for other Sessions.
- In Execution profiles, inspect units and limits of the authorized profile. Change values only for a concrete operational reason and check inheritance.
- In Workflow Scheduler, review calendar, timezone and enabled state. Associate it with the intended published Workflow after a successful manual test.
- Save reviewed fields, wait for acceptance and reopen to confirm persistence. When nothing changed, Save can correctly remain disabled.
- Inspect Runtime health separately and continue in Workers or Monitor to verify capacity and actual attempts.
Verify the result
Two synthetic Sessions, one using the default and one with a compatible override, show the expected worker in execution context. For a calendar, record timezone, next planned time and resulting run identifier; these are separate checks.
Errors and recovery
Do not increase limits to conceal an unavailable worker. Correct invalid units or ranges. Following a concurrent change, reload the baseline and compare before resubmitting. Disable temporary schedules when finished: closing Configuration does not disable them.
Synthetic example
Use Training with s_Default and s_Override. Keep transformations equal and change only the permitted worker selection; compare both attempts in Monitor.
Verification scope
Use synthetic data and the role authorized for the task. Compare a visual confirmation with the saved record or relevant attempt. Retain only safe identifiers and messages for support; do not share secrets, personal information or tenant data. If an operation outcome is uncertain, check its state before repeating it.
Environment promotions
Open Configuration → Environment promotions. Select a published Mapping, Session or Workflow and its source version. The permitted order is Development → Test → Production (Stage is optional when enabled). Each promotion keeps the exact Session and Mapping dependencies and creates separately published destination artifacts; source-environment originals remain intact.
- Choose the next environment and define Connection replacements and Session settings: worker, profile, parameters, input and output bindings. Use existing IDs; credentials remain protected in Dova.
- Complete Git provenance with an HTTPS repository and full commit SHA or tag when applicable.
- Select Review promotion. Inspect dependencies, version changes, compatible workers, plan capabilities, available DPU and concurrency. Development, Test and Stage use Development processing; Production uses Production processing.
- Apply only the reviewed preview and confirm. Production additionally requires approval permission and a comment. If destination state, definitions or plan change, review again.
- Verify history and the resulting artifacts. Promotion does not execute the Workflow or enable its schedules; enable scheduling only after acceptance.
Export manifest downloads the immutable manifest and provenance for your repository or DevOps process. It contains neither credentials nor usable secret references. Dova does not push commits or activate GitHub Actions.
Restore this release restores historical definitions and environment settings through new destination versions, subject to authorization, confirmation and current checks. It does not undo written files, loads or external data changes. Revision and idempotency checks protect against duplicate application; after a conflict, refresh and compare before confirming again.
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 worker pool
In Configuration → Dova Integration Runtime, Environment worker pool identifies the current environment. Allowed workers assigns existing workers; Default worker must belong to that selection. Pool policy starts as Dedicated. Select Shared only when you explicitly want to share capacity and every participating pool also declares Shared. A matching name does not share a physical worker.
Save environment pool changes only the selected environment’s policy and neither starts a job nor changes the tenant’s global default. The review uses a configuration fingerprint; if another user changes it, Refresh pool lets you reload and review before saving. Controls require configuration and environment Runtime administration. Built-in is not offered as an execution worker.
Without an explicit pool, Production does not borrow Development capacity and new jobs do not run through an implicit default. Legacy execution can retain an earlier worker only when the server verifies the exact published chain, configuration and permitted membership. Test and Stage consume the plan’s Development bucket; Production uses the Production bucket. Pool membership does not replace capacity, online status, profile compatibility, quotas or concurrency.
Colors per Tenant and Environment
Color identifies the active context in the bottom operational status bar summary, environment badge and Environment select border. Defaults are blue for Development, amber for Test, violet for Stage and red for Production. The environment name or code stays visible; color does not grant access or change your personal palette.
To customize it, first choose Tenant and Environment in the user menu, then open Configuration → Miscellaneous → Environment colors. Choose a color or enter a six-digit hexadecimal value, review the preview and use Save color. The setting is shared for that Tenant+Environment, including across Domains. Restore default prepares the default value and Save color applies it. Refresh loads the current configuration after a concurrent change. Configuration management permission is required; there is no separate per-Domain color or additional Tenant-wide base-color selector.
Pool profiles and limits
In Configuration → Dova Integration Runtime, the environment pool lets you choose Allowed workers, Default worker and Dedicated or Shared policy. A worker can belong to multiple environments only when all participating pools declare Shared. Available options also restrict execution profiles and default profile, concurrent slots, timeout and attempts. Review and save the selected environment’s policy; these limits do not replace capacity, heartbeat, compatibility or plan quotas.