The operational problem
A process does not deliver the expected file and the team only knows it “failed.” Without identifying the attempt, task and context, it is easy to inspect a different draft from the version that ran or repeat a load without knowing what was written.
The opposite happens too: a process reports success, but nobody has verified the destination’s rows and values. Technical tracking and data acceptance need separate checks.
How Dova helps
Dova Monitor lets you inspect execution attempts, their states and the available operational detail. The list and its filters help locate a Workflow in the relevant period; task information and logs help investigate where a problem occurred.
Each attempt has its own context and an identifier distinguishing runs of the same Workflow. Reviewing that history helps organize the diagnosis and share incident evidence. Final verification still includes the destination file or table.
How it works
Find the correct attempt
Filter by Workflow, state and the available period. Check the history-window unit and record the identifier before comparing executions.
Review state and tasks
Open the available detail or operational log. Identify the first relevant failing task and distinguish a pending process from a completed one.
Relate the error to its context
Check the associated Mapping, Session and worker. An inaccessible path, missing permission and insufficient capacity require different corrections.
Check destination effects
Inspect the affected file or table before repeating the run. An error state does not prove there were no partial writes.
Record the correction and new attempt
Keep the identifier, time and diagnosis without secrets. After correcting and publishing where needed, make an authorized attempt and compare its result.
What you need
- Permission to inspect executions in the active tenant and authorized access to the Workflow you are investigating.
- An identifier, period or process name that helps locate the attempt and its context.
- Authorized destination access to verify rows and values; separate execution permission if you need to repeat the load.
Limits to consider
- Success reported by the engine does not alone prove that the result meets the business rule. Verify destination contents.
- History windows and log preservation depend on configuration and maintenance. Unlimited retention and certified auditing are not promised.
- Inspecting Monitor does not correct a Mapping or automatically recover an external destination. Cancellation and recovery actions depend on state, permissions and effective capabilities.
Demonstration example
Illustrative example using synthetic data. This is not a customer result or a product screenshot.
Demonstration: compare a failure with a corrected attempt
In a laboratory Session, use a nonexistent input path and inspect the reported error. Correct the path and run again with a separate destination. Keep both identifiers and verify the second attempt’s output. This is a proposed test sequence, not a customer incident.
Attempt A → inaccessible test source
→ inspect task and message
Attempt B → corrected path
→ inspect state and output contents