An inherited Celigo account should be understandable before it is changed. A successful flow run does not prove that every order arrived, and an empty error list does not prove that the business records reconcile. An audit should establish what the account does, where the risks are and which findings require action.
This guide describes an audit method, not a customer incident or a promise of results. The examples are illustrative. The scope, access and evidence available in your account determine what can be concluded.
Start with the business process
Choose the processes that matter to the business: order acceptance, available stock, fulfilment, customer matching or financial reconciliation. Identify the source record, expected destination state and person responsible for checking the result. Record whether the concern is a missing record, an incorrect value, a delay or a process nobody can explain.
Agree the account and environments in scope. Record any systems, histories or permissions that will not be available. A review with limited access should explicitly describe its coverage rather than imply that the whole estate has been verified.
Map the account and its dependencies
Inventory integrations, flows, connections, exports, imports, scripts, lookups and schedules used by the agreed processes. Trace routes and branches rather than judging complexity from the top-level flow list. Record shared resources, downstream consumers and dependencies outside Celigo.
For each flow, document its purpose, trigger, record identifiers, mapping rules and expected completion state. Check what happens to cancelled records and records updated while an earlier version is still being processed. The inventory should explain the operating process, not just list resource names.
Review access and ownership
Identify which function owns each connection and where credentials are managed. Review permissions against the operations the connection needs. Record renewal or expiry responsibilities and a handover path if the original administrator is unavailable.
An initial review can usually begin with agreed read access. Any request for broader access should have a stated purpose. Keep credentials and customer payloads out of presentation decks, ordinary tickets and enquiry forms. Use synthetic records for reusable examples.
Trace failures and prove recovery
Celigo provides error investigation and retry features, but retained retry data is subject to product and account limits. Check the current configuration and available history. Distinguish a record successfully written after retry from an error manually marked resolved; the destination record is the evidence that matters.
Classify a failure before replaying it. A temporary connection problem, missing reference data and an invalid mapping need different responses. For a write that timed out, first check whether the destination committed it. Replaying an uncertain write without that check can duplicate a business transaction.
Define a durable source reference and a safe way to recognise a transaction already accepted. Agree which system supplies the authoritative version during recovery. A stale retry must not overwrite a later correction. Where manual intervention is necessary, record the decision and the operator responsible.
Check monitoring beyond the error count
Confirm that alerts reach a monitored channel and that someone can act on them within the agreed support arrangement. Review silent failure conditions: a schedule not running, a source query returning no records, a filter excluding valid work or a destination accepting a record with the wrong business value.
Use reconciliation to complement run monitoring. Compare the expected population of source records with the destination for a consistent period. Investigate missing references and unexpected duplicates. For inventory, check the age and ownership of the value as well as whether a request succeeded.
What a useful audit finding looks like
Illustrative finding: an order import uses a create operation, and the evidence does not show a durable duplicate check. Risk: a timeout followed by replay could create another order. This is a risk to test, not proof that a duplicate has occurred.
Proposed validation: in an appropriate test environment, submit an approved synthetic order, interrupt the acknowledgement path and replay the same business operation. Confirm the resulting record count and destination reference. Remediation should depend on the observed behaviour and the API or connector capabilities.
The finding register should distinguish confirmed defects, untested risks and documentation gaps. Each item needs its evidence, business consequence, proposed action, owner, dependencies and acceptance check. Avoid a score that suggests precision the evidence cannot support.
Turn the review into an operating plan
Prioritise work by customer impact, financial risk, likelihood and ability to recover. Agree backups or configuration exports, a test environment, release approval and rollback conditions before changing production. Separate repairs from optional platform redesign.
An ongoing support agreement should identify the covered flows, hours of coverage, severity definitions and escalation contacts. Automated retries are not an after-hours support commitment. Keep vendor issues, ERP configuration issues and integration defects distinguishable so each has a useful escalation path.
What to bring to the first conversation
Bring the connected systems, an outline of the business process, known symptoms and the references you can safely share. Note who has access and which environments are available. We can then agree whether the next step is an account audit, incident investigation or a scoped integration change.
Discuss a Celigo account audit or support arrangement