Connected business systems supported by a Celigo maintenance routine
Integration•8 min read

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.

WhenTaskSuggested ownerEvidence to keep
DailyReview runs, aged errors, and urgent missing recordsSupport ownerOpen issues and next actions
WeeklyReview repeat errors and compare source and destination dataTechnical and business ownersSample IDs and explained differences
MonthlyReview access, credentials, capacity, and support notesIntegration administratorAccess decisions and planned fixes
Before each releaseTest mappings, connections, and recovery stepsChange ownerTest results and approval
After each incidentConfirm recovery and prevent the same failureIncident ownerCause, 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.

Six-step recovery flow
  1. 1. Identify impactFind the affected flow, records, and deadline.
  2. 2. Check destinationLook for records already created or updated.
  3. 3. Fix the causeCorrect data, access, or the failing dependency.
  4. 4. Test a safe retryUse one record with a confirmed matching rule.
  5. 5. Replay in batchesWatch results and stop if new failures appear.
  6. 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.

  1. Celigo Help Center: Monitor flows, APIs, and tools in an integration.
  2. Microsoft Azure Architecture Center: Retry pattern.
  3. Oracle NetSuite Help: Web Services and RESTlet Concurrency Governance.
  4. OWASP: Secrets Management Cheat Sheet.
  5. Google SRE: Monitoring Distributed Systems.

Build a Celigo Maintenance Plan Your Team Can Run

We can review your flows, prioritize recurring issues, and help document a practical support and recovery routine.

Frequently Asked Questions

Practical answers for teams maintaining Celigo integrations.

What should a Celigo integration maintenance checklist cover?

Cover flow runs, overdue records, error ownership, data checks, credentials, capacity, change testing, and recovery steps. Give each task an owner and keep evidence of completion.

How often should we check Celigo integrations?

Use daily checks for critical flows, weekly reviews for repeat errors and data samples, and monthly reviews for access and capacity. Adjust the cadence to your business deadlines and check again after each material change.

Does a successful flow mean all business data is correct?

No. Confirm that expected records reached the destination and that key values match. Review filters, skipped records, and downstream steps before calling a process complete.

Should we retry every failed record?

No. Find the cause and check whether the destination already accepted the record. Correct data or access problems first. Retry a small, safe sample before replaying a larger group.

Who should own Celigo maintenance?

Name a technical owner, a business owner, and a trained backup. The technical owner manages flows and recovery. The business owner confirms data accuracy and business impact.

When should integration credentials be rotated?

Follow your security policy and the connected service’s rules. Track expiry where it applies, test replacement credentials, and revoke old secrets after the switch. Respond promptly to suspected exposure.

What should we test after a mapping or application change?

Test a normal record, missing data, an update, a safe replay, and relevant business exceptions in a non-production setup. Confirm destination values and downstream results before approving the change.

What evidence should we save after maintenance?

Record the date, owner, flow or connection, issue, approved change, test record IDs, and outcome. Store evidence in an access-controlled location and keep secrets and unnecessary personal data out of the log.