Workers execute Sessions and Workflows under tenant policy. Heartbeat, VM power state and eligibility are different observations. A public worker can offer shared capacity; assigning a Session to it does not publish its definition, data or artifacts to other users or tenants.
Before you begin
Prepare an authorized host and know its owner. You need compatible capacity, permissions and network access to process resources. Input files must be available to the worker; selecting it does not copy them automatically.
Procedure
- Open Workers and identify the record by identifier, tenant or pool and recent heartbeat. Do not rely on its name alone.
- Open details and inspect version, resources, connectors and slots. Compare these with Session requirements and the Execution profile.
- If registering a host, use authorized enrollment and keep the token within protected input. Confirm a valid heartbeat appears.
- Distinguish restarting the worker service from powering on a provider VM. Provisioning and provider controls belong to Administrator.
- Choose the default or a permitted explicit assignment. Check that the identity can resolve Connections and access the input file.
- Run a synthetic Session and verify in Monitor which worker received the attempt and its result.
- Before retiring or replacing capacity, inspect active jobs, references, default policies and dependencies.
Verify the result
The record is current, eligible for the task and completes a test with known output. Slots are weighted units: four slots can accept four weight-one jobs or two weight-two jobs, subject to other limits. Online does not mean unlimited capacity.
Errors and recovery
For missing heartbeat, inspect service and permitted connectivity. For ineligibility, inspect policies, capabilities, resources and lifecycle. Provider unavailable does not prove the VM is absent. Resolve failed removal through the supported procedure rather than deleting records to hide the problem.
Synthetic example
Assign s_CustomerNames to lab-worker with a synthetic CSV available there. Check the worker identifier and Mapping version used by the attempt.
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 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.
Production does not automatically borrow the Development pool. New jobs require an explicit pool, apart from the public Development option for an eligible Trial described below. 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.
Public Trial: platform-managed Development pool
For an eligible public Trial without an explicit Development policy, Dova derives a platform-managed public Development pool. It selects only public shared workers with verified references, authorized for the Trial and absent from other configured pools. It does not include private workers, create workers or save Runtime changes. The Trial does not gain permission to save pools.
An explicit Development policy, including an empty Allowed workers selection, takes precedence. This mechanism does not extend to Test, Stage or Production. Capacity, profile, isolation, quota and concurrency checks still apply; public access does not guarantee availability.
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.
Removal and later assignment
Open Remove VM and unlink, review resource identity and impact on Sessions, executions and pools, then confirm the intended deletion. For a supported owned VM, manually dismantling every reference or first powering it off is not a prerequisite for this operation. Removing capacity can interrupt active executions; schedule the operation to suit your needs.
After confirming provider absence, Dova retires the active worker, clears Runtime references and shows Unassigned for Session bindings that used it. Definitions, published versions, configuration and audit history are preserved. If the VM is deleted directly in the provider, reconciliation applies the same treatment after verifying absence. A provider-read error is not evidence that the VM was deleted.
Before running again, select compatible authorized capacity and review the environment pool. Unassigned does not silently choose another worker. You can provision a new VM and assign it explicitly. Permissions, resource ownership, the protected base server and pending operations remain checked; removal does not bypass these protections.