Files for your first Workflow

For the complete route, use this edition’s small fixture: four synthetic customers, three with status=ACTIVE. Download the input and keep the expected result separately.

• active-customers-input.csvFour-row input · CSV · 147 BDownload
• active-customers-expected.csvThree-row expected result · CSV · 89 BDownload
• README.mdLaboratory instructions · Markdown · 2.0 kBDownload

Configure Flat File input → Row filter (field=status, operator=equals, value=ACTIVE) → Field selector (fields=customer_id, name, amount) → Flat File output. Publish the Mapping, then continue with this guide’s Session and Workflow. Output must contain only customer_id, name and amount, with D001/Demo Alfa/125.50, D003/Demo Gamma/80.00 and D004/Demo Delta/0.00. Without an explicit Row sort, compare records by identifier rather than treating source order as a universal guarantee. Decimal serialization and line endings may differ: acceptance checks schema and values rather than byte identity. Following this browser route does not require a private source checkout.

This laboratory connects organization, transformation, execution and verification. Its goal is a CSV whose contents you can check, with the executed versions and runtime conditions clearly identified. Use synthetic data and output locations isolated from operational processes.

Prepare your workspace

Sign in with an authorized identity and check the active tenant and role in the account menu. The same person may have several contexts; an object's name alone does not establish its scope. Open Repository and select a laboratory Domain and Folder. If your role cannot create them, have an administrator prepare the location.

Use recognizable names, such as a lab_ prefix, and record how your Mapping, Session and Workflow relate. Do not reuse production object identifiers. Prepare input and output directories accessible to the selected worker. A file on your browser computer is not automatically available on that remote worker. Configure credentials through Connections, rather than sample rows or file names.

Design and validate the Mapping

The Mapping defines data operations. Start with Flat File input, one simple transformation and Flat File output. Review delimiter, encoding, field names and empty values. Use the normalization demonstration when you are ready for a longer chain.

1. In Mappings, choose New Mapping and enter the laboratory name, Domain and Folder.
2. Add components from the palette and configure each selected component in its inspector.
3. Connect source, transformation and target ports in business-rule order.
4. Choose Validate and resolve its messages. Arrange and Fit change the view, rather than transformation rules.
5. Choose Save draft, then Publish. Accept the publication confirmation and check the persisted version.

A filter before conversion may behave differently from the same filter after conversion. Saving a draft does not publish it, and publishing does not start execution. If you use Run directly in the Mapping, follow the file-upload route without creating the objects in the next sections.

Bind the Session

The Session associates a published Mapping with its execution context. Create a laboratory Session, select the Mapping and check its version. Set the test environment, execution profile and worker policy. Keep the tenant default unless an authorized override is deliberately needed.

In File paths, bind every source and target node identifier to a path the worker can access. In the simple example, source_csv reads customers and target_csv writes the result. Use a destination exclusive to the laboratory. A valid file bound to the wrong node is still an incorrect binding.

The worker must be enabled, eligible, compatible and have available capacity. Check heartbeat and slots in Workers; a powered-on VM does not prove that its agent can execute the task. Review typed parameters and their resolution preview, then save, validate and publish the Session.

Orchestrate and run manually

Create a Workflow with Start → Session → End. Select your published Session in the task, check its version and connect success dependencies. A Workflow needs exactly one Start, at least one End, and valid reachable paths without cycles. Task names must be unique within the design.

Validate, save the draft and publish. Run manually in the laboratory and record the new attempt identifier. Values overridden for that attempt do not permanently edit the Session or Workflow. Add Decision or Timer only after the basic case matches its expected result; Timer waits a number of seconds rather than creating a recurring schedule.

Leave scheduling disabled until you have verified the manual behavior, actual destination and recorded evidence. After updating a Mapping or Session, review and publish its consumers deliberately; an open draft does not silently replace a version pinned by an execution.

Verify and close the test

Open Monitor and follow the attempt to a terminal state. Accepted or queued does not establish that the output exists. Expand tasks and inspect the first relevant error and available logs. Use Download output when a succeeded attempt has a stored result; for worker files or tables, inspect the authorized destination itself.

Compare header, values, row count and physical order with an independently defined expected result. Record tenant, Domain, Folder, versions, attempt ID, count and destination without secrets. Investigate parsing, bindings and transform order before repeating a write to a shared destination.

Once stable, prepare a schedule in Configuration → Workflow Scheduler with an explicit timezone. Check the next planned execution and an actual resulting attempt separately. Before moving environments, recheck permissions, paths, connections and capacity. A local rule test does not certify destination infrastructure.

First, this guide presents an exercise you can build in the Dova 22.0.5 browser interface. It then preserves a local 1,000-row laboratory for readers with an authorized engine checkout. These are different fixtures: keep their files, rules and expected counts separate.

CSV demonstration: from 18 to 10 rows

The public files and screenshots come from a preserved genuine Dova 20.0.4 demonstration. Their bytes and counts were rechecked for this edition, and component fields were reviewed against active 22.0.5 source. This guide does not claim that a new 22.0.5 attempt was executed during its preparation.

Download the synthetic input CSV and keep the reference result separately. Input has 18 records and eight columns; output has 10 records and six columns. Names, zones and identifiers are explicitly marked DEMO.

• customers-demo.csvSynthetic input (18 rows) · CSV · 2.2 kBOpen file
• clientes-demo-excel.csvReference output (10 rows) · CSV · 773 BOpen file

One record before and after

This excerpt shows DEMO-C002, rather than the complete file. Extra spaces are removed and text becomes uppercase; HABILITADO becomes ACTIVO. The amount is numeric: 2500.0 and 2500.00 represent the same value in this fixture.

customer_id,full_name,city,segment,status,credit_limit,demo_row_ref,internal_note
DEMO-C002, cliente   demo beta ,zona demo sur, empresa demo , habilitado ,2500.00,DEMO-R02,MUESTRA SINTETICA; SIN DATOS REALES

cliente_id,cliente_nombre,ciudad,segmento,estado,limite_credito
DEMO-C002,CLIENTE DEMO BETA,ZONA DEMO SUR,EMPRESA DEMO,ACTIVO,2500.0

Configure all twelve components

Create a Mapping in your laboratory Domain and Folder. Add the table components and connect one linear chain in the listed order. Each block shows the technical configuration corresponding to inspector controls. It is not an import document, and you do not paste it into the read-only Advanced view. Your own design generates its node identifiers.

{
  "format": "csv",
  "delimiter": ",",
  "hasHeader": true,
  "headerRowNumber": 1,
  "columns": [
    "customer_id",
    "full_name",
    "city",
    "segment",
    "status",
    "credit_limit",
    "demo_row_ref",
    "internal_note"
  ],
  "headerMappings": [],
  "encoding": "utf-8"
}

{
  "fields": [
    "customer_id",
    "full_name",
    "city",
    "segment",
    "status",
    "credit_limit"
  ],
  "operations": [
    "trim",
    "collapse_whitespace",
    "upper"
  ]
}

{
  "field": "status",
  "find": "HABILITADO",
  "replacement": "ACTIVO",
  "matchMode": "exact",
  "caseSensitive": true
}

{
  "field": "status",
  "operator": "equals",
  "value": "ACTIVO"
}

{
  "field": "customer_id",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "full_name",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "credit_limit",
  "operator": "not_empty",
  "value": ""
}

{
  "field": "credit_limit",
  "targetType": "number",
  "outputField": "",
  "onError": "fail",
  "defaultValue": ""
}

{
  "mapping": {
    "customer_id": "cliente_id",
    "full_name": "cliente_nombre",
    "city": "ciudad",
    "segment": "segmento",
    "status": "estado",
    "credit_limit": "limite_credito"
  }
}

{
  "fields": [
    "cliente_id",
    "cliente_nombre",
    "ciudad",
    "segmento",
    "estado",
    "limite_credito"
  ]
}

{
  "field": "cliente_id",
  "direction": "asc"
}

{
  "format": "csv",
  "fileName": "clientes-demo-excel.csv",
  "delimiter": ",",
  "includeHeader": true,
  "textQualifier": "double",
  "quoteMode": "minimal",
  "escapeCharacter": "\\",
  "lineEnding": "crlf",
  "encoding": "utf-8-bom",
  "nullValue": ""
}

Ten transformations sit between source and target: cleaning, replacement, four filters, conversion, renaming, selection and sorting. All four filters must precede Convert type: an inactive fixture record contains an invalid amount and must be excluded before conversion. not_empty checks the cleaned value is present; it does not prove that any arbitrary text is numeric.

Publish and run from the browser

1. Choose Validate and resolve its messages, then Save draft.
2. Choose Publish, confirm publication and check the persisted version. Later edits require saving and publishing again.
3. Click Run in the Mapping. Select customers-demo.csv in the CSV file picker. This direct test does not require an S3 Connection, Session or Workflow.
4. Follow the attempt in Monitor and record its identifier. Wait for terminal success; queued or an accepted request is not completion.
5. Choose Download output when the succeeded attempt has a stored result. Save the downloaded CSV separately from the reference file.
6. Compare the actual download with the expected result, without reordering or editing it to force a match.

Acceptance criteria

Check the exact header, six columns and ten data records, unique identifiers and physical ascending cliente_id order, normalized text and ACTIVO status, and numerically equivalent amounts. Confirm demo_row_ref and internal_note are absent. The target configures UTF-8 BOM and CRLF for a CSV that Excel can open or import. It remains CSV, rather than an XLSX workbook.

For missing rows, inspect the first filter excluding each record. If Convert type fails, check preceding filters and the accepted amount. For incorrect columns, review Field mapper and Field selector. If Download output is unavailable, check terminal state, stored output and permission; publication alone does not produce a file.

View genuine screenshots of the 16 demonstration steps

Additional local laboratory: 1,000 rows → 667

This local package belongs to the 6.0.2 laboratory and preserves its original verification. Its 667-row result is that fixture’s expected acceptance criterion, not a newly executed 22.0.5 run. It requires an authorized checkout; use the demonstration above for browser-only learning.

This laboratory processes 1,000 synthetic CSV rows through eight Transform components and expects 667 normalized output rows. It demonstrates text cleanup, replacement, field splitting, concatenation, calculated fields, conversion, filtering and numeric sorting. Names and values are repeatable fixtures, not records of real people.

Use the existing historical sample package · laboratorios-dova-6.0.2.zipZIP · 43.8 kBDownload. The fixture format remains applicable to the documented transformation model; the package version is separate from the Dova 7 interface. It contains the sample inputs, expected outputs and coherent Mapping/Session/Workflow definitions. The ZIP is a fixture runner, not the Dova engine, and requires an authorized source checkout with the documented Python dependencies.

The local transformation verification and a server Workflow run are separate exercises.

1. Inspect the data and expected result

After extracting the package, inspect transform_workflows/inputs/customers.csv. Its fields include customer_id, raw_name, location, amount and status. It intentionally contains repeated spaces, accents, a vertical-bar location separator and alternating ACTIVE, ENABLED and INACTIVE states.

Inspect transform_workflows/expected/customer_normalized.csv independently. Do not generate your expected output by simply copying a new engine result. The supplied independent Python oracle establishes the expected values, ordering and byte representation.

2. Review the eight transformations

Replace precedes Filter, so rows originally marked ENABLED are accepted. Conversion precedes Sort so the order is numeric rather than lexical. Inspect those dependencies before moving components on the canvas.

3. Run the isolated verifier

From the extracted package directory, point the runner to your authorized source checkout:

python .\run_pocs.py --repo C:\path\DovaETL --report .\verification.json

Replace the illustrative path. The runner does not start a server, create tenant objects or access network endpoints. It copies synthetic inputs into a temporary directory, validates definitions and verifies both documented laboratories. The optional report contains safe counts, hashes and comparison results.

If a dependency is missing, follow the project's authorized dependency setup. Do not modify expected CSVs to make a mismatch disappear. Inspect the first error and the fixture integrity result.

4. Check acceptance

Confirm 1,000 source rows, 667 output rows and byte-for-byte equality with both the independent oracle and supplied expected CSV. Inspect the columns and descending amount order as additional human checks. A correct count alone would not reveal an incorrect key, segment or sort order.

5. Reproduce through the UI

Review the definition in Mappings, configure all bindings in Sessions, and publish a laboratory Workflow. Use worker-accessible synthetic files and an exclusive destination. Run manually and inspect Monitor. Record the actual published dependency versions and run identifier, then compare the server output with the same expected result.

Local verification demonstrates transformation behavior for these fixtures. It does not establish remote worker authentication, storage permissions or production capacity. For a mismatch, inspect Replace/Filter ordering, numeric conversion, the split delimiter and output serialization before changing the oracle.

This example combines 1,000 synthetic pipe-delimited transactions with a 1,000-row Excel customer catalog. It filters approved transactions, joins customers to regions and produces a four-row CSV summary. The expected result is calculated by an independent oracle instead of reusing the engine's Join or Aggregate implementations.

Download the existing synthetic fixture package, edition 6.0.2 · laboratorios-dova-6.0.2.zipZIP · 43.8 kBDownload and extract it. The preserved fixture package is separate from the current product release. Use an authorized DovaETL source checkout and its required Python dependencies. No customer transactions, payment provider or external connection is involved in the isolated exercise.

1. Review both inputs

transform_workflows/inputs/transactions.txt contains customer_id, amount and status. Every fifth transaction is REJECTED; the others are APPROVED. Identifiers and amounts initially arrive as text.

transform_workflows/inputs/customers.xlsx contains a Customers sheet with a header and 1,000 rows in columns A–C: customer_id, customer_name and region. Its identifier is numeric, and text contains deliberate accent and spacing variations. The expected CSV contains exactly sales_region and approved_total.

2. Inspect the component order

The two input branches let you diagnose parsing before blaming the join. Numeric key normalization matters because one identifier comes from text and the other from an Excel cell. Duplicate customer keys can multiply joined records and inflate an aggregate.

3. Execute the isolated verification

Run from the extracted fixture directory:

python .\run_pocs.py --repo C:\path\DovaETL --report .\verification.json

The wrapper verifies both laboratories. It checks fixture integrity, validates definitions, resolves the source_txt and source_xlsx bindings, and verifies the reported 1,000 rows for the Customers sheet. Network and persistent application-storage access are forbidden by the runner. The optional JSON report records synthetic evidence only.

4. Accept the result

Confirm four rows and byte-for-byte equality with the independent oracle and expected/regional_approved_totals.csv. The oracle builds a region lookup by integer identifier, skips rejected transactions, sums by normalized region and sorts. Inspect exactly two output fields, UTF-8 encoding, header and LF line endings.

The sample's number representation does not establish a universal accounting or rounding policy. For a real financial process, define precision, scale, currency and rounding separately before implementing the rule.

5. Move into a laboratory Workflow

Publish the Mapping, then configure both source bindings in the Session. A single uploaded file does not replace the two sources. In the CLI, use the multi-source command shape from CLI and API with actual task and node identifiers. Publish the Workflow, run it manually and compare its output in the same way.

For too few regions, inspect unmatched keys and join type. For inflated totals, inspect lookup uniqueness. For regions split by accents or spaces, inspect Excel cleanup. For additional output fields, inspect Rename, Select and the target schema. Remote file access, worker capability and authorization need their own acceptance checks.

Troubleshooting checklist

• Check both source headers, the Customers worksheet and its A:C range before blaming Join.
• Use integer join keys on both sides; nulls do not match in this fixture.
• Duplicate customer keys may multiply transactions and inflate sums.
• Normalize region before aggregation, and keep only sales_region and approved_total after renaming.
• Compare header, row values, order, numeric representation and LF endings with the independent reference. Do not replace the expected file to conceal an unexplained difference.

Operational decisions require the current identity, tenant, permitted action and actual state. This guide connects observable execution to controlled recovery and worker retirement. It does not authorize access to another tenant or provider account, nor does an operational success message establish output correctness.

Conceptual retirement path. Provider availability, active jobs and dependency checks can block progression.

1. Establish the authorized context

Open the account menu and confirm user, tenant and active role. Review the target object identifier and location. Separate permission to view from permission to edit, publish, run or administer cloud resources. Keep MFA, normal expiry and logout behavior intact while troubleshooting.

Use a laboratory tenant for demonstrations. Store no credentials in names, parameter text, screenshots or exported incident reports. A safe error message and timestamp are usually enough to begin investigation without attaching raw data.

2. Prepare an observable run

1. Record the published Workflow, Session and Mapping versions.
2. Check worker eligibility, file bindings and non-sensitive parameters.
3. Use a controlled destination and understand whether retries can duplicate writes.
4. Launch once and keep the attempt identifier.
5. Open Monitor and review task states and the first relevant safe error.
6. Inspect and compare the actual result independently after terminal success.

Queued, waiting, running and retry-wait are active states. A timeout in a browser or CLI does not prove that server work stopped. Look up the existing identifier before repeating a launch.

3. Diagnose before choosing recovery

For file errors, inspect Session paths and worker access. For authentication errors, inspect the Connection method, custody and identity permissions. For ineligible capacity, inspect worker state, capability, slots and policy. For an upstream version notice, review pinned dependencies.

Choose cancellation, termination, repeat or checkpoint recovery according to the current state and supported contract. Checkpoint recovery only applies when usable checkpoint state exists. It does not guarantee undoing side effects at an external destination. Preserve the failed attempt while validating a corrected one.

4. Reassign references before worker removal

1. Inspect the source worker's current provider state and impact.
2. Review default-worker references, active or queued jobs, Sessions, Workflows and credential dependencies.
3. Select an authorized compatible replacement or distribution.
4. Generate Preview and inspect every intended change and blocker.
5. Regenerate Preview after changing a destination or selection.
6. Apply an accepted current plan and inspect the dependency backup/result.
7. Refresh the source impact before proceeding toward retirement.

The interface manages plan tokens and request identity. Do not alter those values to bypass a conflict. Dependency backups preserve supported reference projections; they are not complete VM images or database/file backups.

5. Retire with current provider evidence

If the VM is running, Stop and deprovision asks for explicit confirmation, sends stop, refreshes impact and proceeds only when allowed. Stop and delete use separate operation identities. A stop failure must not lead to delete; a newly discovered dependency must be resolved first.

The Dova record is retired only after provider absence and final reference checks. Unavailable is not absent. Clean up Dova record is appropriate for confirmed absence, not for hiding a provider-access failure. Closing a dialog cannot undo a provider effect already accepted.

Acceptance and incident evidence

Keep identifiers, versions, timestamps, safe messages, output comparison and current provider observations. Confirm the supported result after each stage and retain audit history. Do not claim cloud cost savings until the resource is confirmed retired at the provider. Follow worker migration and backups for the detailed administrative procedure.

Choose an attempt action

• Cancel: cancel a queued Workflow.
• Terminate: request termination of an active execution and check its later result.
• Re-run: start a new attempt from the beginning with stored input and the pinned definition.
• Recover: resume failed or cancelled tasks from the available recovery point.

A client timeout does not prove cancellation. Before repeating work, inspect files and committed transactions; recovery does not automatically undo every external effect. Preserve the first relevant error, attempt identity and non-sensitive overrides so the next action has a known scope.

The CLI client version is independent of Dova 22.0.5; check the installed artifact and its help. Downloadable laboratories preserve historical fixtures and verification, whereas executing against the service creates a new attempt subject to your permissions and destinations.

The CLI can inspect authorized objects and runs and launch permitted actions. This chapter uses command shapes and routes reviewed in the current client; it is not a complete OpenAPI specification or a promise that every internal route is a stable public integration. Check your installed client's help before automating against a different release.

1. Download, verify and identify the client

Open Developer Tools, select the distribution for your platform and inspect version, signature status and SHA-256. Calculate the downloaded artifact hash and compare it exactly. Install using the distribution instructions, then run dova --version to identify the executable on your PATH.

2. Authenticate to an authorized laboratory

Create a personal API key for the exercise, then log in interactively:

dova login --url https://dova-lab.example.invalid

The .invalid host is a nonfunctional placeholder. Replace it with your permitted laboratory environment. Enter the key through the prompt, not a shared command argument. Verify the reported identity and tenant before continuing. Protect the local CLI profile because it stores authentication configuration.

3. Start with read-only operations

dova status --output json
dova repository list --domain Training --output json
dova mapping list --name sample --limit 50 --output json
dova workflow list --status published --name sample --output json
dova run list --status failed,cancelled --sort createdAt --descending --output csv

Compare identifiers with Repository, Workflows and Monitor. An empty filtered collection can be correct; a failed request must not be converted to a valid empty list. JSON is useful for explicit field processing and CSV for an authorized tabular review. Names are not guaranteed to be unique.

4. Understand the reviewed route shapes

The client uses Bearer authentication and JSON responses. Collection keys differ: Workflows use orchestrations, while attempts use runs. For direct API integrations, confirm the actual response schema and retain normal authorization, failure and tenant handling.

5. Run a published synthetic example

The local laboratories require no network. A server run is a second phase and can write outputs, so first prepare published definitions, authorized inputs and a laboratory-only destination.

dova workflow run WORKFLOW_ID --input transform_workflows/inputs/customers.csv --wait --output json

For multiple sources, repeat --source using TASK_ID:SOURCE_NODE_ID=FILE:

dova workflow run WORKFLOW_ID --source TASK_ID:source_txt=transform_workflows/inputs/transactions.txt --source TASK_ID:source_xlsx=transform_workflows/inputs/customers.xlsx --wait --output json

Replace placeholders with the actual identifiers from your published definition. Do not combine --input and --source. The client also supports --var KEY=VALUE and --param KEY=VALUE for permitted values that match the Workflow contract. Keep secrets out of ordinary overrides.

6. Wait, verify and close

--wait polls toward a terminal state; --poll and --wait-timeout bound its behavior. A client timeout does not establish server cancellation. Query the attempt again before repeating, cancelling or recovering it. Compare the generated output with the independent expected data, not just the terminal command status.

Record client version, environment, object/run identifiers, safe parameters, terminal state and result comparison. Use dova logout to remove local authentication state when done, and revoke a temporary key in the UI when it should cease working everywhere. Revocation and local logout are distinct operations.

Purpose and model

Overview combines workspace operational status: defined objects, execution activity, health and links to other areas. It provides orientation rather than business-data reconciliation. A Workflow counter represents definitions; an execution counter represents processing attempts. Neither independently proves how many customers, invoices or transactions reached the target.

The view belongs to the active tenant and role. Before interpreting a number, check both in the account menu. Available information depends on enabled permissions and capabilities. A read user can view a section without creation or run actions.

Recommended walkthrough

1. Open Overview in the left panel.
2. Review Service health and the synchronization timestamp before comparing metrics.
3. Review the Mappings, Workflows, Executions, Rows processed and Workers online cards when available.
4. Use Open Monitor, Workflows or Mappings to move from the summary to the object or execution that needs investigation.
5. Select the incident's period in the charts. Keep the same period when comparing activity and results.
6. If the view seems stale, use reload and wait for its result; a pending request is not evidence of no activity.

You can also check navigation without starting a run: locate a synthetic Workflow from the summary, open its definition and compare its latest attempt identifier with Monitor. Keep the saved definition, its published version and each execution distinct. No new attempt is needed to check that relationship.

Observability use case and proof of concept

Prepare a laboratory workspace with a published Session and a Workflow that uses it. The source must contain three synthetic rows and the target must be exclusive to the laboratory. Note object names and versions before running.

Start a manual run and preserve its identifier. Open Monitor, wait for a terminal state and check the produced file. Return to Overview and select a period that includes the test. Expect activity consistent with the Monitor record; the exact number depends on other executions and when the summary updates.

Repeat the query with an authorized read role. The proof of concept succeeds when accessible metrics remain readable and unauthorized actions stay restricted. No global permission change is necessary: use a laboratory account prepared by the administrator.

Validation, errors and recovery

An empty chart can mean no executions in the period, a filter mismatch or an incomplete query. Review the visible message and compare with Monitor before running a process again. Avoid duplicate executions merely to “make a number appear.”

If Workers are connected but tasks remain pending, review compatibility, profile, exclusions and capacity in Configuration and Workers. If platform health reports issues, record time, module and message; do not copy credentials or sensitive log content.

Relationships and scope

Overview summarizes information; version detail belongs to Mappings, Sessions and Workflows, while per-run diagnosis belongs to Monitor. This proof of concept is a proposed procedure rather than a test executed during the writing of this manual.

Purpose and model

Repository organizes work inside the active tenant using Domains and Folders. A Domain groups related work; each Folder belongs to one Domain. Mappings, Sessions, Workflows and Connections have a location that helps you find them and understand their relationships.

The hierarchy does not create another tenant or replace authorization. Shared within tenant makes an object available within its permitted scope in the same tenant. It does not publish it to another organization, move its owning location or create a duplicate.

Prerequisites and navigation

Confirm the tenant and active role in the account menu. Viewing the repository, creating locations and editing or deleting objects require the relevant permissions. A missing action can reflect authorization rather than an incomplete interface.

Use both category and location: All, Mappings, Sessions, Workflows, Connections and Shared select different views. An object can exist outside the currently selected Folder or filter.

Create a laboratory location

1. Open Repository and choose New domain.
2. Enter ETL Laboratory and a description explaining that this location contains synthetic test data.
3. Create a Folder named Customer Demo, selecting the new Domain in Parent domain.
4. Open the Folder. Check its breadcrumb and list before creating an object.
5. In the Mapping editor, select the same Domain and Folder. Save a small draft and find it again from the Mappings category.

Follow each form's displayed name and description validation. Domain names and executable-object names have separate rules; spaces accepted in a Domain do not establish valid Mapping or Session identifiers. Parent domain establishes the Folder's owner rather than a runtime file directory.

Understand Folder states

Freezing and closing serve different purposes. Opening a Closed object's Shared entry does not bypass its lifecycle state. Ask the authorized owner to review the transition rather than copying an artifact to evade the restriction.

Example: ownership and controlled sharing

Create Source and Consumer Folders in the laboratory Domain. Save a Mapping in Source and check that its editor reports that location. If permitted, enable Shared within tenant, select an authorized scope and save through the object's normal lifecycle.

From an allowed consumer location, find the Mapping under Shared. It should remain owned by Source and become discoverable only within the granted scope. A reader without the required permission must remain restricted. This exercise uses authorized laboratory identities and does not require another real customer's tenant.

Validation and recovery

For an empty list, clear filters and return to the parent location. For an invalid name, correct the indicated field without recreating the hierarchy. If deletion is refused because consumers still reference an object, inspect those dependencies first; do not assume deletion cascades.

Record the object's identifier and location before reorganizing it. Human-readable names help navigation, but object references are not ordinary filesystem paths. A successful save should be followed by checking the persisted location and finding the same object again.

Purge contents and Delete

Purge contents... permanently removes reviewed contents while preserving the selected Domain/Folder and execution history. Its preview can include artifacts, drafts, versions and child Folders. Open tabs for purged artifacts close and their unsaved changes are discarded. Delete is a separate operation that removes an eligible empty location.

1. Use a disposable laboratory and the required location-management permission. Open the correct location's menu and choose Purge contents....
2. Inspect the target name, every count and all blockers. Choose Cancel if you are only studying the form.
3. For an intentional authorized purge, type the requested name exactly and acknowledge permanent deletion.
4. Choose Purge contents once and wait. If the reviewed revision changed, use Refresh preview and confirm the updated scope again.
5. If the outcome is uncertain, use Check result before attempting another purge.
6. Verify that only the reviewed contents were removed and the target location/history remain. Use Delete separately if the empty location must also be removed.

Protected locations and non-Active Folders impose restrictions. Do not edit stored records to bypass a blocker or assume an undo operation exists. A filtered empty list does not prove absence of dependencies.

Related chapters and boundaries

Continue with Mappings, Sessions and Workflows. Repository structure differs from the worker-accessible file paths configured for execution. The example gives an acceptance procedure to perform in your laboratory; it does not claim that your tenant's permissions have been tested.

Purpose and model

A Mapping describes how records are read, transformed and delivered through connected source, transformation and target components. A Session supplies a reusable execution context; a Workflow coordinates Sessions. For a supported file-only trial, Run can execute the Mapping directly with a browser-selected file; a separate Session and Workflow are not mandatory.

Distinguish editing a draft, Save draft, Publish and Run. Saving preserves design changes. Publishing creates a version for authorized consumers. Running processes data. Existing consumers can retain an earlier published reference.

Prerequisites and editor controls

Confirm the tenant, role and laboratory Domain/Folder. Viewing, editing, publishing and running have distinct permissions. A compatible eligible execution worker is required; remote components also require configured Connections and runtime network access. Follow the editor's naming validation and use a technical name such as m_CustomerDemo.

Components searches the catalog; Configuration edits the selected component. Domain, Folder and Shared within tenant define location and permitted sharing. Validate checks the design; Auto arrange mapping, Zoom and Fit only adjust presentation.

Arrange lays out dependencies from left to right. It requires at least two components and an acyclic graph; a wide graph can remain horizontally scrollable. It changes draft positions, not records or the published version. If nothing moves, check for an existing arrangement, cycles or a read-only Mapping.

Example: prepare a customer CSV

Download the public customers-demo.csvCSV · 2.2 kBOpen file: 18 synthetic records and eight columns. The preserved demonstration produced ten output records and six columns · clientes-demo-excel.csvCSV · 773 BOpen file. This is CSV readable by Excel, not a native XLSX workbook.

1. Choose Mappings → New Mapping. Enter the name and authorized laboratory location.
2. Add Flat File input from Components. In Configuration, select CSV, comma delimiter, header row 1 and UTF-8. Check all eight input column names.
3. Add the transformations below and connect compatible ports in the listed order. Select each node to configure its fields.
4. Add Flat File output. Use CSV, clientes-demo-excel.csv, comma delimiter, included header, double-quote qualifier, minimal quoting, CRLF endings and UTF-8 with BOM.
5. Choose Validate, fix each reported problem, then Save draft. Choose Publish, confirm Publish mapping, and check the published version.
6. Choose Run and select the synthetic CSV in the file picker. This supported single-file execution does not require a separate Session or Workflow.
7. In Monitor, identify the attempt and wait for its terminal state. After success, use Download output when stored output is available.

Verify the result

Compare row count, exact header, unique identifiers, values and physical ordering with the reference. Expect ten records, six columns and ascending cliente_id. DEMO-C002 becomes CLIENTE DEMO BETA, ACTIVO and numeric 2500. The inactive record containing NO_NUMERICO is filtered before conversion. Zero is allowed in this example; a positive-amount filter would change the contract.

Compare numbers by value: 2500.0 need not be serialized as 2500.00. The preserved demonstration establishes these sample results, not a performance guarantee. The separate customer-normalization laboratory documents its historical eight-transform chain and 1,000-input / 667-expected-output contract.

Projection and assistance

Field selector preserves rows and selected field values while removing other columns from the output schema as well. fileName names the artifact; it does not select columns. For unexpected extra fields, inspect saved configuration, connected branch, downstream components and the version actually executed.

You can ask DovaAI for a configured design, inspect the proposal and confirm a draft. Creating the draft does not publish, schedule or execute it. Current Mapping names use 2–79 characters, beginning with a letter and containing only letters, digits or underscores.

Validation, failures and recovery

A connected port does not prove that a required column exists. Inspect source schema, upstream renamed fields, nulls and connector compatibility. A conversion failure can indicate incorrect filter order. For file-backed Sessions, inspect bindings and worker access; a browser-local path is not a worker path. Keep credentials in Connections rather than canvas text.

After changing a Mapping consumed by Sessions, review their version notices and update dependencies deliberately. Publishing the Mapping does not republish every consumer. Preserve an earlier output for comparison; a succeeded state alone does not establish business correctness.

Related reference

See transformation reference for the broader catalog, including Unpivot, Run sequence, Field fingerprint and Partition rank. Compatibility depends on the selected engine and worker. Use Monitor for evidence and Open items to navigate without confusing drafts with published definitions.

Purpose and model

A Session binds a published Mapping to an executable context: environment, worker selection, execution profile, recovery, parameters and file paths. The Mapping owns transformation logic, formats and schema. The Session resolves the worker-accessible locations used for a reusable run.

References are versioned: the Mapping reference includes its identifier, version and fingerprint. Publishing a new Mapping does not automatically update every Session. A supported direct file-only Mapping Run is a separate path and does not require creating a Session.

Prerequisites and lifecycle

You need access to the location and Mapping plus permissions for each intended action. New session, Save draft, Publish session, disabling and deleting are distinct operations. File paths require a published Mapping. An entry in a worker selector does not prove execution eligibility.

The manager provides search, environment/status/runtime filters, Columns, Export CSV and pagination. Summary cards filter the inventory without changing Session status. Before a bulk action, check the selected count and names.

Fields by tab

Environment offers Development, Test, Stage and Production. This classifies context; selecting Production neither publishes the object nor grants permission. Use tenant default inherits worker policy. Override worker chooses an explicit eligible worker when authorized. An execution profile can inherit from the Workflow. Cloud provider and region shown for a worker are read-only context.

Review the offered Recovery policy and timeout/retry settings. Retrying and resuming from a checkpoint are different actions. A checkpoint helps only when compatible persisted state exists, and does not provide an automatic rollback of external writes.

The current Recovery choices are Fail immediately, Retry once, Retry up to 3 times and Resume from checkpoint. Select the intended behavior explicitly and verify it with the destination's retry contract.

Configure and publish a laboratory Session

1. Choose New session and enter s_CustomerDemo_Test.
2. In General, select the accepted published Mapping and authorized Domain/Folder. Check its identifier and version notice.
3. Select Test as Environment.
4. In Runtime, retain Use tenant default or enable a compatible Override worker. Review execution profile and recovery deliberately.
5. In File paths, fill every required source and target binding. A path on your browser's computer is not automatically present on the worker.
6. In Parameters, supply only declared, type-compatible overrides. Inspect Parameter preview for name, type and effective value.
7. Use Save draft, resolve validation and choose Publish session when ready. Reopen the record to confirm the persisted reference, bindings and version.

Binding and parameter example

Illustrative worker paths are /srv/dova-lab/input/customers.csv and /srv/dova-lab/output/customers-test.csv. Replace them with authorized locations prepared for the worker identity; the documentation does not create those directories.

If the Mapping declares a string parameter named region, an example typed override is:

{"region":{"type":"string","value":"DEMO"}}

This value affects data only when a component uses it, for example a Calculated field template ${param.region}. An arbitrary parameter does not create a column or alter engine batch size. Task-scoped overrides belong to a Workflow task, not Session layers.

Example: one design, two contexts

Create Test and Stage Sessions using the same published Mapping version and equivalent synthetic files accessible to the same worker. Assign separate output destinations. Execute each through a laboratory Workflow and compare results: equivalent inputs and parameters should yield equivalent transformed records in independent files.

As a controlled failure, temporarily use a nonexistent laboratory source path only in Test. Locate that attempt in Monitor, identify the file error, restore the path and inspect a new attempt. The environment label does not move files or deploy code automatically.

Versions, failures and recovery

For an ineligible worker, inspect status, capabilities, profile and exclusion rules in Configuration. For invalid JSON, correct the indicated field without discarding unrelated draft settings. After changing a Mapping reference, review downstream Workflows and publish consumers deliberately.

Destination timestamp behavior can be inherited, enabled or disabled. An optional template resolves %RUN_TIMESTAMP% while retaining the destination directory. Verify the resulting filename with a small run. Before any retry, check whether a previous external write can be duplicated or whether the selected recovery state is usable.

Continue

See Configuration, Workers, Workflows and Monitor. The examples define acceptance checks to carry out in your environment; they do not claim a new execution has already occurred.

Purpose and model

A Workflow coordinates tasks, dependencies and decisions. A Session binds a Mapping to execution context; the Workflow determines how those Sessions are combined. The canvas shows Start, Session, Decision, Timer and End tasks and their connections.

Published dependencies are versioned. A Session task refers to its Session and sessionVersion, which in turn references a Mapping version. Changing an upstream draft does not silently change an already published execution definition.

Prerequisites

Prepare an accepted published Session, compatible eligible capacity, an authorized laboratory location and an exclusive output. Viewing, editing, publishing, running and administering schedules require their respective permissions. Follow executable-name validation and avoid production object names for experiments.

Create and test a minimal Workflow

1. Open Workflows, create a laboratory Workflow and set its name, Domain, Folder and authorized sharing scope.
2. Add a Session task between Start and End. In its inspector, choose the published definition in Reusable session and check the referenced version.
3. Connect Start → Session → End by dragging from each output port to the next input port. Adding a task does not connect it automatically.
4. Review declared task overrides and dependencies. With multiple inputs, joinPolicy=any or all controls dependency joining; canvas position does not.
5. Use Auto arrange workflow and Fit workflow to inspect the graph. These controls adjust presentation, not data.
6. Choose Validate, resolve problems, Save draft and Publish. Publishing establishes an accepted version without executing it.
7. Choose Run. If input configuration is requested, inspect the offered mode for every source and supply the authorized laboratory input. A file attached in DovaAI chat is not an execution input.
8. Find the returned attempt in Monitor and compare its tasks and output with your expected result.

Timers and complementary decisions

For a controlled delay, insert Timer before Session and set Delay (seconds) to 5. The field accepts 1–604800 seconds. Timer delays this attempt; it does not create a recurring schedule.

For Decision, configure True branch expression (JSON). Declare the Workflow variable runMode as string, with default full and allowed values full and sample. This expression tests it:

{"ref":"variables.runMode","op":"eq","value":"full"}

Connect the True and False output ports to explicit destinations. False represents the complementary alternative; duplicating the True condition is not a meaningful two-path test. Use the documented JSON expression language rather than SQL or arbitrary script.

Verify tasks and data

The minimal example reads synthetic name,amount records and writes the same intended fields. Expect one Session execution on the selected path and independently verified output. Record the attempt ID, Session/Mapping versions and supplied overrides. An override for one attempt is not a persistent edit of the Session.

For Decision, test each input value with separate outputs and confirm the intended branch. A skipped branch is different from a failed task. The separate customer laboratory describes a historical 1,000-input / 667-expected-output example and downloadable study definitions; a private source checkout is not required to follow this page.

Schedule after manual acceptance

Configuration → Workflow Scheduler manages reusable schedules. Create an authorized schedule, review calendar, timezone and enabled state, then assign it to the intended published Workflow. The scheduler timezone differs from Profile's date-display preference.

First verify a manual execution. Then check the next planned time and, separately, the actual resulting attempt. An enabled schedule records future intent, not a successful run. Disable temporary laboratory schedules when finished.

Validation and recovery

The validator accepts 2–100 nodes and 1–300 links, rejects cycles, repeated identifiers and invalid dependencies, and requires reachable valid paths. For waiting tasks, inspect parents, worker eligibility, slots and exclusions. For failures, investigate the first relevant task error in Monitor.

When a Session or Mapping changes, inspect dependency notices before deliberately republishing consumers. Checkpoint recovery depends on compatible persisted state; it is not a transaction covering every external destination. Check duplication risk before retrying or using stored input for another attempt.

Continue

Use Sessions for bindings and recovery, Workers for capacity, Monitor for evidence and the expression reference for supported conditions.

Purpose and model

Monitor follows execution attempts and their outcomes. Its main unit is a run, not a saved Workflow definition. Two attempts of the same Workflow may use different inputs, parameters and published dependencies; compare their identifiers and recorded execution context.

A succeeded state is the engine's reported outcome. Functional acceptance also requires row count, schema, expected values and the correct file or table. A notification-delivery failure is not automatically a transformation failure.

Access and views

You need permission to inspect the active tenant's runs. Run, cancel, terminate, recover and history maintenance can require additional authorization. Check the specific action instead of expanding a reader's role to solve a display issue.

List, Gantt and Notifications separate operational records, temporal dependencies and notification deliveries. List and Gantt share upper filters. History can express a window in minutes, hours or days: check its unit before interpreting an empty result.

Notifications has its own delivery table and pagination; a delivery record is not another Workflow run. Wide tables can scroll horizontally inside their container on a small screen.

Investigate an attempt

1. Filter by object name, state and approximate time. Confirm attempt ID and timestamp.
2. Open its detail or Operational log when available.
3. Inspect task dependencies and locate the first relevant failed task. Relate it to the actual Mapping, Session and worker.
4. Review inputs and parameter context recorded for the attempt. Do not infer them solely from today's open draft.
5. For waiting work, inspect eligible workers, available slots and dependencies before requesting another copy.
6. Inspect the destination before deciding to cancel, terminate, recover or repeat. Refresh state and read the action's confirmation.
7. Retain the ID, time, task and sanitized message for support; exclude secrets and customer records.

Download and uncertain state

A successful Mapping attempt with stored output can offer Download output when access allows. Download the artifact for that exact attempt. An external database/API write does not necessarily create a downloadable file. Compare the actual returned file rather than an older local file with the same name.

A client timeout does not prove cancellation. Query the same attempt before retrying. If its state changes while a confirmation dialog is open, refresh the evidence before acting. History's visible time window is a filter, not a retention policy.

Example: controlled failure and corrected attempt

Use a small synthetic Workflow with an exclusive laboratory output. First supply a nonexistent source path in its test Session. Expect a terminal failure with an identifiable missing-file error and no valid output for that attempt.

Restore the correct binding, perform a new authorized attempt and compare identifiers. Expect a terminal success and output matching the known header, rows, values and ordering. Keep outputs distinct so a residual file cannot masquerade as the corrected result.

For checkpoint recovery, first confirm usable compatible persisted state and destination behavior. An external partial write is not undone merely by choosing recovery. A repeated append can duplicate records.

Operational diagnosis and maintenance

A pending attempt may be waiting for capacity, an eligible worker or upstream dependencies. Check Configuration and Workers; distinguish agent Offline, a powered-off VM and provider Unavailable. Avoid issuing duplicate runs because a table refresh is slow.

History cleanup is separate maintenance with its own scope and confirmation. It does not cancel active work or replace a retention policy. Inspect blockers, preserve necessary incident evidence and do not use deletion to hide an unresolved failure.

Continue

Overview summarizes activity; Monitor provides attempt-level evidence. Persistent corrections belong in Mappings, Sessions or Workflows and follow their publication lifecycle. Use Cloudata support for unresolved issues with sanitized evidence.

Purpose and model

Connections centralizes reusable connection definitions and their status. A definition combines a system type, connection parameters and a compatible authentication method. A catalog entry does not establish network reachability, licensing or dependencies on the selected execution worker.

Stored credentials and the connection definition are related but separate. A configured-credential indicator neither reveals the secret nor proves that it remains valid in the external system.

Prerequisites

You need permission to view Connections and the appropriate management permission for creating, editing, testing or retiring credentials. Prepare an authorized laboratory system, a least-privilege account and connectivity from the worker that will execute the Mapping.

The authentication catalog includes methods such as username/password, certificates, managed identities, OAuth client credentials and API keys. Availability depends on the selected connector; these are not interchangeable choices supported by every connector.

Authentication and credential custody follow the offered connector options. Passwordless uses an execution identity; external custody requires a protected reference resolvable from the authorized context. Inspect consumers before rotating, revoking or deleting a connection. Editing metadata differs from replacing credentials.

Configure and verify a connection

1. Open Connections. Search and check filters before creating a duplicate.
2. Start a new connection and select the connector for the actual data system.
3. Enter its name and repository location. Complete the host, database, endpoint or other fields required by that connector.
4. Select a supported authentication method and enter secrets only in the designated credential fields.
5. Save and resolve any field validation errors. Read the result rather than assuming that closing the form means success.
6. Use the available connection test and inspect its complete result.
7. If the connector exposes metadata, inspect the objects accessible to the account. Confirm the intended schema and columns.
8. Bind the connection to a laboratory Mapping and perform a small authorized read or write to an exclusive test destination.

Example: a bounded extraction

Prepare a synthetic table with three records and a read-only source account. Configure the laboratory connection, run its test and inspect metadata. Build a Mapping that reads only that table and writes a test file using a Session and compatible worker.

The expected output contains three rows with the same synthetic values except for explicitly configured transformations. Write access to the source database is outside this example and should not be granted merely to make the test pass.

To study a failure, use a separate temporary definition with an incorrect laboratory endpoint. Record the error category, then restore the endpoint. Do not break a shared connection or rotate its credentials to induce an error.

Diagnosis and recovery

Separate network, authentication, authorization and schema errors. A valid account can lack access to one table. A hostname reachable from your browser's computer can still be unreachable from the selected worker. Check drivers and connector capabilities in that execution environment.

After rotating credentials, repeat the smallest relevant test and execution. A previous test result does not prove access with the replacement secret. In a support request, provide the connection identifier, connector family and a sanitized error; exclude passwords, tokens, private certificates and internal secret references.

Related chapters and boundaries

See Mappings for format and logic, Sessions for execution context and Workers for runtime connectivity. Connector-specific fields and limitations belong to the connector reference; do not assume identical behavior across families.

Notification channels define reusable delivery destinations for authorized events. A channel is different from the notification policy, the execution email template and the platform SMTP transport. Configuring a destination alone does not establish when an event is generated or whether a recipient received it.

Choose a controlled laboratory destination and a role allowed to manage the channel. An endpoint or recipient can be sensitive even when it is not a password. Keep real customer addresses and webhook URLs out of documentation and screenshots.

Step-by-step procedure

1. Choose the destination purpose. Open Notification channels and inspect existing entries. Decide which event or team needs the channel and whether an existing authorized destination should be reused rather than copied.

2. Create the channel. Use the available creation action and enter a recognizable laboratory label. Choose the offered channel type and complete its required endpoint or recipient settings. Follow the type-specific validation shown by the form.

3. Review scope and sensitive input. Confirm the active tenant and which authorized audience the channel serves. Use the protected credential flow when the type requires it. Never replace a protected field with a secret embedded in a URL or description.

4. Save before testing. Save the channel and inspect the accepted result. Reopen the persisted record when needed. A test should validate the stored configuration rather than an unsaved draft that was never accepted.

5. Send a controlled test. Use the Test action where available and send only synthetic content to the laboratory destination. Read the reported result and inspect the receiving sandbox system. A local success message may describe handoff rather than final delivery.

6. Associate the policy. Review the relevant execution or administrative notification settings. Configure which authorized events use the destination and how suppression, severity or recipient rules apply. Do not confuse this with editing the email body.

7. Check end-to-end delivery. Trigger a synthetic event and review the delivery history. Compare generated, sent, failed or suppressed state with the receiving system. Restore temporary policies when the exercise finishes.

Verify the result

Acceptance requires a persisted channel, an expected test response and an independently observed laboratory delivery or a clearly explained suppression. Preserve a safe identifier and timestamp for troubleshooting. For email, verify transport and template separately; for webhooks, respect the endpoint contract and retry behavior.

Errors and recovery

If a test fails, inspect safe validation and transport messages without exposing the endpoint credential. If an event is suppressed, inspect notification policy before changing the channel. If delivery is delayed, check its current state before sending duplicates. Removing a channel may affect consumers; inspect references and use the confirmation shown.

Continue

Repository · Mappings · Sessions · Workflows · Monitor · Configuration.

Channel type and field reference

A previously configured protected value may not be redisplayed when editing. An empty secret field does not necessarily mean no stored credential exists. Read the configured indicator and field guidance before replacing it. Search notification channels helps avoid duplicates; New notification channel opens the creation flow. Reload, Filters, Clear filters, Columns and Export CSV operate on the manager view, not on event generation.

Example: delivery and disabled state

Create LabOperations with a controlled mailbox, associate a small synthetic Workflow and select the intended event. Confirm the persisted channel, a safe execution identifier, the delivery result and the receiving mailbox. Inspect subject, text and links without exposing input records. Then disable Enable this channel and repeat only the necessary controlled exercise. A disabled channel remains administratively available but does not receive Workflow events; restore the intended final state.

Sent, failed, suppressed and acknowledged are different outcomes in Delivery history. Inspect whether the event was generated or suppressed before changing credentials. Global SMTP changes require the relevant platform authority, and a body preview is not a transport test. See Execution templates, SMTP and policy for the detailed administrator procedure.

Purpose and model

A worker supplies capacity for compatible execution. The inventory exposes identity, status, resources and capabilities. Agent connectivity, VM power state and eligibility for one particular Session are different observations.

Infrastructure provisioning and provider operations belong in Administrator. Workspace Workers helps you understand the capacity your tenant can use. A public worker may offer authorized shared capacity; assigning it a Session does not publish that Session's definition, data or artifacts to other users or tenants.

Prerequisites

You need viewing permission and specific privileges for registration or changes. Prepare an authorized host and follow its current distribution instructions. Keep enrollment tokens in the protected enrollment flow, not screenshots, tickets or repositories.

Compare the Mapping's requirements with the worker's component types, connector capabilities, resource and isolation requirements, profile and network access. A connector in the designer does not install a driver or open a network route on the worker. Selecting a worker does not copy browser-local input files onto its filesystem.

Read the inventory

Details can include host, platform, version, resources, last heartbeat, profiles and connectors. Use them to verify compatibility without copying unnecessary infrastructure details into public reports. The built-in control-plane worker is not execution-eligible for tenant Sessions or Workflows.

Weighted slots and concurrency

Slots represent weighted capacity. For example, four slots can admit four weight-one jobs or two weight-two jobs, subject to other limits and real reported capacity. Multi-job admission requires an explicit capability and compatible live reporting; increasing a configured limit does not make a legacy agent concurrent.

Evaluate capacity for a run

1. Open Workers. The Dova Worker Agent panel provides packages, Register worker, search, filters, columns and pagination.
2. Find the intended laboratory worker by identifier and permitted tenant/pool, then inspect its status and recent heartbeat.
3. Compare component types, connectors, version and profiles with the actual Mapping. Check available slots and resource requirements.
4. Confirm that the worker identity can resolve Connections and access the authorized input/output locations.
5. Review whether tenant default selection or a Session override is appropriate. An explicit selection still must satisfy eligibility and exclusions.
6. Run a small synthetic case and inspect the actual selected worker and outcome in Monitor.
7. Before replacement or retirement, inspect active work, references and default policies; use the supported Administrator procedure.

Example: eligibility before capacity

Prepare a published file Mapping, laboratory Session and authorized worker. Make three synthetic records accessible to that worker and use an exclusive output. Expect the intended worker to receive the attempt and produce the known output. Record worker and attempt identifiers together.

As a comparison, inspect a Session requiring a missing capability without forcing execution. Expect a compatibility restriction rather than permissive assignment. This validates selection, not maximum throughput or permanent availability.

Recovery and operational boundaries

For missing heartbeat, inspect the authorized worker service and its control-plane communication. For ineligibility, examine lifecycle, capabilities, resources, exclusions and profile. Avoid changing the entire tenant's default worker to fix one isolated failure without checking consumers.

Provider Unavailable does not prove that a VM is absent. Stopping a VM, removing its registration and deprovisioning provider resources are separate operations with ownership, reference and active-run checks. Deleting inventory records does not replace those procedures.

Related chapters

Configuration controls routing, profiles and exclusions; Sessions can inherit or override worker selection. Use Monitor for execution evidence and the Administrator worker guides for installation or retirement.

Purpose and structure

Configuration groups five areas: Dova Integration Runtime, Execution profiles, Workflow Scheduler, Runtime health and Git / DevOps. Runtime policy selects authorized capacity; a profile sets execution conditions; a scheduler requests future work; health reports current observations.

Saving a policy does not establish that a compatible worker is available or that a job has completed. On narrow screens, use the content area's horizontal scrolling for wide tables rather than assuming off-screen columns are unavailable.

Prerequisites and scope

Confirm tenant and permissions. Viewing settings, registering workers, saving policy, managing profiles and editing schedules can require separate privileges. Record the current settings before a laboratory change and inspect Sessions that inherit tenant-wide values.

Review and configure the correct area

1. Open Configuration and identify the area relevant to the issue before editing.
2. In Dova Integration Runtime, review identity, status, mode, default worker and capabilities. Runtime inventory offers search, refresh and column selection.
3. In Tenant routing policy, inspect Default worker, Fallback and Save policy. Selection still applies eligibility, compatibility and exclusions; do not assume automatic reassignment to any available worker.
4. Use the Workers and Exclusion rules subtabs to inspect capacity and restrictions. An exclusion changes routing; it does not delete a worker.
5. In Execution profiles, find an existing suitable profile before creating another. Review units, limits, inheritance and consumers. An execution profile is different from an Administrator cloud-provisioning profile.
6. In Workflow Scheduler, prepare a reusable schedule with an explicit name, frequency, timezone and enabled state. Assign it to the intended Workflow only after a successful manual acceptance test.
7. Save only the intended change, wait for acceptance, then reopen to verify persistence. Save may remain disabled if nothing changed.
8. Read Runtime health separately and continue in Workers or Monitor for worker and attempt evidence.

Example: inherited policy and explicit override

Create two laboratory Sessions using the same published Mapping. Keep Use tenant default in the first; enable Override worker in the second only if another eligible worker is available. Leave transformations, inputs and parameters equivalent.

Record the tenant default and inspect the effective worker in each Session. Expect the first to resolve through tenant policy and the second to retain its explicit choice, subject to eligibility. Execute a small synthetic input when authorized and compare actual selected workers in Monitor.

Only in a dedicated laboratory tenant, change the default with Save policy, recheck both Sessions and restore the original value. Do not perform this experiment on shared active workloads.

Schedule and health checks

For a schedule, record timezone, next planned time and the resulting attempt ID as separate facts. Profile's display timezone is not the schedule's timezone. Disable temporary laboratory schedules afterward; closing Configuration does not disable them.

Runtime health describes the environment, not independent data correctness. Correlate health with worker heartbeat/capacity and the actual output of an identified attempt.

Errors and recovery

Without an eligible worker, examine capabilities, lifecycle, resources, exclusions and profile before increasing limits. For schedule discrepancies, compare timezone, enabled state and Monitor. Avoid changing policy, profile and schedule simultaneously, which obscures the cause.

After a save error or concurrent change, reload safely and compare the persisted state before resubmitting. A selected dropdown value is not evidence that server policy changed. Do not repeatedly request execution because a health summary has not refreshed.

Git / DevOps: versioning and promotion

The fifth tab, Git / DevOps, presents the Bitbucket Cloud integration. Git → Dova plans and deploys reviewed artifacts in dependency order. Dova → Git exports published versions and pinned dependencies for review without exporting credentials.

1. Open Git / DevOps with the relevant permission and read its state. Configuration required means setup is needed; a visible tab does not establish a connected repository.
2. Download the offered integration kit and inspect its instructions and example configuration before adding it to the authorized Bitbucket repository.
3. Set target workspace and artifact bindings. Store the Dova API key as a secured pipeline variable, outside JSON files and commits.
4. Run the kit's dry plan first. Review artifacts, dependencies, versions and conflicts before enabling deployment or scheduled export.
5. After an authorized promotion, inspect the published Dova versions and references. A successful export or commit does not replace execution acceptance.

For a laboratory exercise, prepare a published Mapping and its Session/Workflow, inspect a plan and preserve the expected scope before applying it. Stop at plan review if you are only learning. The current kit defines exact commands and configuration; this page does not invent a deployment command or claim your tenant's integration is enabled.

Continue

See Workers, Sessions, Workflows and Monitor. These laboratory checks establish an acceptance method, not a capacity or availability guarantee.

Plans and subscriptions presents the effective commercial choices for the active tenant. Availability depends on tenant type, lifecycle, plan and authorized offers. A displayed price, a checkout order and an active subscription are different stages; one does not automatically prove the next.

Review the tenant identity before entering checkout. A public trial is designed to continue as the same operational tenant after an accepted conversion, preserving object identity. Do not recreate the tenant or move objects to simulate that continuation.

Step-by-step procedure

1. Confirm the workspace. Open the account menu and record the active tenant. Open Plans and subscriptions and inspect the plan and lifecycle information available to your role. Do not use another tenant offer as the baseline for this workspace.

2. Review the effective offer. Read the offered plan version, price, currency, period, quantity and terms shown. Tenant-specific offers reference the global versioned catalog; they do not imply an independently duplicated product catalog.

3. Inspect checkout fields. If authorized to evaluate a purchase, review customer type, document type/number, legal name, email, country, address and payment method. Check totals and currency before advancing.

4. Use a controlled sandbox exercise. For learning, use supported fixtures or a separately authorized payment sandbox. Opening checkout is not permission to send a real payment confirmation. Synthetic tokens must never be submitted to a live provider.

5. Track the order outcome. After an actual authorized purchase, inspect the definitive order/subscription result through the supported flow. A delayed UI update is not evidence that no provider operation occurred. Resolve the existing order before repeating checkout.

6. Verify continuity. Confirm the active tenant identifier remains the intended one and existing Repository objects retain their identifiers. Inspect the accepted subscription and permitted capabilities independently of the payment UI message.

7. Review later changes. Before renewal or a new offer, inspect its validity and applicable contractual version. Historical orders retain their terms; a newly published price does not rewrite an earlier order.

Verify the result

A successful conversion is supported by an accepted commercial result, the operational tenant remaining the same and capabilities matching the applicable subscription. This manual provides a sandbox procedure; it does not certify a payment or provide a revenue forecast. Billing administrators investigate invoices, subscriptions and orders in their proper context.

Errors and recovery

If the offer is unavailable, check lifecycle, eligibility, plan and role. If amounts disagree, confirm currency, quantity and terms before submitting. For a pending order, investigate its current state rather than creating another. Do not mark an invoice paid or alter historical terms merely to make access appear correct.

Continue

Repository · Mappings · Sessions · Workflows · Monitor · Configuration.

DPU, DPU-h and purchased terms

For a DPU-enabled plan revision, DPU measures active processing capacity and DPU-h combines capacity with time. The example 4 DPU × 15/60 h = 1 DPU-h expresses consumption, not a currency price. Development and Production have separate allowances and concurrency. Credits follow verified funded periods, which need not be calendar months. Queued work and structural validation are not billable active processing time; a Workflow aggregates its tasks without charging the same work twice.

A legacy subscription retains its purchased terms until an accepted, activated conversion. Opening a calculator or publishing another offer does not change the active contract. Contracted concurrency does not create workers or override capacity requirements. Accepted DovaAI queries have tenant and user quotas separate from DPU; an administrative title does not imply unlimited access.

Subscription and DPU administration · Versioned catalog and offers.

Checkout fields and order states

For a form-only exercise in the authorized Training sandbox, review the offer and cancel before payment. Verify that merely reviewing the form did not create an unintended subscription. If testing a complete sandbox order, record its safe identifier and provider test result separately from the subscription and tenant continuity checks. A sandbox result does not establish production acceptance.

Developer Tools provides platform-specific CLI distributions, checksum and signature information, quick-start instructions, release notes and personal API key management. A package name or version label alone does not establish integrity; compare the downloaded SHA-256 with the published value.

Use an authorized laboratory environment and a personal key scoped to the required work. Keep keys out of shared commands, screenshots, repository files and incident reports. API authorization remains tied to identity, tenant and permissions.

Step-by-step procedure

1. Choose the correct distribution. Open Developer Tools or the Downloads entry in the account menu. Select your operating system and inspect the published artifact version, signature status and installation instructions. The CLI version can differ from the application version.

2. Verify the download. Download the selected artifact to an authorized local location. Calculate SHA-256 with the platform tool and compare it exactly with the published checksum before installing. Investigate a mismatch rather than bypassing verification.

3. Install and inspect help. Follow the package instructions. Run dova --version and the relevant command help. Confirm the executable you are using is the intended installation, especially if another version is already on PATH.

4. Create a purposeful API key. Use API Keys to create a personal laboratory key where permitted. Record its purpose and any validity information actually exposed by the supported flow. Do not assume an expiry or scope editor exists. Handle the displayed value through the protected workflow; it is not documentation evidence.

5. Log into the laboratory. Run dova login --url with the authorized service URL. Enter the key through the interactive prompt rather than adding it to a shared argument. Check the identity and tenant returned by login.

6. Start with read-only commands. Use status, repository list and filtered mapping/workflow/run lists. Compare their result with the corresponding UI module. A valid empty list is different from a failed authentication response.

7. Close and revoke separately. Use dova logout to remove local authentication state when appropriate. Revoke a temporary key in the server UI when it must stop working on every device. Logout and revocation have different scope.

Verify the result

Read-only laboratory examples:

dova --version
dova login --url https://dova-lab.example.invalid
dova status --output json
dova repository list --domain Training --output json
dova mapping list --name sample --limit 50 --output json

The .invalid URL is an intentional placeholder. Replace it with your authorized laboratory host. Confirm the returned identity and compare identifiers with the UI before automating writes.

Errors and recovery

For checksum mismatch, stop using the artifact and verify the distribution. For 401/403, review expiry, active key and permission; do not reinterpret the error as an empty list. A command timeout may leave server work running. Inspect the existing run before retrying. Protect the CLI profile because it can retain authentication state.

Continue

Repository · Mappings · Sessions · Workflows · Monitor · Configuration.

Distribution metadata and integrity example

For example, PowerShell can calculate the downloaded file’s checksum. The filename is illustrative; substitute the actual artifact you obtained:

Get-FileHash -Algorithm SHA256 -LiteralPath .\downloaded-dova-cli.zip

A successful download, a matching checksum, a signature and an authorized read are separate results. Keep each result distinct in the laboratory record. Downloading the CLI does not create tenant membership, grant a role or bypass commercial lifecycle restrictions. If command options differ from this guide, inspect the current package help instead of guessing flags.

CLI read filters

These forms describe published read commands. Check the installed version’s help before adding options. Do not confuse workflow list with workflow run: the latter executes work and needs a separately authorized laboratory exercise.

Filtered Workflow and run reads

After confirming the laboratory identity and tenant, these additional read examples inspect published Workflows and failed or cancelled Workflow runs:

dova workflow list --status published --name customer --limit 50
dova run list --status failed,cancelled --sort createdAt --descending --output csv

Replace synthetic names with the permitted laboratory filters and compare identifiers with the UI. An empty filtered result is valid when no records match.

Purpose and model

The account menu shows the authenticated identity and working context. In Dova, it lets you review tenant and role, switch to an authorized workspace, adjust appearance and open personal functions. Check it first before editing or running anything when a person belongs to more than one workspace.

The active role determines available actions. Switching it does not grant new privileges: it selects an already authorized role. Likewise, the workspace list is not an open tenant catalog.

Menu structure

The interface may abbreviate long names. Before a sensitive operation, confirm identity and tenant through the available fields rather than avatar initials alone.

Dova and Administrator share the menu design, but not every action is identical. Administrator offers Back to workspace, whereas Dova provides Profile. These differences follow the navigation context.

Before switching tenant or role, or signing out, review Open items and resolve pending changes with Save or deliberate discard. Wait for save confirmation. An open tab or an editor memory optimization does not replace object persistence.

Safe context-switching procedure

1. Open the account control in the header.
2. Review the current workspace and role.
3. If another workspace is needed, select an authorized membership.
4. Wait for the switch to complete and confirm tenant and role again.
5. Open the required module and check that its objects belong to the expected context.
6. If an action disappears, review permissions and membership before assuming an interface failure.

To change appearance, select Mode and Palette. Native controls retain keyboard navigation. In height-limited menus, scroll inside the menu to reach lower actions, including Sign out.

Proof of concept: compare roles without changing data

Use a laboratory account with two previously authorized roles: one for reading and one for editing. Open Mappings, note the available actions and switch to the read role through the menu.

Expected result: permitted navigation remains available while actions requiring editing are restricted. Do not try manual requests to bypass the restriction. Return to the edit role and confirm the context before continuing.

Then switch between Light and Dark, navigate the menu by keyboard and close with Escape. Focus should return to the control that opened it. This checks access and operability; it does not expand account authorization.

Validation and recovery

If a context switch fails, preserve the message and check which context remains active. Clicking an option does not prove that the switch succeeded. If the expected workspace is missing, ask the administrator to review membership.

Sign out ends the session through the application flow. Closing a browser tab does not replace this action on shared devices. Password changes have additional effects described in Profile.

Relationships and boundaries

Personal preferences belong to Profile; distributions and keys are in Developer Tools; open objects are managed through Open items. This proof of concept is a validation procedure using synthetic identities, not a verification of real users' permissions.

Purpose and structure

Profile combines personal settings, account information and privacy actions. It is not the administrative user editor or a way to switch tenants freely or grant yourself roles.

Open Dova's account menu and select Profile. The dialog shows identity and context, with preference, security and data sections. On small screens, the body scrolls to keep controls and close accessible.

Personal preferences

Review name, email, tenant and role before making changes. Timezone uses a time zone, such as America/Lima, saved through Save preferences. Its visible help states that it is used to present dates and times in the account experience.

Do not confuse this preference with a Workflow schedule's time zone. Changing date presentation does not imply automatic process rescheduling. See Configuration for the scheduler.

Use Change photo to select PNG, JPEG or WebP. The flow accepts an input file up to 10 MB, center-crops it to a 256-pixel square and optimizes it before uploading. Remove photo removes the existing photo. Wait for the result message before closing; processing failure is not a successful save. Test with a laboratory image containing no sensitive information.

Security

The interface requires 12–128 characters for a new password. The server can apply additional checks. Do not use the same password in documentation and a real account.

The dialog warns that changing the password ends all browser sessions and trusted devices. Prepare your access method and authentication factors before changing it. Do not use this as a routine test on a shared operations account.

Data and privacy

Download profile export requests a profile export. Treat the file as personal information and save it only in an authorized location.

Request profile data deletion and Request account deletion are separate requests. The flow asks for confirmation by typing the email and submitting with Submit request. Its notice explains that requests are reviewed before affecting shared tenant ownership or retained audit records.

Confirmation of a request therefore does not prove immediate deletion. Do not promise automatic removal of all workspace-related data.

Reversible preference proof of concept

In a laboratory account, note the current time zone. Change Timezone to America/Lima, save and reopen Profile. Expected result: the persisted value matches the selection and relevant dates display according to the supported preference.

Restore the previous time zone afterward. To check validation in the laboratory, enter a clearly invalid time zone and observe the message without repeated requests.

You can open a deletion request to inspect its confirmation and cancel with Cancel, without submitting. Do not use Submit request as a rehearsal unless you intend to initiate the process.

Errors, recovery and relationships

If saving fails, preserve the message and check the persisted value before repeating. If the session ends after a password change, authenticate again through the authorized flow; this does not indicate lost objects.

Relationships and scope

See Account for context and appearance and Developer Tools for personal keys. This proposed proof of concept was not executed during writing and is not an actual password-change or deletion request.

Purpose and model

Open items switches between Mapping, Session and Workflow editors. Each tab identifies an object's type, name and edit state. The bar organizes browser work; it is neither a new object version nor a copy of the data.

An open object can have pending changes. Keeping it visible in a tab does not guarantee that those changes are saved or published. This distinction matters when alternating between a Mapping, its Session and the consuming Workflow.

Access and controls

The bar appears in supported views when objects are open. At limited widths, More accesses items that do not fit in the row. Names may be abbreviated, while type identifiers distinguish similarly named objects.

Availability depends on type, object existence, permissions and state. Pinning a tab changes its treatment in closing operations; it does not protect the object against administrative changes.

When closing a modified editor, interpret Save, Discard and Cancel according to the confirmation shown. Cancel retains the context; discarding local changes does not delete the saved object. Memory optimizations and navigation between editors also do not replace Save.

Recommended procedure

1. Open a Mapping from its manager.
2. Open its consuming Session, then a related Workflow.
3. Switch between the three with Open items and confirm name and type before editing.
4. Deliberately save or discard pending changes.
5. Use the context menu only after checking which tabs it will affect.
6. On mobile, open More to locate items outside the row.

Before using Reload, check for local changes. Reload queries the server and can require resolving the draft; it does not merely refresh a header number.

Proof of concept: navigate with a pending draft

Prepare three linked synthetic objects: m_ClientesDemo, s_ClientesDemo_Test and a laboratory Workflow. Open their editors. Change a permitted Mapping field without publishing, then use the bar to switch to the Session.

Expected result: the application retains edit state according to the draft flow and identifies the active object. Return to the Mapping and check the edited field before deciding whether to save.

Next, try closing the object with changes. Observe the confirmation and cancel closing to verify that the editor remains available. Finally, explicitly discard or save the laboratory changes and close the tab.

Repeat at a mobile width with enough objects to show More. Check that you can locate and activate the object and reach its close action by keyboard or touch.

Errors and recovery

If Reload reports that the object no longer exists, do not immediately create another with the same name: check its manager for what happened and who can recover it. Investigate a tab-action error without assuming the definition changed successfully.

After saving and closing, reopen from Repository or the manager and check identifier, content and version. Successful reopening does not turn a draft into a published version. Before switching tenants or signing out, resolve each editor's pending changes.

Edit locks and permissions still apply while the object remains open. A role or context change can alter available actions; review the account menu.

Relationships and boundaries

Open items complements Mappings, Sessions and Workflows. It replaces neither publication nor verification in Monitor. This proof of concept checks drafts and navigation; closing a tab does not imply deleting the repository object.

Purpose and scope

DovaAI uses the authorized tenant, current module and view to explain Dova controls, components and configuration. It can guide you through the 36-component Mapping catalog and propose a reviewable design. Interface context does not grant access to other tenants, hidden data, credentials or operations outside your permissions.

Responses follow the message language: Spanish, English or Portuguese. You can explicitly request “in English” or “em português”. When a message does not clearly identify another language, the available language reference is retained. You do not need to select an assistance mode or language first.

Before you start

Confirm tenant and permissions. Schema attachment requires Mapping access; draft creation requires its corresponding authorization. Service configuration belongs to the authorized administrator and stays outside the conversation. Never paste keys, passwords, private certificates or customer information.

Usage allowances depend on the effective plan and contract. Starting another conversation does not reset consumption or grant more capacity. A configured service can still reject requests due to availability or limits.

Request and review a Mapping

1. Describe the goal, fields and expected result. For example: “Keep name and amount; change only the exact name value jorge to Jorge and prepare CSV output.”
2. If file context is needed, choose Attach data file and select a synthetic CSV, TSV, JSON, JSONL or XLSX sample. Inspect inferred names and types; inference does not replace your business schema.
3. Review components, connection directions, settings and missing fields. For exact replacement, Replace values should use field=name, find=jorge, replacement=Jorge, matchMode=exact and caseSensitive=true. This does not capitalize arbitrary names.
4. Confirm creation only when the proposal matches the goal and authorized location. A proposal is not an executed Mapping. If multiple drafts are offered, review each artifact and its required permissions.
5. Open the created draft and manually complete execution files, Connections, paths and parameters. Inspect missing settings; attaching a chat sample does not place a file on the worker.
6. Use the normal Validate, Save draft and Publish lifecycle. Then perform an authorized synthetic run and accept its output in Monitor. Assistance does not automatically publish, schedule or execute the proposal.

What an attachment provides

The service temporarily inspects the sample to derive its name, format, field names, inferred types and source settings. The AI context contains that structure, without sample rows or original file bytes. File, column and sheet names can also be sensitive: use laboratory data.

The schema is not saved as a run input. Supply the real execution file through Run or the appropriate bindings. A chat attachment does not establish connectivity, destination authorization or worker compatibility.

Verify the result

For the example, inspect Flat File input → Field selector → Replace values → Flat File output. Field selector retains only name and amount in records and output schema; Replace values changes the specified exact value. Check that other capitalization and different names remain unchanged, then compare the actual CSV after execution.

You can move, minimize or open chat in another window where supported. Context adapts when switching modules within the same authorized tenant. Identity, tenant or permission changes invalidate stale actions; continuity after sign-out or browser restart is not guaranteed.

Limits and recovery

Samples must be nonempty and at most 15 MiB; JSON and JSONL are limited to 1 MiB. The schema requires 1–32 unique field names. CSV/TSV requires a valid header and UTF-8 encoding. Attached structure expires after 15 minutes and can be lost when the service restarts; attach it again when expired.

An oversized schema or invalid context can be rejected. Correct the sample rather than increasing permissions. For exhausted allowance, inspect the plan. For an incomplete proposal, clarify the goal and fill missing fields in the editor. If creation outcome is uncertain, find the draft in Repository before repeating confirmation.

Continue with a controlled test

Use name,amount,internal_note with two synthetic rows whose names are jorge and Jorge. Expect only name and amount in output; both names become Jorge, amounts remain unchanged, and internal_note is absent. Continue with Mappings and Monitor. For unresolved issues, use the Cloudata support form without secrets or customer data.

What the graph represents

A Workflow controls execution order. A Mapping transforms records, while a Session supplies its execution context. Box positions make the canvas readable; links and their conditions establish the actual dependencies. Prepare a published Session and an eligible worker first. Creating and publishing also require the appropriate permissions in your tenant and Repository location.

Dova 22.0.5 requires exactly one Start and at least one End. The graph must be acyclic: no route can return to an earlier task. Every node must be reachable from Start and lead to an End. Adding an unconnected box leaves an incomplete design.

Choose the appropriate task

A five-second Timer delays that route. It does not create a recurring schedule or guarantee an exact starting time for the following work.

Connect and validate

1. Open Workflows and create a laboratory design in an authorized location.
2. Add a Session task between Start and End. Choose the published Session in its inspector.
3. Drag from an output port to the next task’s input port. The ordinary link is Success. Adding a task does not connect it automatically.
4. If a decision is needed, add Decision and set True branch expression (JSON). Connect both branches to valid destinations.
5. Use Validate and resolve the issues before Save draft and Publish. Validation accepts 2–100 nodes and 1–300 links.

A testable decision example

Declare a Workflow variable named runMode, with type string, default value full and allowed values full and sample. This is its configuration fragment, not a complete import document:

{"name":"runMode","type":"string","default":"full","enum":["full","sample"]}

Enter the following condition in True branch expression (JSON):

{"ref":"variables.runMode","op":"eq","value":"full"}

With full, the condition selects True; with sample, it selects False. The editor constructs the negation for False. Do not supply JavaScript, SQL or a different condition that could activate both branches. This expression reads execution context; it does not count CSV records automatically.

Link conditions and convergence

The definition supports success, failure, always and expression links. Each condition uses the source task’s state or context. A Workflow link is not a column-to-column data connection. The editor displays True/False for decisions and Success for an ordinary connection.

For a task with several parents, joinPolicy distinguishes any from all; the default is any. Decide which links must be satisfied before choosing the policy. Do not require both mutually exclusive branches of a decision as if both would run.

Check the run and diagnose issues

Run a minimal route first and find its attempt in Monitor. Check executed tasks, skipped branches and the Session version. A task skipped because of a condition is different from a failed task. If progress stops, inspect parents, conditions, published dependencies and worker capacity. A cycle, duplicate link or missing endpoint is a design problem; moving boxes does not fix it.

Continue with publication and dependencies or the complete CSV laboratory.

Three objects with separate responsibilities

A Mapping describes the data flow. A Session references a Mapping version and supplies bindings, parameters and execution profile. A Workflow selects Sessions and arranges their tasks. The published chain must be consistent: a published Workflow cannot repair an incomplete Session or grant access to a Connection.

Use a laboratory location and check editing, publishing and execution permissions separately. Prepare synthetic inputs, authorized Connections and worker capacity before accepting the chain.

Save, publish and run

Saving a CSV in your browser does not place it on a worker’s filesystem. Likewise, a draft prepared by DovaAI is neither published nor executed by that creation step.

Publish a controlled chain

1. Open the Mapping and inspect its source, transformations, target and schema. Validate and save the draft.
2. Publish the Mapping and record the version selected for the laboratory.
3. Open the Session and check its Mapping reference, version and input/output bindings. Validate and publish the Session.
4. Open the Workflow. For each Session task, inspect Reusable session and the consumed version. Review dependency notices.
5. Validate links and conditions, save the draft and publish the Workflow.
6. Run it manually with an independent laboratory output. Record the attempt and reconcile Monitor with the resulting file or target.

Example: change a rule without losing traceability

Suppose m_CustomersActive v1 keeps status=ACTIVE. Session v1 and Workflow v1 were accepted with three output records. You now modify the Mapping to discard amount=0 as well. The laboratory sample’s expected result for this new rule is two records.

Publish the new Mapping version deliberately, inspect the reference retained by the Session and update consumers through the available actions. Repeat that review for the Workflow, then test again. Preserve both outputs so the difference can be explained. Do not infer the executed version from whichever draft remains open in another tab.

Minimum acceptance evidence

• The name and version of each object in the chain, plus the execution attempt ID.
• Effective test parameters and bindings, without copying secrets.
• Task states and the first relevant error, when present.
• Output schema, record count and verified business rules.

Mapping references may include a version and fingerprint; an execution pins its authorized context. These identify what was consumed, but they do not make a mutable external file immutable. Preserve or identify the input data as well. A passing object validator is only one part of acceptance.

Update or return to a known reference

If a dependency is unavailable, check publication, tenant, location, permissions and version. If saving succeeds but Run fails, investigate the worker, paths, Connections and data. Repeated publishing is not a substitute for reading the actual error.

To compare with an accepted version, use the available version and reference mechanisms and a separate output location. Restoring a definition does not reverse previous writes to databases, APIs or storage. Complete the schedule review before enabling recurring execution.

Before creating a schedule

Schedule a Workflow only after it is published and manually tested. Confirm schedule-management and execution permissions, inputs available without browser interaction, authorized Connections and worker capacity. A file attached during a manual test does not become a permanent source for future scheduled attempts.

Open Configuration → Workflow Scheduler to prepare a reusable schedule and assign it from the Workflow. Inspect recurrence, start time, time zone and enabled state in the form. Keep it disabled while reviewing the settings.

Prepare a daily run

1. Publish and manually run the laboratory Workflow; confirm its output.
2. Create a recognizable schedule name, such as daily_customers_lima.
3. Choose daily recurrence at 02:15 and select America/Lima. If using cron representation, the equivalent is 15 2 * * *.
4. Inspect the calculated next run. The schedule’s zone is independent of the Profile time zone used to display dates.
5. Assign the schedule to the Workflow and review concurrency. Enable the schedule only after accepting its settings.
6. After the expected time, find the attempt in Monitor. Check tasks and output: a calculated next date does not prove successful execution.

Interpret local time and cron

Do not substitute an ambiguous abbreviation such as CST for the IANA zone. For zones with daylight-saving changes, review expected behavior around the transition. Recheck the calendar after changing its zone; changing only the language or Profile is not evidence that execution has been rescheduled.

Separate simultaneous runs from parallel tasks

concurrencyPolicy governs overlapping executions of the same Workflow: allow, forbid or replace; the default is forbid. Review it before scheduling potentially overlapping loads. Replacing an execution does not guarantee reversal of external operations that have already occurred.

maxParallelTasks limits parallel tasks within one execution: 1–64, with a default of 4. This does not reserve workers, slots, CPU or target capacity. Actual selection still depends on resources, authorization and availability. A simple sequence makes the first laboratory acceptance easier to interpret.

Check and maintain the schedule

• Check the published Workflow and versions, assigned schedule and enabled state.
• Inspect the next run’s time and zone, then compare an actual attempt afterward.
• Confirm which permanent input was read and where its output was written.
• When retiring a schedule, inspect existing attempts: disabling future launches does not cancel an active execution.

When the expected time produces no result

First check whether the schedule is enabled and assigned, the Workflow is available and concurrency policy prevented overlap. Then inspect the queue, worker and task errors. Do not create duplicate schedules as a first remedy: they may launch additional writes after the original cause is resolved.

A Timer delays an existing route; it does not replace the Scheduler. Use Monitor and recovery to choose an action appropriate to the observed state.

Find the correct attempt

Open Monitor and adjust the period, object type, state and worker where applicable. Find the attempt ID rather than relying only on the Workflow name: an object may have several runs. Period filters change what is displayed; they do not guarantee unlimited evidence retention.

Open details to inspect tasks, times, versions, authorized parameters and available events or logs. A queued acceptance does not mean the worker has started. A succeeded state still needs independent business-result checks.

Choose an action for the observed state

Availability also depends on your authorization and the current context. A missing button is not permission to recreate the operation through another route.

Investigate before retrying

1. Open the attempt and identify the first failed or waiting task.
2. Read its actual error, definition and version, effective parameters, worker and access to inputs or Connections.
3. Check whether the target received data even though the overall attempt failed.
4. Correct the cause in the appropriate configuration and determine whether a new publication or input is required.
5. Choose Re-run or Recover according to what should execute again and which recovery context exists.
6. Identify the resulting attempt and verify tasks, schema, rows and business rules. Preserve its relationship to the earlier attempt.

Example: an output already exists

A Session writes a CSV, then a later task fails. Repeating the whole Workflow using the same output path may overwrite or duplicate results depending on the target. In the laboratory, use an independent output and check its three records before comparing it. For an append database target, inspect keys and repeatability before launching another write.

Recover is not a distributed transaction. The recovery point and earlier commits determine which work remains persisted. Even an execution that has been terminated may have committed batches before receiving that instruction. External files and services may also have changed since the first attempt.

Accept the recovered result

• The new attempt has an ID and an explainable recovery or repetition relationship.
• Executed, skipped and reused tasks match the action chosen.
• The output satisfies its expected columns, count, keys and values, without unintended duplicates.
• Worker, task and attempt states are consistent; no unknown operation remains in progress.

Waiting tasks and missing evidence

For a waiting task, inspect parents, conditions, concurrency policies, resources and worker slots. If logs or output are unavailable, check filters, permissions and retained evidence rather than inferring a result from an empty panel. Do not purge history required for investigation. For help, use the Cloudata form with version 22.0.5, the attempt ID and a synthetic example, without credentials or customer data.

Goal and expected result

This exercise follows Mapping → Session → Workflow in Dova 22.0.5. It uses four synthetic customers and keeps the three whose status is ACTIVE. This is an expected result to verify in your environment, not a new measurement of customer data. For direct browser-upload Mapping Run, see the CSV normalization demonstration.

Download the input · active-customers-input.csvCSV · 147 BDownload, expected output · active-customers-expected.csvCSV · 89 BDownload and file instructions · README.mdMarkdown · 2.0 kBDownload. These contain no credentials and do not automatically import a definition.

Prepare the laboratory

You need authorization to design, publish and execute all three objects, a Repository location and a compatible worker. Put the input on a path authorized for that worker and prepare an independent laboratory output. A path on your laptop is not necessarily visible to a remote worker. If the run dialog requests a file, complete that input for the displayed context; do not assume an earlier attachment remains available.

customer_id,name,status,amount
D001,Demo Alfa,ACTIVE,125.50
D002,Demo Beta,INACTIVE,40.00
D003,Demo Gamma,ACTIVE,80.00
D004,Demo Delta,ACTIVE,0.00

1. Design and publish the Mapping

1. Create m_CustomersActive. Add Flat File input with CSV format, comma delimiter, header and the four sample columns.
2. Connect Row filter: field=status, operator=equals, value=ACTIVE. It filters the record’s value.
3. Add Field selector with customer_id, name and amount. It removes status from both schema and output.
4. Connect Flat File output with CSV format and header. Validate the graph, save and publish the Mapping.

This chain contains four components. It does not convert amount to a number; the exercise retains its text values. Add and configure Convert type before any operation that needs numeric comparisons or ordering.

2. Configure the Session

1. Create s_CustomersActive and select the published Mapping version.
2. Configure laboratory input/output bindings and select an eligible execution profile or worker for your environment.
3. Review parameters and failure/retry policy. For initial acceptance, avoid retries that conceal an unresolved cause.
4. Validate and publish the Session. Check that its reference and schema correspond to the selected Mapping.

3. Arrange and execute the Workflow

1. Create wf_CustomersActive. Add a Session task and select s_CustomersActive under Reusable session.
2. Connect Start → Session → End. Validate, save and publish.
3. Run manually with the test files. Record the attempt ID and open Monitor.
4. Wait for a terminal state and open the Session task to inspect its available output. Do not enable a recurring schedule yet.

4. Compare the output

Compare by customer_id. Without Row sort, do not treat an observed record order as a universal guarantee. CSV quoting or newline differences do not by themselves invalidate the exercise’s values. Do not claim byte identity when only records were compared.

Extend the exercise and diagnose issues

After accepting the minimal Workflow, insert a Timer with Delay (seconds)=5 to observe a wait without changing the data. To explore Decision, use runMode and the expression in Tasks and links. Test both values in separate attempts before scheduling it.

If four records remain, inspect the filter and executed version. For a missing column, inspect Field selector and the target. If execution never starts, check Session publication, paths and worker eligibility. If it fails after writing, review recovery before repeating it.

Purpose and access

Administrator brings together workspace access, tenant capacity, cloud workers and commercial records. Open Overview to identify where to investigate before changing a setting. Your active workspace and role determine which information and actions are available. The account menu identifies the signed-in user and the current membership. Confirm both before interpreting counts or opening another section.

The examples in this guide use synthetic data. A worker named worker-demo-a and a tenant named documentation-lab are examples, not records to locate or create in a production environment.

Read the dashboard

The summary cards show Tenants, Users, Subscriptions, Invoices, Usage and Security. Read their labels and supporting text together. A count describes the data available to the current view; it does not establish that a payment cleared, a user can sign in, or an execution succeeded.

Worker resource history compares worker CPU, memory and available disk. Select a worker from Worker, or use the worker comparison cards. Search worker..., provider, status and sort controls help locate a worker in a larger inventory. The time controls offer 1h, 6h and 24h. Zoom controls change the visible chart range; Reset restores it and Refresh requests current observations.

Other cards summarize Users by status, Invoices by status and Usage allocation. Quick access opens the corresponding administrative area when your role permits it. The operational footer provides connection and activity information while the main view is open.

Daily review procedure

1. Open Administrator and confirm the account, workspace and active role.
2. Select Overview and allow the view to finish loading. Distinguish a displayed zero from a loading error or missing measurements.
3. Read the summary cards and note which category requires investigation.
4. For a resource concern, select the affected worker and choose a comparable time range. Compare several samples, including the recorded coverage, rather than relying on one point.
5. Open Users, Subscription & billing or Cloud workers according to the symptom. Use the destination screen to verify the underlying record.
6. After any authorized corrective action, refresh the relevant view and confirm its resulting state.

Acceptance and recovery

A successful review identifies the workspace, affected record, observation period and next administrative action without exposing personal or sensitive information. For example, a laboratory memory increase should be checked against a synthetic execution in Dova before changing a worker profile.

If a card fails to load, retain the visible error message and retry after checking session and connectivity. If a shortcut is missing, review the active role; switching tenants does not resolve a permission denial. Old browser tabs may retain an earlier display until refreshed.

For execution outcomes, use Dova Monitor and the execution detail. For cloud infrastructure, continue with Cloud workers. For navigation, appearance and account options, read Preferences.

Purpose and prerequisites

Cloud workers manages execution infrastructure through four tabs: Workers, Provisioning history, Connections and Profiles. A worker record, a cloud VM and an enrolled execution agent are related but distinct states. Confirm the intended tenant, authorized cloud account, management permission and available capacity before provisioning infrastructure.

An approved cloud connection must be available, and its provider permissions and region policy must be satisfied. A worker profile defines requested capacity. Where the interface reports unsupported or unavailable capabilities, resolve that condition before proceeding. The optional price preview is an estimate, not a guaranteed bill.

Prepare a cloud connection

1. Open Connections and select New connection.
2. Enter Name, Provider, Account / project ID and Default region.
3. Complete provider-specific identity and networking fields using the approved cloud configuration. Use federation or temporary impersonation; this form does not accept cloud passwords, access keys or private keys.
4. Select the allowed Authorized regions and confirm that the default region is included.
5. Choose Save connection. Follow the displayed verification instructions, using Copy steps if needed, then select Verify or Re-verify.
6. Use Capacity to inspect the connection's current capacity and worker headroom. Read unavailable or unknown values as conditions requiring investigation.

Prepare a worker profile

1. Open Profiles and select New profile.
2. Enter Name, Provider, vCPU, Memory (GB) and Disk (GB).
3. Choose SKU compatibility. Exact resources requires a matching provider size; Allow next larger SKU permits the supported larger-size selection.
4. Review Status and optional pricing information, then select Save profile.
5. Reopen the profile to verify its saved requirements before using it in provisioning.

Provision and verify a worker

1. Open Workers and choose Provision worker.
2. Confirm Tenant and Worker access. Review the distinction between Private to this tenant and Public shared before continuing.
3. Select Cloud connection, Worker profile and Maximum concurrent slots.
4. Set Worker name, Region and Zone when the provider requires them. Resolve placement errors with the supported refresh control.
5. Use Continue and Back to inspect each step and the final review. Request Get optional quote if a price preview is useful.
6. Select Create worker once, then inspect Provisioning history and the inventory until infrastructure and agent state are verified.

Operations and recovery

The worker row menu can expose Edit configuration, Resume scheduling, Pause scheduling, Disable worker scheduling, Start VM or Stop VM according to state and permission. Scheduling and VM power are separate controls. Read any disabled-action explanation before making a related change.

If creation times out, inspect the existing operation before submitting another request. If a worker is online but unavailable for a job, check tenant eligibility, required capabilities and slot capacity. Validate a synthetic execution and its Monitor result before claiming the worker is operational for the intended workload.

Continue with Worker installation, Migration and removal and Overview.

VM state, Runtime and current operations

Status reports the VM state observed in the cloud provider: Running, Stopped or Paused. In GCP, Paused corresponds to SUSPENDED. Transitions can include Starting or Stopping. Unknown or Unavailable means no current verifiable observation; Last known identifies an earlier observation that could not be refreshed. None of these is a recent worker heartbeat or proof of available execution capacity.

Enable the optional Runtime column through Columns. It reports the worker process and admission state: Online, Offline, Draining or Disabled. It is independent from VM Status: Running does not guarantee Online. Use Refresh to update the provider observation and open More actions or the row context menu for permitted operations; the row shortcut opens View details.

Pause scheduling stops new assignments and allows active work to finish. Resume scheduling admits new work again. These actions do not suspend or resume the provider VM. Start VM and Stop VM depend on observed state and authority; Start VM can also resume a suspended VM where supported. A default, busy or public worker can block Stop VM. A public worker shares capacity with authorized tenants and never publishes a Session, its credentials or data.

Reset VM force-restarts a Running GCP VM and requires confirmation. Before sending it, Dova rechecks that no active jobs, executions or reservations exist in any tenant authorized to use that worker. A default or public worker can reset only if the complete check confirms inactivity; its references and sharing policy remain intact. The action appears only for compatible providers and states.

While a Reset result remains unconfirmed, Dova blocks new assignments and another Reset. The primary Status still describes the VM; Reset pending or Check reset separately describes the operation. Use Refresh to inspect its result without resubmitting. A completed native operation and a valid observation are needed to resolve the block; Running alone does not prove completion. Even after confirmation, Runtime needs the next heartbeat before process readiness is established.

Review Tenant, Public, Status, Slots and Last seen together. Configured and available slots can differ because of physical admission limits. An optional quote is neither a guaranteed bill nor a capacity reservation.

GCP worker networking

New GCP workers provision with private IP only; there is no public-IP selector. Configure Cloud NAT in the subnet’s region for outbound HTTPS to Dova and approved package and dependency destinations such as Debian, PyPI and GitHub. Private Google Access helps reach Google APIs, but does not replace Cloud NAT for external destinations. Verify DNS and the egress rules needed by approved connectors.

For maintenance, use IAP SSH with OS Login when its IAM roles and firewall rules are configured. Workers fetch jobs and send heartbeats over outbound connections, without an inbound application port for job delivery. The public_shared capacity policy is independent from public IP addresses. Keep job isolation and tenant credential and data scope intact.

Reset verification and recovery

1. In a controlled laboratory, inspect VM Status, Runtime, current work and the complete impact before considering Reset.
2. If a Reset is already pending, use Refresh and read the existing operation rather than submitting another.
3. When the provider confirms completion, verify the updated VM observation, then wait for a recent Runtime heartbeat.
4. For a provider failure, read the safe message and current state before deciding on another action. Preserve the distinction between completed infrastructure operation and process readiness.

Purpose and prerequisites

Use Users to inspect identities, tenant memberships, roles and access status. Viewing accounts and managing them are separate permissions. An administrator who can open the table may still be unable to create users, change roles or generate an activation link. Confirm the current workspace and active role before editing an account.

The Status and Access columns answer different questions. Status describes the identity, while Access describes its sign-in readiness. Last login records an observed login or displays Never. A presence indicator is supporting information; it does not grant access or prove an execution completed.

Find and inspect a user

1. Open Users from the sidebar.
2. Use Search users, column filters or the mobile Filters control to narrow the table.
3. Select Columns to adjust the visible fields, or Clear filters to restore the unfiltered view.
4. Open View details for the required identity and confirm its tenant, email, roles, status and access state.
5. Use Export CSV only when an export is needed and you can handle its account information appropriately.

Create or edit an account

1. Select New user, or Edit user on an existing row.
2. Enter the user's Name and Email, then select the intended Tenant.
3. Choose Active, Inactive, Suspended or Disabled according to the account's intended availability.
4. Use Select roles to assign only the roles required for that tenant. Search the available roles when the list is long.
5. If membership management is available, use Add tenant to add a permitted membership. Select its membership before using Set default or Remove.
6. For a new account, choose the displayed first-access delivery option. Copy activation link reveals a one-time link after creation; Send reset email sends first-access instructions to the registered address.
7. Submit the form once and wait for completion. Reopen the record to verify the saved tenant, roles and status.

Manage first access

For an eligible existing account, open Manage access and review the identity and current access state. Select the intended option under Available actions. Local activation labels vary by state: Reset access, Resend activation, Send new activation or Create activation. Eligible accounts can also offer Convert to local access, Restore SSO access or Revoke activation. Read the displayed impact before proceeding.

Delivery method appears when creating a local activation or converting to local access. Choose Copy activation link or Send activation email for those actions. Restoration or revocation does not require a delivery selection. The submit button uses the selected action's name; confirm that action once and verify the resulting Access state. A displayed link should be shared through an approved private channel. Do not place it in a screenshot, support note or shared document. Close the result with Done after completing the permitted delivery step.

Where available, View as user (read only) provides an inspection context. Confirm the read-only indication and exit that context before returning to normal administration.

Acceptance and error recovery

In a synthetic exercise, create Documentation operator using a controlled laboratory email address, assign a limited role and verify the final row. Successful account creation does not establish that the user completed first access; verify Access separately.

If Manage access is unavailable, check account status and whether you are inspecting your own identity. If saving fails, keep the form's message, correct the identified field and retry after checking the latest record. Review selected identities carefully before Delete selected and its confirmation.

Continue with Roles and permissions, Tenants and Authentication.

Identity and membership safeguards

Identity status, membership status and access readiness are different concepts. Membership changes require platform administration; permission to inspect or edit account fields does not allow arbitrary changes to its tenants. An administrator cannot delegate capabilities they do not possess. These actions do not permit disabling or downgrading your own account, or deleting the last active platform administrator.

An Active identity can still require activation or MFA. Before reporting access as ready, verify identity status, active membership, selected role and completed first access. An existing administrator session does not establish that another identity can sign in.

Account review checklist

Session and inspection-context checks

When the session expires or the active role changes, reconfirm permissions, tenant and current values before saving. View as user (read only) does not grant execution or mutation authority; exit the inspection context before normal administration. Keep cookies, tokens and activation material out of support requests.

Purpose and access

A tenant is the operational workspace associated with users, data assets and commercial settings. Tenants provides a directory of workspaces and their capacity. Confirm that your role permits tenant viewing or management, as appropriate. Creating a tenant and creating a user are separate operations; one should not be assumed to complete the other.

The inventory includes Tenant, Type, Parent, Plan, Usage / limits, Capacity and Status. A displayed plan name is a commercial or administrative attribute. Check the applicable subscription and entitlement details before concluding what a tenant can use.

Inspect a tenant

1. Open Tenants and search for the workspace by its displayed name or identifier.
2. Use column filters to separate organization, individual or reseller tenants, or to inspect a status or capacity state.
3. Read Usage / limits with its units. Seats, monthly jobs and storage measure different resources and should not be added together.
4. Open View details to confirm the tenant's identity, parent relationship, plan, status and configured limits.
5. Use Columns, Rows, Previous and Next as needed. Wide data remains inside the table's scrolling area.

Create or maintain a tenant

1. Select New tenant, or Edit tenant for an existing row.
2. Set Name and the appropriate Type: Organization, Individual or Reseller.
3. Select Parent reseller when a supported reseller relationship applies. Direct customer indicates that no parent reseller is selected.
4. Choose Status, Plan, Seats, Monthly jobs and Storage MB using the values authorized for this workspace.
5. Review the complete form, submit once and wait for the result.
6. Refresh or reopen the tenant and confirm the resulting status, relationship and capacity values.

Use Suspend tenant and Reactivate tenant only after reviewing the affected workspace and expected availability. These are administrative status changes, not a migration of the tenant's objects. Inspect linked users and operational obligations before using bulk deletion.

Trials and lifecycle

A Trial status should be interpreted with the subscription's dates and lifecycle information. To inspect or extend an eligible trial, open Subscription & billing, select the same tenant and use the supported Extend trial flow. Do not recreate a workspace to change its commercial status.

When reviewing a trial-to-paid transition, verify that the expected workspace remains selected and that subscription and entitlement information reflect the intended outcome. Commercial activity and infrastructure readiness are separate checks.

Acceptance and recovery

For a laboratory tenant named documentation-lab, verify the visible usage, limit units, plan and status after saving. A successful exercise preserves the intended workspace identity and confirms that unrelated memberships remain unchanged.

If a save or capacity read fails, inspect the visible message and reload the latest record before retrying. A warning or critical capacity indicator calls for investigation of the individual resource and applicable policy. It does not automatically justify increasing every limit.

Read Subscription and billing for commercial lifecycle, Preferences for limit policies and Cleanup and tenant lifecycle before destructive maintenance.

Continuity and commercial restrictions

Switching tenants revalidates active membership. Commercial expiry preserves objects and the permitted safe reading, but does not enable new mutations or executions. Commercial reactivation does not override an administrative or security suspension.

The Plan name alone does not describe all entitlements. Check the current subscription and purchased contract, and read the Plans & billing notice in a restricted commercial state before attempting creation, editing or execution.

Tenant capacity field reference

Do not interpret an empty required number as unlimited. After a laboratory capacity change, reopen the same tenant and compare identity, units and persisted values. Reducing a limit without reviewing current use can prevent later operations.

Understand the access model

Roles & permissions separates assignable roles from the permission catalog. A permission describes an authorized operation; a role groups permissions for an intended responsibility. The role's scope and tenant determine where that responsibility applies. Access to the screen does not itself authorize editing every role or assigning a role to every user.

Before changing a role, identify its intended users, the tenant concerned and the operations those users actually need. Review a current account in Users to understand its existing assignments. Use a laboratory role and identity to validate a proposed access arrangement before applying it more widely.

Inspect existing roles and permissions

1. Open Roles & permissions and select the Roles tab.
2. Search for a role, use table filters and open View details.
3. Review the role's key, label, scope, description and assignment information.
4. Select Permissions to inspect the permission catalog. Search for the relevant capability and open its details.
5. Use Columns and Export CSV where available to support a permitted review. Keep exported account and access information in an approved location.

The permission catalog is an inspection reference. Do not infer that a displayed permission is currently granted to the signed-in user or to the user being reviewed. Check the role assignment and its actual scope.

Create or edit a tenant role

1. Select New role, or Edit role on an editable role.
2. Enter a stable Key and a readable Label. Choose names that describe the responsibility without implying broader access.
3. Confirm Scope and Tenant before selecting permissions.
4. Enter a Description explaining when the role should be used.
5. Review the available permission choices and select the smallest set needed for the intended workflow.
6. Submit the form and verify the saved role in the table.
7. Open Users, assign the role to a synthetic laboratory account and verify both a permitted action and a relevant denied action.

System or immutable roles may be viewable without exposing edit or delete actions. Do not attempt to duplicate an immutable role merely to bypass that restriction. If a new responsibility is needed, create an appropriate editable tenant role through the supported form.

Remove a role safely

Delete role is available only for an eligible editable role. A role with assignments cannot be deleted through that action. First inspect the affected identities and decide which supported reassignment is appropriate. Reopen the role after those changes and verify its current assignment count before confirming deletion.

Acceptance and recovery

Successful access validation demonstrates the expected capability within the selected tenant and a denial outside its authorized scope. A button appearing in a menu is not sufficient evidence of authorization.

If a save is denied, verify the active role and workspace rather than changing tenants to evade the denial. If deletion is disabled, inspect assignments and immutability. After a change, refresh the relevant accounts and review Audit where appropriate.

Related guides: Users, Tenants and Authentication.

Built-in responsibilities and effective access

Check the current catalog and effective session role; role names describe responsibilities and do not replace permission, tenant and contract checks. Custom roles remain tied to their tenant. The unique master administrator’s DovaAI quota exemption does not extend to every administrator: it requires an active persisted identity, active platform tenant and valid membership and selected role. Provider availability is still required.

Tenant role field reference

Purpose and prerequisites

Subscription & billing contains Subscription, DPU & calculator, Payments & invoicing, Licenses, Commerce, Global catalog and Tenant offers. Select the intended Tenant before inspecting or changing its commercial information. Viewing, operating billing and managing the global catalog require their respective permissions; global catalog changes require the authorized platform role.

A subscription, invoice, license and commerce order are separate records. A manual invoice status update does not independently establish payment settlement. Issuing a license does not prove an installation activated it. Use each record's supported detail and lifecycle to verify the intended result.

Maintain subscription and billing profile

1. Select the tenant and open Subscription.
2. Read the subscription summary and choose Manage when an authorized update is required.
3. Select Plan and the appropriate Status, then choose Save subscription.
4. Use Edit profile to review legal name, billing email, tax identification, country and address.
5. Save the profile and reload the tenant's subscription information to confirm persistence.

For an eligible trial, Extend trial opens a separate review. Inspect the current end, choose the displayed extension option and enter the required reason. Verify the new end and preserved tenant identity after acceptance. Detailed eligibility and recovery are explained in Tenant lifecycle.

Create or maintain an invoice

1. Select New invoice in the invoice inventory.
2. Enter Number, Amount, Currency, Due date, Status and Description as required.
3. Review amount and currency together, then choose Create invoice.
4. Reopen the invoice's details and verify the saved record.
5. When a lifecycle update is authorized, use its status dialog and Update status. Select a status reflecting the verified administrative process.

The invoice editor offers USD, PEN and EUR. The set of invoice currencies should not be assumed to extend the separate Commerce catalog's supported currencies. Use search, filters and Export CSV only for the required billing review.

Issue, activate and revoke licenses

In Licenses, choose Issue license and review Reference, Paid invoice, Maximum activations and Expires on. Verify the invoice association and validity before issuing. Protect a displayed key using approved private storage.

Activate opens the supported license activation flow with License key and Runtime / installation ID. Verify the resulting activation separately. Revoke license requires its confirmation and does not imply a financial refund.

Commerce and acceptance

In Commerce, inspect Plans available and Order summary. Continue to checkout or New checkout opens the order form. Review price, quantity, payment method, customer type, fiscal document, legal details and billing address. Use the supported browser payment flow; never enter card data into a documentation example.

A synthetic exercise should use fixtures or an authorized sandbox and stop before any real charge. Confirm the tenant, order terms, subscription and invoice independently. If a checkout response is delayed, inspect recent activity before submitting another order because the provider may already have accepted an operation.

Read Global catalog and offers for versioned terms and Audit for administrative evidence.

DPU, calculator and funded periods

The seven current tabs are Subscription, DPU & calculator, Payments & invoicing, Licenses, Commerce, Global catalog and Tenant offers. Confirm Tenant and authority before using each area.

1. Open DPU & calculator for the intended tenant and use Refresh usage as needed.
2. Compare included, consumed, available and reserved capacity in each environment. Check the funded period, which need not be a calendar month.
3. In the authorized calculator, review proposed allowances, concurrency, currency and commercial terms. An estimate does not change an active subscription.
4. If publishing an eligible offer, confirm its frozen price and terms for the intended tenant. Verified purchase and activation determine when it takes effect.

The DPU model applies only to a DPU-enabled plan revision. A legacy subscription keeps its purchased terms; opening the calculator or publishing a different offer does not convert it. Actual allowances and limits come from the current contract. A monthly display label does not replace checking the funded period’s dates.

Accepted DovaAI queries have tenant and user quotas separate from DPU consumption. A payment or fiscal-document sandbox does not establish production acceptance. A browser return, invoice creation or manual status edit does not prove confirmed payment.

In a laboratory, estimate 4 DPU × 15/60 h = 1 DPU-h and compare Development with Production without transferring funds or charging a card. Check estimate, published offer, active contract and observed consumption separately.

Purpose and access

Audit provides a read-oriented record of administrative activity available to the current workspace and role. Use it to inspect an event's action, actor, timing and associated record, then correlate those details with the relevant administrative screen. The visible audit trail is one source of evidence; it does not independently prove payment settlement, provider completion or execution success.

Before investigating, define the question you want to answer. For example: which permitted administrator changed a laboratory user's role, when was a trial extension recorded, or what happened around a worker configuration attempt? Keep the investigation within the workspace and information your role authorizes.

Locate and inspect events

1. Confirm the active account, workspace and role in the account menu.
2. Open Audit and wait for the inventory to load.
3. Use Search audit events to narrow the records by the displayed information relevant to your question.
4. Apply available column filters, checking the selected period and status where applicable.
5. Open View details for the event and inspect its visible action, actor, timestamp and subject.
6. Open the associated screen, such as Users, Tenants or Cloud workers, and confirm the current record state.
7. Refresh the audit view if you need to inspect a recent authorized action.

Columns changes presentation. Clear filters restores the broader visible inventory. Rows, Previous and Next control pagination. On mobile, use Filters and the existing table viewport rather than assuming hidden columns are absent from the record.

Build a useful evidence note

Record the administrative question, workspace scope, displayed event time, action, subject and observed result. Distinguish the recorded event from a conclusion that you infer after checking another screen. Preserve the relevant time context when comparing timestamps from different systems.

Use Export CSV only when the investigation requires an authorized export. Store the result in an approved location and share the minimum needed information. Exports may contain identifiers or account details even when the application avoids showing secrets.

Synthetic acceptance exercise

In an authorized laboratory, edit the description of an editable tenant role. Confirm the saved role in Roles & permissions, refresh Audit and locate the corresponding activity if recorded and visible to your role. The exercise succeeds when the role state and audit observation describe the same intended action within the same tenant.

If the event is absent, inspect filters, paging, workspace selection and the delay between the action and refresh. Do not invent an audit event or conclude that an action failed solely because the currently displayed page does not contain it.

Errors and recovery

A loading failure should be reported using the visible message and a bounded description of the scope and time. Retry after checking connectivity and session validity. A permission denial requires an authorized access review; switching tenants is not an evidence-preserving workaround.

For the action itself, return to Users, Roles and permissions, Subscription and billing or Cloud workers. The current record and its supported detail view remain necessary parts of the investigation.

Purpose and access

Registrations presents self-service customer requests for administrative review. The screen supports inspection and a decision on an eligible pending request. Viewing a registration and deciding it are separate capabilities. Confirm the current workspace and your review permission before acting on an applicant.

An approval records the review decision. Tenant and user provisioning remain separate. Do not tell an applicant that a workspace or account is ready solely because the registration changed to approved. Review the actual tenant and user records through their supported administrative screens.

Inspect an application

1. Open Registrations from the sidebar.
2. Use Search registrations or the column filters to locate the relevant request. On a narrow screen, open Filters as needed.
3. Open View details and confirm the applicant's name, email, organization, type and current status.
4. Check the received date and any existing reviewed date, reviewer and review reason.
5. If the row is stale or another administrator may have acted, select Refresh before deciding.

Export only the permitted information required for the review. Use Columns, Rows, Previous and Next to manage a large list without changing its underlying records. Search and filtering do not themselves approve or reject an application.

Approve a pending request

1. Open Approve registration for the eligible pending row.
2. Check the applicant shown in the confirmation dialog.
3. Enter Reason (optional) when your review process benefits from a short explanation.
4. Select the confirmation acknowledging the applicant and decision displayed above it.
5. Choose Approve registration once and wait for the response.
6. Confirm the saved status and review information in the refreshed list or details.

Reject a pending request

1. Open Reject registration for the intended pending row.
2. Check the applicant and enter Reason (required).
3. Keep the reason between 1 and 1,000 characters and avoid personal information beyond what the review needs.
4. Select the confirmation and choose Reject registration once.
5. Verify the resulting status, reviewer and explanation after completion.

Acceptance and recovery

Use a synthetic request from documentation-lab to practice inspection without contacting a real applicant. A successful review produces one recorded decision for the intended request and preserves a traceable reason where required. It does not create a tenant, assign a role or generate first-access instructions.

If a decision fails because the record changed, close the stale review and refresh the list. Inspect the current status before reopening an action. If the response cannot be verified, use the same decision's supported retry rather than changing the decision or repeatedly submitting new requests.

Review controls disappear when the request is no longer pending or your role lacks management access. Treat that as a state or permission condition. Do not attempt to bypass it through another tenant or a handcrafted request.

Continue with Tenants, Users and Audit to verify the separate provisioning and access steps.

Decision review fields

A laboratory acceptance check should reject an empty required reason and an unchecked confirmation without recording a decision. After one authorized test decision, verify the intended row and review information. The exercise must not contact or decide a real customer application.

Purpose and prerequisites

Developer Tools provides the published Dova CLI catalog, platform guidance and API key tools. It shares its presentation with the Dova workspace. Opening this view or downloading a distribution does not grant access to a tenant or authorize an administrative command.

Choose the operating system of the destination machine, which may differ from the computer running your browser. Before using a downloaded tool, identify the intended laboratory workspace, the permitted operation and the credential scope required for it. Keep operational credentials outside repositories, screenshots and documentation.

Download a published distribution

1. Open Developer Tools and allow its release catalog to load.
2. Inspect the available platform entries and select the destination platform.
3. Confirm that the main download and the Quick start guidance correspond to that selected distribution.
4. Read the release information, availability, checksum and signing information exposed for the artifact.
5. Download through the published link and verify the file against the checksum for that exact artifact.
6. Follow the distribution's current Quick start steps in an authorized environment.

Availability, integrity and signing are different properties. A successful download proves neither that the file's integrity matches nor that it is signed. Describe each property according to the published metadata, and do not present an unsigned artifact as signed.

Configure permitted access

Use the supported API key flow only when your role permits it. Check the intended tenant and the available scope before creating or selecting a key. If a one-time credential is displayed, transfer it to approved secure storage without including it in shared notes or screen captures.

Copy commands from the current distribution's Quick start or its linked CLI reference. This guide intentionally does not invent subcommands, package names or flags. Document the version and required configuration for an automation, but substitute descriptive placeholders for credential values.

Acceptance exercise

In a synthetic catalog, select a Linux entry and confirm that its download, metadata and instructions agree. Switch to a Windows entry and repeat. This checks navigation and catalog consistency without installing a binary or creating a real key.

For a functional laboratory exercise, download the verified distribution and perform one explicitly permitted read operation against a synthetic resource. Record three separate outcomes: the distribution was available, its integrity matched, and the authenticated operation was authorized. Passing one outcome does not establish the others.

Errors and recovery

If no distribution is available, inspect the release catalog's message rather than guessing a URL or filename. If the checksum differs, stop using that download and obtain the correct artifact through the supported process.

For an authentication or authorization error, inspect the selected workspace, credential validity and allowed scope. Creating a stronger credential is not the first diagnostic step. Revoke or retire keys through their supported lifecycle when they are no longer needed.

Keep commands complete and copyable in downloaded documentation. Long platform tables can scroll within their own viewport. Continue with Worker installation for execution capacity and Preferences for the account and appearance controls.

Find the correct scope

Preferences groups administrative settings while preserving the distinction between tenant settings and platform settings. The visible sections depend on your active role. Opening Preferences does not imply permission to edit authentication, email transport or every tenant's limits. Read the scope badge, selected tenant and enabled actions before changing a value.

The Dova 22.0.5 application uses compact spacing, readable labels and consistent controls in day and night themes. On mobile, section navigation and toolbars remain available through wrapping or their local scrolling areas. Use the account menu for appearance and account options; use Preferences for the administrative policy concerned.

Account and appearance procedure

1. Open the account trigger in the top bar and confirm the identity and workspace membership shown.
2. Select another permitted membership or role only when it is the intended context for your work.
3. Adjust theme and palette using the appearance controls. Check the resulting selected values and status feedback.
4. Use Back to workspace, Downloads, API Keys or Documentation for the related destination when available.
5. Close the menu with Escape to return focus to its trigger. Use Sign out to end the account session when your work is complete.

Review tenant limit defaults

1. Open Preferences and select Limits.
2. Choose Configuration scope. Platform defaults establishes inherited defaults; a tenant selection addresses that tenant's permitted overrides.
3. Read the scope summary before editing. Distinguish inherited values from explicit overrides.
4. Select Workers and capacity, Executions and objects, Retention, API and budget or Security and access.
5. Read each limit's label, description, current value and unit. Workers, slots, memory, executions and retention periods are different resources.
6. Edit only the authorized values, remaining within the displayed validation range. Where available, use the inheritance control to restore a tenant's inherited value.
7. Select Save changes after the form records a real change. Reload the same scope and verify the saved policy.

The save control remains disabled when nothing changed. Reverting an edit to the loaded value should leave no pending update. If you change scope with unsaved edits, review Keep editing and Discard changes instead of assuming the previous values were saved.

Acceptance and recovery

For a synthetic tenant, change one permitted capacity value, save it and reload that tenant's policy. Verify the value, unit and inheritance state while confirming that platform defaults and another tenant's policy remain unchanged.

If a field is unavailable, inspect scope and permission before changing roles. If a save fails, retain the visible message and pending edit, refresh the relevant baseline when instructed, then retry the reviewed value. A limit change does not install infrastructure or guarantee that a workload is eligible to run.

Read Notifications and email, Authentication and Cleanup for those specific preference sections.

Select the administrative preference section

The five sections have different authorities. Appearance, palette and authorized membership changes in the account menu do not modify permissions or commercial terms. Do not raise limits to evade a commercial or security restriction. Review the relevant current scope after a session or role change.

Purpose and authority

Preferences → Authentication configures supported external sign-in providers. Management of this global configuration requires the authorized Platform Administrator role. A role that can inspect ordinary Preferences does not automatically have authority to save provider settings, replace secrets or test global authentication.

SSO establishes identity, role assignments control authorization, and MFA completes the account's required verification. Enabling an external provider does not grant administrative access or remove MFA. Prepare an authorized recovery route and a laboratory identity before changing an integration.

Configure an external provider

1. Open Preferences → Authentication and select the intended provider's card.
2. Prepare an approved application in the provider's administration system.
3. Copy Dova's read-only Authorized callback URL and register that exact address with the provider.
4. Enter Client ID and the provider-specific configuration. Microsoft uses Tenant ID; Okta and Auth0 use Issuer URL; GitLab can use its supported issuer for the intended service.
5. Use Replace client secret only when replacing the stored secret is necessary. Leaving it blank preserves the current value according to the form's guidance.
6. Set the provider's enabled state and choose its corresponding save action, such as Save Google or Save Microsoft.
7. Confirm persistence, then use Test discovery or Test provider as displayed. The test uses the saved configuration, not unsaved fields.
8. Perform a fresh sign-in with the authorized laboratory identity and verify the final workspace and role.

The supported cards are Google, Microsoft, Okta, Auth0, GitHub and GitLab. The GitHub card states that a verified primary email must match an active Dova user. Follow each provider's own identity rules rather than applying one provider's onboarding behavior to all six.

Registration policy

Allow self-registration has a separate Save registration policy action. Review the current onboarding policy and the resulting workspace identity when testing it. Enabling this switch does not convert existing accounts, renew trials or assign platform roles. An access refusal caused by account lifecycle should be investigated through the tenant and subscription information.

Complete MFA

At sign-in, follow the Verification or recovery code flow. For first-time factor setup, register the displayed QR or setup key privately in the intended authenticator and submit its current code. Store one-use recovery codes securely. Do not capture the setup key, QR, recovery codes or verification codes for documentation.

Trust this device is an explicit account choice. It does not disable MFA globally. If you selected the wrong identity, use Use another account. If the factor is unavailable, follow the authorized recovery process.

Acceptance and error recovery

Test an authorized identity, an unauthorized identity and an incorrect verification code in a controlled environment. Successful configuration admits only the authorized account into the expected workspace. A provider discovery result alone does not prove complete login success or role authorization.

For failures, inspect callback accuracy, issuer or tenant, enabled state and account correspondence. Separate provider connectivity, MFA failure and permission denial. Avoid repeated secret replacement without identifying the failed stage.

Related guides: Users, Roles and permissions and Tenant lifecycle.

Pending MFA and current session

When sign-in reports mfaRequired, authenticated=false is expected until the second factor is completed. Accepting a password or external identity alone does not establish a fully authenticated session. An expired verification requires a new sign-in and the current challenge. Do not reuse a challenge from an old tab or share codes so another person can complete the login.

Understand the commercial model

Subscription & billing contains Global catalog and Tenant offers. The catalog is shared across tenants, while an offer applies to its selected tenant. Products, plans, published plan versions and prices have different responsibilities. Confirm catalog-management authority and the selected tenant before changing commercial records.

Published plan terms remain associated with their version. A new set of terms begins as a draft, and an existing used price may require New price rather than editing its historical value. Review the record's status and available row actions before deciding how to make a change.

Create or revise the catalog

1. Open Subscription & billing → Global catalog.
2. Use search, filters, Columns and View to inspect the existing products, plans, versions and prices.
3. Create a product or plan using New product or New plan where permitted. Enter the form's identity and description fields.
4. On an eligible plan or version, choose New draft to prepare revised terms.
5. Review the draft's limits and entitlements. The editor's JSON fields require the indicated object format and supported value types.
6. Save and inspect the draft. Use Publish and Publish version only after reviewing the resulting terms.
7. Use New price to create a price for the intended Published plan version.
8. Set Amount (minor units), Currency, Billing interval, Tax behavior and Tax rate (basis points), then verify the saved price.

One hundred minor units equals one currency unit. One hundred basis points equals one percent. These units should be checked before saving an amount, discount or tax value. Review the final order summary rather than interpreting an amount alone as a tax-inclusive customer total.

Configure a tenant offer

1. Select the intended Tenant and open Tenant offers.
2. Read the scope description and choose Reload offers if another administrator may have made a change.
3. Choose New offer, or edit an eligible existing offer.
4. Select Published price and confirm its read-only currency.
5. Choose Offer type: a discount in basis points or a negotiated amount in minor units.
6. Set Valid from (UTC), optional Valid until (UTC) and Status.
7. Save and reload the same tenant's offers. Verify that its eligible price is reflected in the applicable commerce view.

When no eligible offer exists, public prices apply. Creating an offer does not duplicate the global catalog or rewrite the terms of an earlier order.

Acceptance and recovery

In a laboratory catalog, create a draft change and a synthetic offer for one tenant. Verify that another tenant continues to receive the applicable public price and that published historical terms remain inspectable.

If an editor reports that a record changed, preserve the entries, close it, reload the catalog or offers and reopen the latest record for review. If access or tenant changed, reopen in the correct authorized scope. Use Retire only after inspecting the record and its lifecycle implications.

Continue with Subscription and billing, Tenants and Audit.

Separate content, transport and policy

Execution email content, SMTP delivery and notification policy are three configurations. Execution email template defines the message, Email delivery defines the platform transport, and Notifications chooses events, channels and routing. A valid preview does not prove message delivery, and a successful SMTP connection does not prove an event qualifies for a notification.

Check the selected tenant and the relevant view or management authority. Platform SMTP management requires the authorized Platform Administrator role. Use a controlled test recipient and synthetic execution data for validation.

Edit an execution email template

1. Open Preferences → Notifications → Execution email template.
2. Confirm the template's displayed scope and inheritance before editing.
3. Select the supported execution outcomes: succeeded, failed or cancelled. At least one outcome must be selected.
4. Enter a meaningful subject and optional preheader. Keep each on one line.
5. Compose both HTML and plain-text content. The text version is required and should communicate the same operational result as the HTML version.
6. Insert variables from the editor's supported catalog, using its documented percent-delimited syntax.
7. Preview the message at narrow width and inspect headings, contrast and links.
8. Save, reload and verify the content before testing actual delivery.

For a synthetic example, %WORKFLOW_NAME%, %STATUS%, %RUN_ID%, %OUTPUT_ROWS% and %EXECUTION_URL% can describe an execution and link to its authorized detail. Unknown variables are rejected. Use the available catalog instead of inventing placeholder syntax. Keep logs, credentials and sensitive data out of message bodies.

Configure SMTP delivery

1. Open Preferences → Email delivery.
2. Review SMTP host, Port, Encryption, Username, From name, From email and Reply-to email.
3. Enter Replace password only when replacing the stored credential. Blank preserves the current password according to the form.
4. Set Test recipient email to a mailbox you are authorized to use.
5. Save the reviewed configuration through Save email, then use Test SMTP as the supported form permits.
6. Choose Send test email and verify actual receipt, subject, text and link readability.

Configure notification policy

In Notifications, review Show action notifications, Position, Duration (seconds) and Maximum visible. Select the intended Delivery channels, endpoints, Events and severity, recipient roles, thresholds, deduplication, escalation and digest settings. For quiet hours, verify the selected timezone and both time boundaries.

Use Preview, Test channels and Save preferences for their distinct purposes. Inspect Delivery history after a controlled test. Sent, failed, suppressed and acknowledged outcomes should be interpreted separately; suppression by policy is not automatically an SMTP failure.

Acceptance and error recovery

A complete laboratory check verifies template persistence, correct substitution, the configured policy and actual receipt at the controlled mailbox. Record each outcome separately. Never include secret endpoint values or SMTP credentials in screenshots.

If testing fails, retain the safe displayed message and inspect one layer at a time: content, connection and credentials, then policy. Review event selection, quiet hours and deduplication before repeating a send.

Related guides: Preferences, Users and Audit.

Template field limits and variable catalog

Subject: %STATUS% result for %WORKFLOW_NAME%
Run: %RUN_ID%
Output rows: %OUTPUT_ROWS%
Authorized detail: %EXECUTION_URL%

Place each variable between percent signs. The limits are ceilings, not design targets. Keep the message short and link to the authorized detail. Unknown variables are rejected; the template is not executable code. A safe preview can restrict remote image rendering, and actual mail-client rendering needs its own controlled validation.

Choose the installation path

There are two supported paths: install Dova Worker Agent on an existing authorized server, or provision a cloud VM through Administrator → Cloud workers. Neither path automatically assigns every existing Session to the worker. Before starting, confirm tenant, operating system, approved capacity, outbound connectivity and responsibility for the infrastructure.

Download the currently published package through the supported catalog and verify its integrity. Package versions can differ from the Dova application version. Use the instructions bundled with the selected package and perform the initial exercise on an authorized laboratory server.

Linux prerequisites and installation

The documented prerequisites include Python 3.10 or later, a virtual environment, systemd, util-linux with flock, administrator access and outbound HTTPS to Dova and the approved package registry or mirror. The installer checks requirements; do not assume it installs a different Python or changes the operating system.

1. Extract the verified package on the laboratory server.
2. Run the prerequisite check from the package directory.
3. Complete installation only after resolving the reported requirements.

sudo sh execution-worker/install.sh --check
sudo sh execution-worker/install.sh

In Dova, use Register worker, select the intended system, enter the worker name and permitted concurrency, and generate the enrollment instructions. Run the generated command on the correct server. Supply the enrollment token through the supported hidden prompt, never through documentation, shell history or a shared screenshot.

After enrollment succeeds, enable and inspect the service:

sudo systemctl enable --now dovaetl-execution-worker
sudo systemctl status dovaetl-execution-worker

Windows Server prerequisites and installation

Use supported 64-bit Windows Server, PowerShell 5.1 or later and a machine-wide 64-bit Python 3.10+ installation accessible to the service account. A Windows Store alias or a Python installed only for the interactive user is unsuitable.

1. Extract the verified Windows package.
2. Open an elevated PowerShell in its directory.
3. Follow the bundled installer instructions and identify the actual machine-wide Python executable.
4. Generate enrollment for Windows Server and complete its hidden-prompt flow.
5. Start and inspect the installed service after successful enrollment.

Set-Service -Name DovaWorkerAgent -StartupType Automatic
Start-Service -Name DovaWorkerAgent
Get-Service -Name DovaWorkerAgent

The service uses a dedicated virtual account. Windows process limits do not make arbitrary untrusted code safe, and Windows workers remain private-only under the supported sharing contract.

Cloud installation and acceptance

Prepare Connections and Profiles, then use Provision worker as described in Cloud workers. Observe Provisioning history until you distinguish VM creation from completed agent enrollment.

Verify service state, recent heartbeat, displayed resources and tenant eligibility. Assign a synthetic Session to the worker, execute a small controlled file transformation and inspect its Monitor result. Concurrency represents slot units: a job can reserve more than one unit, so capacity is not simply a count of jobs.

If the worker is offline, inspect service, outbound connectivity and safe logs. If it is online but ineligible, inspect tenant, capabilities, policy and capacity. Enrollment does not configure database credentials or transfer input files.

Continue with Worker migration and removal before replacing or retiring infrastructure.

Private workers and isolated public capacity

Private workers support their Linux and Windows paths. Isolated public capacity is Linux, requires explicit enablement and a verified approved runtime. The isolated process transforms CSV and Excel files without network access or ambient cloud identity; the bounded public JSON acquisition is described below. It exposes neither host files nor persistent checkpoints; an unsupported task fails explicitly rather than falling back to an unisolated process. These shared-capacity boundaries do not describe every connector on a private worker.

Windows installer example

From the verified package directory, use the installer included with that distribution and substitute the real machine-wide Python path. The following documented path is illustrative, not a requirement to install Python in that exact directory:

.\execution-worker\install-windows.ps1 -Python 'C:\Program Files\Python312\python.exe'

Follow the organization’s script policy rather than disabling it globally. The installed service account is NT SERVICE\DovaWorkerAgent; configuration, rotated logs and scratch data are separated from immutable runtime releases. An upgrade preserves the registered identity and keeps the prior release for rollback. Do not enroll an already registered installation again.

Public JSON input and isolation boundaries

The approved package also supports one public HTTPS JSON GET acquisition without authentication or pagination, followed by supported transformations and CSV output. The trusted agent validates the public destination and acquires at most 8 MiB. The isolated child receives a read-only input descriptor and a bounded output descriptor; it does not gain network access. CSV output is capped at 15 MiB and is not transported as inline Base64. Direct network connectors and checkpoints remain rejected on this shared capacity.

A heartbeat or local probe alone does not enable public-pool readiness. The platform must verify the approved installation and runtime on the managed host. A manually enrolled private worker is not automatically upgraded or certified for public sharing. These checks are not a claim of cryptographic kernel attestation.

Scope and prerequisites

Worker migration changes execution references to compatible authorized capacity. It does not automatically transfer files, databases, credentials or an operating system. Confirm the source tenant, eligible destination, worker-management authority and operational window before beginning.

A dependency backup preserves assignment metadata and integrity information. It is not a VM image or a complete data backup. When restoring or reassigning from saved metadata, verify that the destination currently satisfies the required capabilities and that the referenced objects still exist.

Inventory and prepare

1. Open Cloud workers → Workers and inspect the source worker.
2. Use Reassign references, Dependency backups or Restore/reassign to another worker as appropriate.
3. Read the current references and confirm the source tenant and worker.
4. Review active or queued executions, default-worker usage, Sessions, Workflows and any credential or connection dependencies.
5. Use Pause scheduling when the intent is to stop assigning new work while allowing existing work to finish.
6. Resolve incomplete inventories and provider-state errors before attempting removal.

Scheduling changes and VM power changes are different actions. Stopping a VM is not a replacement for a controlled wait for active executions to finish.

Preview and apply reassignment

1. Select the supported Destination worker and the intended references.
2. Confirm Destination credentials have been configured and verified only after checking the actual destination configuration.
3. Choose Preview changes and inspect the proposed changes, warnings and blockers.
4. If you change destination, selection or relevant configuration, generate a new preview.
5. Apply the allowed plan through Apply reassignment and verify the reported result.
6. Refresh source and destination information and inspect the saved dependency backup where applicable.

The interface manages the preview and retry identifiers. Do not alter them to override a conflict. Download metadata copy provides the displayed backup scope; it should not be treated as a portable copy of all object contents or secrets.

Resolve Sessions and deprovision

The removal flow can offer Replace worker, Distribute Sessions or Disable affected Sessions. A replacement must be compatible with every affected Session. Distribution requires a complete assignment plan. Disabling affected Sessions changes their ability to run, and linked Workflows can show a dependency error.

Open the removal dialog, refresh impact and review provider resources, references and execution activity. If the supported flow offers Stop and deprovision the VM, read its effect before selecting it. Enter the displayed Type to confirm value and acknowledgment only after all permitted prerequisites are satisfied, then submit once.

Acceptance and recovery

In a laboratory, reassign one synthetic Session, verify the published references and backup, then refresh the source impact. Successful removal requires confirmed provider absence and final reference checks. A provider error preserves the Dova record for diagnosis and retry; unknown or unavailable is not equivalent to absent.

After a network error, reopen the operation and inspect current state before retrying. Closing a dialog does not cancel a request already accepted by the provider. Do not claim resource removal or cost savings until the provider result and the corresponding Dova state are verified.

Related guides: Cloud workers, Worker installation and Audit.

Shared capacity and historical references

Removal of public capacity checks references across authorized tenants and historical versions still in use. Inaccessible historical versions are preserved and do not block removal by themselves. Resolve public policy, default-worker dependencies, active sessions and complete inventory before removal.

Before applying, confirm that the destination satisfies each object’s capabilities. Files and connections still need their separate preparation. An assignment backup does not transfer secrets or guarantee that today’s destination matches its earlier state.

Choose the correct operation

Deleting ETL data, extending a trial, suspending a tenant and canceling a subscription have different scopes. Preferences → Data Cleanup removes the selected tenant's ETL records while preserving the listed identity, access and commercial records. It does not delete a cloud VM or substitute for a lifecycle process with retention requirements.

Confirm the intended tenant, authorized purpose, management permissions and applicable retention process before acting. Use a synthetic laboratory workspace for practice. A managed individual tenant can reject generic ETL cleanup and require its separate lifecycle process; do not change tenant type or subscription management to evade that restriction.

Review cleanup scope

The screen lists Mappings, Sessions, Workflows, Connections, credentials, runs, Repository data and tenant ETL preferences as deletion categories. It identifies users, the tenant, roles, billing and global administrator audit as preserved records. Read the current inventory because the category list alone does not establish what data is present.

1. Open Preferences → Data Cleanup and select Tenant.
2. Choose Refresh inventory and inspect counts, scope and any blockers.
3. Obtain and verify the authorized backup required for the operation. The form is not an automatic backup of the entire tenant.
4. Choose Clean tenant ETL data and compare the dialog's tenant and summary with the inventory you reviewed.
5. Complete Type to confirm and the irreversible-data acknowledgment.
6. Select Delete ETL data once and wait for the verified response.
7. Refresh inventory, verify the affected categories and separately confirm the listed preserved records.

If the inventory changed, refresh and review the latest state. A conflict or failed response does not authorize direct deletion of storage files or modification of the inventory revision.

Extend an eligible trial

1. Open Subscription & billing, select the same tenant and use Subscription → Extend trial.
2. Review the current lifecycle, dates and eligibility.
3. Choose 7 days, Custom days or Exact date and time.
4. For a custom number of days, use the displayed allowed range. For an exact date, verify the dialog's timezone and resulting end.
5. Enter the required Reason, review the new end and choose Extend trial once.
6. Confirm the accepted expiry while checking that tenant identity, existing objects and original trial history remain intact.

The supported day extension counts from the current end for a running trial, or acceptance for an expired eligible trial. The dialog shows local time and stores the instant consistently. An extension does not recreate the workspace, reset quotas or grant unrelated entitlements.

Lifecycle acceptance and recovery

An expired or past-due tenant may retain permitted safe reading, export and billing access while new business mutations or execution remain restricted. Available reading should not be interpreted as authorization to recreate objects, enroll infrastructure or generate new work.

Use separate laboratory exercises for cleanup and trial extension. For cleanup, verify deletion scope and preserved accounts. For extension, verify expiry and identity continuity. Following a network error, inspect current state before retrying; an identical retry should not produce an unintended second extension.

Read Tenants, Subscription and billing and Worker removal for their distinct operations.

Scope and compatibility criteria

A Connection combines an address, metadata, authentication method and credential custody. A Mapping component selects that connection and specifies an operation on a resource. The Worker executes the operation with its effective capabilities and permissions. These are three separate contracts: creating a connection does not guarantee that a provider supports every read, write or recovery mode.

Use this matrix to prepare the Connections form. Code identifiers help recognize configuration and interpret errors. An asterisk marks a required field in the form catalog; authentication, protocol or provider validation can make other fields required. Ports are initial values rather than instructions to open unrestricted network access. The endpoint must belong to the organization's authorized environment.

Connection catalog matrix

The matrix lists the entries declared by the form. The installation's effective offering comes from its available catalog and can be smaller. It does not claim that an attached identity works outside its cloud or that every Worker has a driver installed. PostgreSQL appears in the interface; the generic connector registry is not the only PostgreSQL integration mechanism.

Interpreting authentication methods

The general authentication catalog also defines oracle_wallet, oci_resource_principal, web_identity and instance_profile. These are not independent options on this matrix's connection entries; their existence does not make them selectable for every connector. For Amazon S3, aws_iam covers the identity already attached to the runtime.

Variations that change preparation

In BigQuery, Database means Project ID and Schema means Dataset. Oracle presents Database as Service name. Databricks requires HTTP path and Catalog. Snowflake requests Database and Warehouse; Role and Schema complete the context. A database name, HTTP path and project identifier are not interchangeable even though each is text.

Salesforce starts with API version v65.0; it requires the My Domain URL and corresponding application and integration setup. Dynamics 365 requests Directory (tenant) ID and derives the scope from the environment. Odoo explicitly identifies its version 19-or-later JSON-2 API. SharePoint adds Site ID or a site-relative path. These differences belong to the connector contract rather than a generic SQL option.

The FTP / SFTP entry lets you select the protocol. SFTP starts on port 22; FTP and FTPS start on 21. SSH keys are unavailable for protocols other than SFTP. The TLS option follows the protocol: FTP does not mean an encrypted connection. Retain the transport policy required by your organization.

Custody and secure preparation

Dova Worker Agent keeps the secret in the customer's environment. Customer vault stores a reference to a secret in an external vault. Passwordless uses an execution identity without storing a reusable secret. Dova Vault is an exception mode with encrypted input that does not redisplay the value. Managed reference identifies existing managed references.

Reference providers recognized by the form include AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, CyberArk Conjur and Kubernetes Secret. Each validates its own reference format. A well-formed URI does not prove that the Worker can resolve it: check identity, network and vault authorization. Never replace a reference with its secret value in names, descriptions or evidence files.

Authentication choices depend on custody. Passwordless filters for methods marked as secretless; protected custody offers the relevant methods. When a combination has no valid methods, change custody or connector according to the design rather than forcing hidden form values.

Connectivity proof of concept and expected results

Prepare an isolated resource containing two synthetic records and a read-only identity. Create the connection in the test tenant, complete endpoint and metadata, choose custody and save. Run the connection check from the interface. Record connector, Worker, time and result without secret material. Then select the Connection in the corresponding source component and read only the test resource.

Expected results have two levels: the check confirms the conditions implemented by the connector; the read confirms object access and projection of its two records. A passed connection check does not approve a write. To evaluate a target, use a separate disposable resource, test the chosen write mode and compare keys, counts and contents. This sequence is a reproducible practice rather than a connectivity result already obtained in your environment.

Diagnosis and limitations

For authentication rejection, check method, identity, validity and permissions. For a missing object, verify catalog, database, schema or path. For a timeout, first check the Worker and its network access. For a missing write option, consult the connector's effective capabilities: a generic component does not guarantee every mode for every provider. A timeout does not prove incorrect credentials; do not copy responses that might contain source data.

Continue with Mapping components, transformations and permissions by action.

From design to execution

A Mapping transforms records through a component graph. Sources produce records; transformations project, enrich or validate them; targets write results. A Session associates the design with parameters, files and execution settings. A Workflow coordinates Sessions and decisions. This separation lets you change an input file or Worker without creating another design for every operational variation.

Built-in file components differ from components that require a compatible Worker. Database, API and Object storage declare the compatible_worker runtime; selecting a node does not automatically install drivers, grant permissions or create a connection. Read connectors and authentication before configuring them.

This reference lists the sources and targets in the Mapping catalog. Technical names identify configurations; the interface displays the labels in the first column. Listed options belong to the generic component. The connection and Worker can support a smaller subset.

Source catalog

Delimited files and JSON

Flat File input reads CSV, TSV and delimited text. Configure the actual delimiter and whether a header is present. Header row number is a physical position starting at one; distinguish an offset header from data rows that must be kept. Supply Field names when the file has no header. Header mapping relates positions or headings to logical fields and types. Encoding distinguishes UTF-8 from UTF-8 with BOM.

JSON input accepts a JSON array or JSON Lines. Record path locates the array inside a document; Field mapping projects nested paths into logical fields. Valid JSON can still have a structure incompatible with the expected collection. Start with a small document whose record count is known and confirm that projection returns the right fields.

Excel

Excel input offers automatic detection, XLSX, XLSM and XLS. Read sheets supports a single sheet, list, pattern, regular expression or all sheets. Include hidden sheets explicitly when required. Header row number, Data starts at row, Start column and End column define the region. Skip empty rows controls blank rows; Include sheet name preserves provenance in the configured field, initially _sheet_name.

Password protected indicates that the password is supplied at runtime; do not store it in the Mapping. Reading an XLSM workbook does not authorize macro execution. Before including all sheets, check that they share a structure. Notes or totals sheets can produce records outside the intended dataset.

Remote sources

Database input offers Table or view and a read-only SQL query. Select the connection, schema and object, or configure the query. Fetch size and Query timeout control operational behavior; they do not replace business filters. Selected fields provides explicit projection. Query an authorized resource and do not interpret a SQL field as universal dialect support.

API input declares GET, Resource path, Record path and Field mapping. Pagination can be None, Page number, Offset or Cursor. Page size, Retries and Timeout must match the service. A correct first page does not prove that the full collection was read: deliberately exceed one page in the acceptance test.

Object storage input selects a Connection and Object key. Its declared formats are CSV and JSON Lines. Selected fields and CSV delimiter complete the configuration. The object key is not a local browser path. Check the prefix and final resource to avoid reading a different file with a similar name.

Target catalog

Representation and writes

Flat File output specifies the name, delimiter, header, text qualifier, quoting policy, escape, line ending, encoding and null representation. These settings form the exchange contract. Record any consumer requirement for CRLF or BOM before comparing files. JSON output distinguishes an array from JSON Lines, offers readable formatting and controls whether null fields are retained.

Database output declares Append, Replace and Upsert; keys, table creation, batches, commit interval and timeout complete the configuration. Confirm that the effective connector supports the chosen mode. Test Replace only on a disposable table. Upsert requires correct keys; it does not generically repair historical duplicates.

API output declares POST, PUT and PATCH, Append or Upsert, keys and confirmation that the provider enforces uniqueness. Success status codes starts with 200, 201, 202 and 204. An external service can return 202 for asynchronous acceptance without confirming final processing. Evaluate retries together with target idempotency semantics.

Object storage output uses Conditional replace, requires an Idempotency key and offers Create only when absent, Expected ETag and Expected generation. These conditions protect write intent against object versions. Do not remove a precondition simply to turn a conflict into success: retrieve the expected state and decide whether the new write is still valid.

The current Mapping target catalog has no Excel output component. To deliver a file that Excel can open, use CSV with the appropriate encoding, delimiter and line ending. A CSV with BOM remains delimited text: it is not an XLSX workbook, has no sheets and does not preserve formulas or cell formatting.

File-contract proof of concept

Create a synthetic CSV with header id,name and two rows: 1,Ana and 2,Luis. Design Flat File input → Flat File output, set comma and header at both ends, and bind the input file to a Session. Run in an authorized test environment. Expect two records and two fields; quoting or line endings can differ if output settings change.

Repeat with JSON Lines containing two equivalent objects. Use JSON input and JSON output, select JSON Lines and check for two data lines. This second variant separates transport errors from representation errors. These steps describe a reproducible check; record the actual result before accepting the contract.

For a simple Mapping with a supported file, you can also start a manual execution from Mapping → Run and select the required input. A Session reuses bindings and operational settings; it is not universally required for that manual test. Inspect the actual attempt and download in Monitor.

Validation, failures and recovery

First review the graph structure, node connections and required fields. Then check logical names, types and parameters. If reading fails, preserve an equivalent synthetic sample and reduce the problem to one source and one target. If writing fails, identify partial effects before retrying; a failed Workflow does not prove that the destination remained unchanged.

Use Monitor to correlate execution and tasks, and Sessions to check files, profile and Worker. A small run validates structure and access, without proving capacity for arbitrary volumes. Increase the dataset gradually and maintain an independent expected count.

Record objectives and contracts

Built-in transformations operate on records received from their parents. An operation can change fields, values, row counts or ordering. Before connecting a target, define which properties must be preserved. Quality goes beyond a valid Mapping: a structurally correct graph can produce an incorrect business result if keys or join types do not represent the actual relationship.

The following catalog lists the Transform and Quality components. Identifiers recognize the configuration; labels are displayed to the user. The listed fields describe component contracts rather than an open programming language. For sources and targets, see Mapping components.

Complete catalog

Projection and enrichment

Field selector retains the chosen field list. Field mapper relates source names to target names; use it to establish an output schema recognized by the consumer. Check collisions before renaming: distinct concepts should not end up under one logical name.

Calculated field creates a field from a text template. ${customer} reads a column value and ${param.region} reads a parameter. Substitution produces text; it does not evaluate arithmetic or execute JavaScript or SQL. See expressions and variables to distinguish the template from a Workflow condition.

Convert type supports String, Integer, Number, Boolean, Date and Date and time. An empty Output field replaces the source field; a different name preserves the original. On conversion error can fail, set null, keep the original or use a default. Keeping originals can create a heterogeneous column: validate it before writing to a typed table.

Text cleanup

Clean text applies an ordered operation list: trim, collapse_whitespace, lower, upper and remove_accents. The default trims outer whitespace and collapses repeated spaces. Apply a consistent policy on both sides of a join key. Do not remove accents from a name that must legally be preserved merely to simplify comparison; create a separate normalized field when necessary.

Replace values distinguishes contains, exact, prefix and suffix matches; Case sensitive controls letter case. Split field divides on a delimiter and assigns Output fields, with options to retain the source and trim parts. Concatenate fields specifies a separator, output field and empty-value handling. These components are not arbitrary regular-expression interpreters.

Row counts, ordering and grouping

Row filter accepts Equals, Does not equal, Contains, Starts with, Ends with, greater/less comparisons with or without equality, and Is not empty. Its operators differ from Workflow decision operators. Convert numbers before comparing textual input and test boundary records exactly equal to the threshold.

Limit rows combines Maximum rows with Rows to skip. It provides a controlled window, but a sample does not validate the whole population. Row sort uses Field and Direction. Group aggregate groups by Group fields and computes Count, Sum or Average, with Value field and Output field as appropriate. Medians, percentiles and implicit multiple metrics are not part of this catalog.

Deduplicate configures Match fields. This is an identity rule: test records with equal keys but different other attributes. Confirm which record survives before using it for reconciliation; it does not imply an unmodeled “latest update” policy.

Joins

Join declares Inner, Left, Right and Full, left and right parents, keys and additional AND conditions. Key type can be automatic or explicit. Strategy offers Automatic hash, Hash and Sorted merge. Case sensitive, Trim strings and Match nulls alter key equivalence. Right collision prefix, initially right_, distinguishes repeated names.

Check uniqueness and cardinality before joining. Two matches on the left and three on the right can multiply records; that is not necessarily an engine defect. Prepare unmatched, uniquely matched, duplicate and null cases. A Left join preserves the intention to retain left records, but the exact count depends on the matches for each key.

Reshaping, sequences, fingerprints and ranking

Unpivot: columns to rows

Unpivot converts the columns listed in fields into records. Each record retains keepFields, writes the column name into keyField and its value into valueField. An empty Keep fields list retains the other input fields. Kept fields and value columns cannot overlap; output names must be distinct and must not collide with any input field.

For example, input {"region":"SUR","jan":10,"feb":null} with Value columns jan,feb, Keep fields region, Column name field month and Value field amount produces {"region":"SUR","month":"jan","amount":10} and {"region":"SUR","month":"feb","amount":null}. Drop null values removes only the second record: zero, false and empty text remain. Check the expected row increase; the in-memory execution of this operator rejects an output above 250000 records.

Run sequence: numbering one execution

Run sequence adds an integer to each record using start + index × step, with the first index equal to zero. Start 100 and Step 10 give three rows the values 100, 110 and 120. Step cannot be zero and the calculation must remain within the safe integer range of ±9007199254740991. The output field must not collide with an existing field.

The sequence restarts for each execution. It is not a global identifier, a persistent database sequence or a uniqueness guarantee across retries. If order gives the number its meaning, sort records first and document the tie-breaking criterion.

Field fingerprint: detecting changes in selected fields

Field fingerprint calculates SHA-256 from the names and typed values in fields and writes it to outputField, initially fingerprint. The calculation uses canonical JSON with sorted names and values that retain their types; null, empty text, and the string "1" versus the number 1 are distinct. Use a new output field. The fingerprint compares versions of selected attributes; it does not encrypt or anonymize data.

To compare two customer extracts, select the same business fields, normalize text before calculating the fingerprint and match records by an independent customer key. Exclude extraction timestamps that change on every run when they do not represent business changes. Do not substitute a fingerprint for access controls or treat it as proof of an external file's authenticity.

Partition rank: positions within groups

Partition rank ranks numeric field within each partitionBy group; an empty list ranks the entire input. Direction is ascending or descending. For amounts 100,100,80 in descending order, Dense rank produces 1,1,2; Rank with gaps produces 1,1,3; Row number produces 1,2,3. Row number ties follow input order.

The component adds ranks while preserving the original row order; add Row sort to present results in rank order. It accepts finite numbers and their valid textual representations, while rejecting nulls, empty values and booleans. It requires staged sorting; it does not make arbitrary graphs use constant memory. Test separate partitions, ties and an invalid value before accepting the output.

Quality rules

Default value fills a null field, an empty field or both, according to Apply when. Quality check controls maximum null percentage. Required fields checks completeness of a list. Type check validates the declared type and can allow empty values. Pattern check applies a pattern. Range check defines minimum, maximum and boundary inclusion. Allowed values restricts the domain and offers case sensitivity.

Percentages are acceptance thresholds; they do not describe an automatic quarantine output. Do not describe a rule as separating valid and invalid records unless the design implements that separation. Set zero when no violation is acceptable and test with a known invalid row.

Synthetic cleanup and control exercise

Prepare a CSV with id,name,amount: two valid records and a third with an empty amount. Connect Flat File input → Clean text on name → Convert type on amount → Required fields on id and amount → Flat File output. Use trim and upper; select Set null on conversion and zero Maximum invalid percent on quality.

Expect a quality failure caused by the third record; do not accept that run as a successful load. Correct the synthetic input, repeat and verify three records, normalized names and numeric amounts compatible with the output. For a remote target, use a disposable resource and check partial effects before retrying.

Extend the exercise with another source containing two keys and a description, add Join and check the expected result manually. Record before/after counts, unmatched keys and duplicates. This is an acceptance exercise to run in your environment; it does not establish that a real target has already been validated.

Three distinct mechanisms

Dova separates Mapping field templates, typed execution parameters and Workflow JSON conditions. Each mechanism has its own syntax and scope. A ${field} template is not a decision condition; a JSON boolean is not the string "true"; a secret parameter is a protected reference rather than a password to interpolate into a file.

Use parameters for environment or task variations that do not change the process structure. Use Workflow variables when the orchestration definition includes them. Use conditions to select branches from available values or states. Sessions explains where values are edited; Workflows explains their relationship to tasks.

Parameter definitions

Each definition accepts name, type, description, required, sensitive, overridable, scopes, default, enum, minimum, maximum and maxLength. The contract accepts up to 100 definitions with unique names. A name begins with a letter, has at most 64 characters and can contain letters, numbers, underscores, dots and hyphens. The prefixes sys. and dova. are reserved.

Description is limited to 300 characters. Max length accepts values from 1 to 32768. Minimum cannot exceed Maximum. Enum must contain 1–50 candidates, is normalized according to the type and is unavailable for JSON or Secret. A Sensitive parameter must use Secret: labeling an ordinary string does not turn it into a protected secret.

Secret references recognize the gcp-secret, aws-secretsmanager, azure-keyvault, vault and worker-secret schemes. This syntax belongs to orchestration parameters; do not mechanically mix it with provider-specific Customer vault reference forms in Connections. Resolving a reference requires the corresponding infrastructure and authorization.

Layers and precedence

A later layer replaces an earlier value within the validation rules. Scopes restricts accepted layers and Overridable participates in override control. Required demands a value after defaults and layers have been resolved. The result retains value provenance, allowing diagnosis when the designer's expected value was not applied.

For example, define REGION as String with default NORTE. An Environment layer setting SUR should override that default; a permitted Task layer setting CENTRO should override both. Do not remove scope restrictions to bypass an error without checking who has authority over that configuration.

Calculated field templates

The template recognizes ${nombre} for record fields and ${param.nombre} for parameters. Substitution produces text limited to 4000 characters. A recognized but missing identifier is replaced with an empty string. Field names are looked up as record keys; a dot in the name does not guarantee nested object traversal.

With a row containing name = Ana and parameter region = SUR, the template Cliente ${name} / ${param.region} produces Cliente Ana / SUR. The expression ${amount} * 2 produces text containing * 2; it does not multiply. Use the appropriate transformation components rather than inserting code in expectation of dynamic evaluation.

The parameterized-value helper recognizes a complete ${param.nombre} reference. This does not imply partial interpolation in every field of every connector. Confirm the particular component contract before moving a template from one field to another.

Workflow JSON conditions

A simple condition contains ref, op and, except for two operators, value. Supported references are parameters.nombre, variables.nombre, tasks.identificador.status and tasks.identificador.outputs.nombre. They do not allow arbitrary server-property access or executable code.

When a reference does not exist, ordinary comparisons return false. Exists distinguishes absence from an existing but empty value. In and Not in require the expected value to be a list. Numbers must remain JSON numbers; comparisons do not promise automatic conversion from text.

The all and any groups combine 1–20 expressions; not negates one expression. Depths greater than five and trees with more than 40 nodes are rejected. A comparison value is limited to 4096 bytes. These limits encourage reviewable conditions; split overly complex decisions into clear tasks.

{
  "all": [
    {"ref": "parameters.RUN_MODE", "op": "eq", "value": "full"},
    {"ref": "tasks.load.status", "op": "eq", "value": "succeeded"}
  ]
}

The load reference must match an actual task identifier. Outputs can only be queried when present in context. This example does not declare a universal count output or assume connector field names.

Decisions and states

Task types are Start, Session, Decision, Timer and End. Links support Success, Failure, Always and Expression. A decision needs complementary True and False branches: one expression and its direct negation. The interface constructs the false branch as not of the true branch; do not write independent conditions that could both be true or both be false.

Recognized terminal states include Succeeded, Failed, Skipped, Cancelled and Terminated. Ready, Queued, Running, Waiting and Retry wait are active states. Task readiness considers terminal parents and the join policy. Always does not permit a task to ignore every orchestration requirement.

Proof of concept and diagnosis

Prepare a synthetic Workflow with a Session that processes two rows, a Decision and two end branches. Define RUN_MODE as String with allowed values full and sample. Use an equality condition on parameters.RUN_MODE, run first with full, then with sample, and verify that the active branch changes while the branches remain complementary.

Then test a value outside Enum and a boolean where String is required. Expect validation rejection rather than silent conversion. Run in an authorized environment and record the observed result. If a branch does not activate, check JSON type, technical name, effective layer, parent state and reference existence before changing the logic.

Interpreting authorization

Authorization depends on the authenticated user, active tenant, active role, effective permissions and resource restrictions. Showing a module is a navigation decision; performing an action requires its corresponding check. A user assigned several roles should not assume that all privileges apply simultaneously without selecting the right context.

Subscription and resource eligibility also matter. Run permission does not guarantee an available Worker, plan capacity or connection access. An inactive subscription's read-only response is not resolved by indiscriminately adding permissions. This reference describes catalog permissions and the route/action correspondence; additional resource checks remain mandatory.

Dova matrix

Configuration can appear when any read permission for Configuration, Runtime or Scheduler is present. Its tabs apply specific rules. This alternative does not grant the other permissions: permission to view schedules does not authorize changes to execution policies.

Domain reads can also support Mappings, Sessions, Workflows and Connections selectors with their respective read permissions. Do not confuse this auxiliary read with permission to create folders. Similarly, edit-lock reads accept artifact-type read permissions; lock mutations require manage permissions and resource checks.

Administrator matrix

Both Registrations permissions are declared platform-only. Management of the global commercial catalog and tenant offers also checks the active platform role together with billing.manage. A tenant billing role does not authorize changes to global products.

Built-in roles

These are built-in sets, not a claim that every organization retains identical assignments. Review custom roles and effective assignments in Roles & permissions. Do not treat browser role compatibility as authority: the server obtains and verifies session permissions.

Public Trial includes read and manage for Domains, Mappings, Sessions, Workflows and Connections; Workflow execution; Monitor read; Runtime read and manage; and Billing and Overview read. Its list excludes Scheduler management, Monitor management and Workflow termination. Access validity and tenant isolation remain independent conditions.

From module name to operation

The interface calls Session orchestration Workflows. Orchestration routes use etl.workflows.* permissions. Historical routes named workflows can represent Mapping design and use etl.mappings.*, except for the specific run action. When integrating or auditing, check the action contract; inferring permissions from one URL word can produce an incorrect conclusion.

When a route declares alternative permissions, any listed permission satisfies that initial check. More specific artifact, tenant, subscription or state validation can follow. A permission matrix neither bypasses these checks nor promises a stable public API.

Least-privilege proof of concept

In a laboratory tenant, prepare a Mapping, Session and Workflow using two synthetic rows. Assign an account a read role equivalent to ETL Viewer. Check that it can open permitted modules and read the design but cannot save changes or start a run. Use that account's session rather than reusing administrative credentials.

Switch to the authorized operator role and verify that it can run the Workflow and read Monitor without gaining design management solely through that assignment. Then use a developer role to edit and validate the design; separately check its termination and Monitor-management restrictions. Record each action, context and result without copying tokens or personal data.

Expect a reproducible separation between reading, designing and operating. Execute this check in the organization's environment; this reference does not claim that a particular account's assignments have already been verified. If an action fails, first check the active tenant and role, then effective permission, subscription and resource state. Do not answer every rejection by assigning the platform wildcard.

Navigation and audit

Read account to understand context switching and Repository to distinguish structure from artifacts. After sensitive changes, review the available audit trail and confirm that the result belongs to the correct tenant. A hidden button improves navigation, while effective access control remains on the server.

Scope of this edition

This manual describes Dova 22.0.5 capabilities. Check the version reported by your environment before following a procedure: a documentation version or downloaded file does not establish which code is active in your installation. Accepting a change requires checking its result as well as its version label. Use a separate laboratory destination for the following checks.

Navigation and canvas

The editor reduces repeated work through a bounded geometry snapshot and coordination of visual updates. This optimization concerns canvas presentation; it does not turn API documents, execution results or tenant data into a shared cache. It does not change the meaning of saving, publishing or executing.

To check it, open a laboratory Mapping, select components, move them, connect ports and resize panels. Inspect connection alignment, selection, the inspector and maximized behavior. Undo and redo must retain the expected edit. Responsiveness depends on the graph, device and workload; no universal duration is promised, and extra memory does not replace CPU work.

DovaAI and assisted design

DovaAI uses the authorized tenant and current view internally. Language follows the conversation and history continues across module changes within the permitted context. The chat supports a compact presentation and window controls; guides identify concrete actions with brief messages.

The assistant knows the purpose and settings of the 36 current components. For example, to replace exactly jorge with Jorge, it can recommend Replace values with exact matching; this does not capitalize every possible name. Field selector retains only selected fields in both rows and schema.

You can attach a supported file and describe a goal to prepare a configured Mapping. Design context uses schema metadata rather than providing a permanent execution input. Review components, connections, settings and missing information before confirming creation. Creating a draft neither publishes nor executes it. Plan quotas and authorization checks remain in force.

Retain operational controls

Mapping, Session and Workflow retain separate purposes: transformation, execution context and orchestration. Save and publish their versions deliberately; inspect dependencies before updating consumers. A public worker shares capacity rather than access to other tenants' Sessions or data. Successful publication does not itself prove output correctness.

Acceptance checklist

1. Confirm version, tenant, role and location.
2. Test the canvas with synthetic data and verify the saved edit after reloading.
3. Ask DovaAI for a concrete recommendation and review its proposal before applying it.
4. Run a controlled attempt and compare Monitor, schema and expected output.
5. If something fails, keep authorized evidence and inspect state before repeating actions with external effects.

Verified reference for 22.0.5

This edition uses Dova 22.0.5 as its reference. Inspection of the active product confirms the 36 Mapping catalog components and the Start, Session, Decision, Timer and End tasks. Consult the transformation reference for Unpivot, Sequence, Hash fields and Rank, including fields, failure conditions and examples. Review an assistant proposal like any other draft before publishing or executing it.

Configuration contains Runtime, Execution profiles, Workflow Scheduler, Runtime health and Git / DevOps. Available actions depend on your permissions and configuration. For cloud workers, VM state and agent Runtime are separate checks: a started VM does not establish eligibility or successful execution.

Follow the Session and Workflow laboratory to learn the complete chain. Its synthetic data contains four input records and three expected results with column and value checks. The normalization demonstration also explains the genuine CSV chain with 18 input and 10 output records. Historical examples retain their original identification; they are not new runs in your environment.