Prepared with AI assistance and reviewed for clarity, relevance and unsupported claims.
Workflow reconciliation checks answer a question that error alerts cannot: did every eligible source record produce the expected business outcome? An automation may report no errors because a request never triggered it. It may also complete successfully while skipping a task through an unintended filter.
For a Moroccan service SME, that can mean an enquiry remains in a form’s records while nobody sees it in the team’s task queue. The solution is a separate completeness check, not simply more alerts about executions that already exist.
1. Define what should exist on both sides
Start with one business promise. For example: every eligible quote enquiry saved by the form should have one traceable follow-up task, unless it has an approved exclusion reason.
In a hypothetical office maintenance business, test submissions and enquiries withdrawn before routing are excluded. All other saved enquiries require a task, even when the details are incomplete. Missing details should create a review task rather than make the enquiry disappear.
- Source: the form’s saved enquiry records.
- Eligibility: genuine submissions within the chosen review period.
- Expected output: a task linked to the enquiry’s stable identifier.
- Permitted delay: a business-defined interval before an absent task becomes an exception.
- Exclusions: explicit reasons recorded with an owner or rule.
- Evidence: source and destination references, not just an execution success label.
Clarify these rules with the staff responsible for follow-up. The guide to workflow triggers and states can help separate “submitted”, “eligible” and “task created”.
2. Compare identities, not only totals
Matching counts can conceal a missing item. If one enquiry produced two tasks and another produced none, the overall totals may still agree. Reconciliation should compare individual source identifiers with destination references.
Prefer a stable identifier created by the source and carried into the task. Names and phone numbers alone are poor substitutes: the same person can send separate legitimate enquiries, and contact details can be entered inconsistently.
For each eligible source record, check whether the expected linked task exists. Where useful, also check for several tasks linked to one enquiry and tasks that no longer have a valid source reference.
A task’s absence from the active view does not prove it was never created. It may be completed, archived or hidden by a filter. Include relevant states in the comparison, subject to the destination’s available records and access permissions.
The reconciliation boundary matters. Comparing saved form records with tasks cannot discover a submission that the form never saved. That requires a separate intake check or investigation of the submission path.
3. Use a review window that allows normal delays
Checking immediately after submission can turn ordinary processing time into false alarms. Choose a grace period based on your intended workflow behaviour, then compare records old enough to have reached their expected destination.
Use a clear business time zone and record timestamps consistently. Avoid a fragile check that examines only records created since the last successful run. Late arrivals, interrupted checks and updates can fall through such a boundary.
An overlapping lookback window can catch late changes. Keep a record of existing exceptions so overlap does not generate a fresh alert for the same missing task every time. For larger datasets, combine frequent recent checks with a broader periodic review that is feasible for the team.
Frequent checks shorten the time before discovery but use resources and can create noise. Less frequent checks are simpler, but the business must accept the longer delay. Choose the cadence from the consequence of a missed enquiry, not an arbitrary technical schedule.
4. Give each mismatch a useful status and owner
A mismatch is a reason to investigate, not proof that replaying the automation is safe. Use a small set of exception states:
- Waiting: still within the allowed processing window.
- Missing: expected output absent after that window.
- Ambiguous: a possible match exists without a reliable source link.
- Duplicate: more outputs exist than the rule allows.
- Resolved or excluded: outcome verified and reason recorded.
Assign a primary owner and backup. Include the source reference, expected output, age, check time and next action. Link to authorised records instead of copying full customer details into every alert.
Hypothetical exception note: “Enquiry FORM-218 is saved and eligible. No linked task was found in active or completed records. The operations coordinator will check manual follow-up before creating a recovery task.”
This is more actionable than “workflow discrepancy detected”, because it identifies the work and who must decide.
5. Recover the missing work without replaying everything
For the hypothetical enquiry, the coordinator first checks whether a colleague already handled it manually. They then inspect whether a task was created without the source reference or whether an execution remains in progress.
- Confirm that the source record still requires follow-up.
- Search for completed, manual or partially created outcomes.
- Claim the exception for one recovery owner.
- Create only the missing action through an approved recovery path.
- Record the resulting task reference and verify the link.
Where recovery can race with normal processing, use a shared duplicate-prevention control rather than relying on staff timing. Replaying the whole workflow might resend an acknowledgement that already went out. Recover the missing task separately when possible.
The same reasoning applies to recognising duplicate customer requests: identity and prior actions matter more than superficial similarity.
6. Check the checker and improve the underlying process
A reconciliation process can also stop running. Record its last successful comparison, the period covered and whether both source and destination were accessible. A failed comparison must not be reported as “no missing records”.
Test the check with a deliberately unmatched synthetic record in an isolated setting. Confirm that an exception appears, reaches its owner and can be resolved. Record the procedure in the operations runbook.
Review repeated causes separately: trigger gaps, wrong exclusions and missing source references require different fixes. If you want to define this completeness check for your enquiry process, you can discuss it with FlowAgent within a scoped custom n8n automation project.