Celigo Integration Maintenance Checklist
Keep Maintenance Small, Regular, and Owned
Your orders, stock levels, and invoices depend on more than a flow being switched on. A useful maintenance routine checks whether records arrive on time, whether the values are right, and whether someone can recover a failed run.
We conducted a review of published guidance from Celigo, Oracle, Microsoft, OWASP, and Google to build this checklist. Our analysis turns that guidance into suggested operating tasks. The timing below is a starting point for your team, not a Celigo service guarantee or a report of live customer testing.
Daily: Check the Work That Matters Today
Celigo documents flow status, error details, and actions for reviewing and retrying errors in its integration view. It also notes that marking an error resolved removes it from the queue even if the underlying issue has not been fixed. [1] Use those tools to investigate the business result before closing an issue.
- Check expected runs: compare each critical flow’s latest activity with its schedule and business deadline. Investigate a flow that has stopped producing expected records.
- Review open errors: assign an owner and a next action. Prioritize blocked shipments, missing invoices, and stale inventory by impact and age.
- Check arrivals: sample destination records against source IDs. Confirm amounts, quantities, status, and the expected location or subsidiary.
- Check alert coverage: confirm the primary and backup contacts can receive the alerts your team relies on. Test delivery after a routing or staffing change.
- Leave a handoff: record what is still open, who is handling it, and when the next update is due.
For example, a completed order flow does not answer whether every order needed for today’s shipping cutoff is ready in NetSuite. Compare the source order list with the destination list for the same time window. Account for filters and expected delays before treating a difference as a failure.
Set a Cadence Your Team Can Keep
Use this table as a maintenance calendar. Shorten the interval for time-sensitive processes. A quiet reporting flow may need a different schedule from inventory updates used by an online store.
| When | Task | Suggested owner | Evidence to keep |
|---|---|---|---|
| Daily | Review runs, aged errors, and urgent missing records | Support owner | Open issues and next actions |
| Weekly | Review repeat errors and compare source and destination data | Technical and business owners | Sample IDs and explained differences |
| Monthly | Review access, credentials, capacity, and support notes | Integration administrator | Access decisions and planned fixes |
| Before each release | Test mappings, connections, and recovery steps | Change owner | Test results and approval |
| After each incident | Confirm recovery and prevent the same failure | Incident owner | Cause, fix, and follow-up task |
Weekly: Fix Repeat Problems at the Source
Group recurring failures by cause. A missing item, an expired credential, and a busy API need different fixes. Keep a short list of the most common issues and assign work to remove the cause. Avoid spending every week clearing the same queue.
Compare source and destination counts for a defined window. Then inspect a sample of record values. Equal counts alone cannot show whether the right customer, currency, tax code, or warehouse was used. Include at least one changed record and one business exception relevant to your process.
Keep mapping notes beside the flow documentation. Record who owns each field, which system is the source of truth, and how blank values should behave. If the data rules need work, use our guide to optimizing Celigo data mapping.
Use a Safe Recovery Path
Microsoft’s retry guidance warns that a request can succeed at the destination even when its response is lost. Repeating a non-idempotent operation can create an unwanted second effect. It also recommends choosing retry behavior based on the failure. [2] Check the destination before replaying an order, payment, or shipment.
- 1. Identify impactFind the affected flow, records, and deadline.
- 2. Check destinationLook for records already created or updated.
- 3. Fix the causeCorrect data, access, or the failing dependency.
- 4. Test a safe retryUse one record with a confirmed matching rule.
- 5. Replay in batchesWatch results and stop if new failures appear.
- 6. Reconcile and closeConfirm the business result and save evidence.
If you cannot confirm that replay is safe, stop at the destination check and ask the technical owner to review the matching logic. This workflow is a suggested runbook, not a claim that Celigo automatically performs every step. See our duplicate prevention guide for a closer look at record identity.
Monthly: Review Capacity and Access
Oracle states that NetSuite’s account concurrency limit covers web services and RESTlet requests together. [3] Review overlapping jobs and other integrations before raising Celigo concurrency. Keep a record of busy periods, rejected requests, and completion times so you can judge whether a schedule change helped.
Google’s SRE guidance uses four monitoring signals: latency, traffic, errors, and saturation. [5] For this checklist, we suggest tracking delivery delay, record volume, failed records, and signs of a growing backlog. These are operating measures to assemble from the available systems; they are not a promise of a single built-in Celigo report.
- Review people: remove access that is no longer needed and check who can change production flows.
- Review connection owners: give every connection a current owner and backup. Track expiry dates where the provider uses them.
- Review secret handling: keep tokens out of tickets, screenshots, source files, and shared runbooks.
- Review capacity: compare run times and backlog age with your agreed business deadlines.
- Review documentation: update schedules, field rules, dependencies, alert contacts, and recovery instructions.
OWASP recommends limited access to secrets and lifecycle controls that cover rotation, revocation, and expiry. [4] Apply your security policy and the connected provider’s rules when planning credential changes. Test the new connection, watch the first run, and retire the old secret after the switch is confirmed.
Before a Release: Prove the Business Path Still Works
Treat changes to custom fields, saved searches, scripts, roles, and connected applications as reasons to review the affected flows. Read the relevant release notes and identify the paths that might change. Save the current configuration through your approved process and write down how to restore it.
In a suitable non-production setup, test a normal record, a missing field, an update to an existing record, and a safe replay. Add cases for your actual process, such as a partial fulfillment, refund, or multi-currency order. Check the destination values and any later steps that depend on them.
Choose a release window with a named owner available. Record approval, the expected result, and a clear stop condition. If a mapping sends the wrong values, pause the affected work and assess the records already changed. Restoring a configuration does not undo records that have already reached another system.
Close Maintenance With Evidence
Keep a simple maintenance log with the date, owner, flow, finding, action, and result. Add sample record IDs and the next review date. Store logs under suitable access controls and avoid copying unnecessary customer data.
Ask the backup owner to walk through a recovery scenario using the runbook. Update any step that depends on unwritten knowledge. If ownership or the flow design is unclear, start with an audit of the existing Celigo integration before expanding the maintenance plan.
References
The checklist draws on these primary sources. Cadence, ownership, and sample checks are our practical recommendations.
