Publishing and dependency versions

Prepare the Mapping → Session → Workflow chain while distinguishing drafts, published versions and execution results.

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

Action	What to check
`Save draft`	Editable changes are saved. This provides no evidence of a new execution.
`Validate`	The definition satisfies that object’s checks. It does not test connectivity or final data.
`Publish`	The version becomes available to authorized consumers. Inspect its selected dependencies.
`Run`	Creates an attempt with execution context. Inspect the subsequent state and actual result.

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

Open the Mapping and inspect its source, transformations, target and schema. Validate and save the draft.
Publish the Mapping and record the version selected for the laboratory.
Open the Session and check its Mapping reference, version and input/output bindings. Validate and publish the Session.
Open the Workflow. For each Session task, inspect Reusable session and the consumed version. Review dependency notices.
Validate links and conditions, save the draft and publish the Workflow.
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.