Managing Integrations

An integration is a first-class Celigo resource that represents a named group of related resources -- flows, APIs, Tools, registered connections, scripts, settings, notification subscriptions, aliases, and revision history. It is the organizational layer that says "this body of automation goes together," typically because it serves a specific business purpose (the "Shopify-NetSuite integration", the "customer-onboarding integration"). The actual work is done by the resources inside; the integration coordinates how they are managed, deployed, and evolved.

Users may call integrations tiles, workspaces, or integration folders -- treat these as equivalent vocabulary for the same resource type.

Concerns when managing integrations:

• Organization and access -- grouping related work so it can be named, permissioned, and reported on as a unit. The integration boundary is the permission boundary.
• Plain vs Integration App -- customer-built integrations you own end to end, vs template-driven apps installed from the Marketplace.
• Hierarchy -- parent/child integrations for multi-store, multi-tenant, or per-environment splits.
• Lifecycle and promotion -- cloning across environments and running the ILM workflow (snapshots, pulls, reverts) to evolve integrations safely.
• Composition -- what lives inside, and how to move a resource from one integration to another.
• Per-integration knobs -- notifications, aliases, analytics, and settings that live on the integration record itself.

What Lives Inside an Integration