Deploying

Choose Production or a named preview in the workflow editor and complete its AIMS request. The eligible reviewer's Approve and enable action also publishes when all requirements pass. Check that the destination shows On and the expected deployed version; a second deploy is unnecessary. If authorization was saved but publication was blocked, resolve the displayed requirement and use Retry enabling. Deploy version in the editor also checks an already approved version before publishing it.

Publication activates that destination's real triggers and fixes its version, connections and approved dependencies. Several destinations can stay on at once; each shows its deployed version and an on/off switch. Open Workflows → Active deployments to find them across workflows.

Testing a candidate does not replace an active deployment. If Production runs v1 while a preview runs v2, Production keeps v1 until an explicit promotion succeeds. Previews use shared infrastructure with separate execution identities; they do not require a workspace Staging or QA environment.

Under Connections for this destination, each selector lists only compatible workspace credentials, including the OAuth permissions required by its blocks. Use Add credential beside a field to open that provider's credential dialog. A new connection saved and tested there is selected for the destination; choose Save connection choices to record it. After an OAuth redirect, select the connected account on return. If a saved connection is unavailable or incompatible, replace it before saving.

The destination's Executions button opens the execution panel, selects its Executions tab and brings it into view. The list stays filtered to the selected destination.

From a deployed preview, choose Promote to production. Review Production's connections and complete its AIMS and Git requirements. The promotion stops the source preview by default; you can choose to keep both on. A failed check leaves the current deployments unchanged.

When adding a signed event source, keep its setup dialog open until configuration completes. Copy the returned URL and one-time signing secret to your provider, then select I saved the URL and signing secret. The dialog prevents accidental dismissal while configuring or displaying the secret.

Deploy checklist

Before a workflow can deploy, it must pass validation and a deployment readiness check. Confluye walks the workflow (and any sub-workflows) and blocks the deploy if anything required is missing, grouped into categories:

The readiness panel lists concrete setup actions to resolve each item. Structural problems (dangling edges, unreachable nodes, no reachable output, invalid branch labels) are surfaced by validation on the canvas.

Live workflows and triggers

Deploying sets the selected destination's active version and provisions its triggers:

• Webhook. Deploy returns a public invocation URL, /api/webhooks/<token>. The token is derived from the trigger node's path and destination identity, so Production and previews have different URLs. Copy the deployed URL from the destination panel. Production's URL stays stable through promotion and rollback. The payload plus request metadata become the run input. See Webhooks.
• Schedule. Schedule triggers are reconciled and become active only while their destination is on. See Scheduled Tasks.
• API. A deployed workflow can be executed with POST /api/v1/workflows/{id}/execute.

Chat-style triggers exist as chat-app webhook presets (Slack, Teams, Telegram, and similar) and the Copilot trigger, rather than a dedicated chat channel.

Sentry issue alerts

The Sentry issue to Telegram alert template imports as a draft. Its readiness gate requires a deployed version, a workspace Sentry webhook credential, a Telegram credential with a server-derived chat binding, a signed endpoint, and recursion exclusions. Deployment does not expose or activate an unsigned generic webhook URL.

For Production or a preview in Versions & previews, save the Sentry trigger, select its connection and prepare its endpoint under Deployed triggers before publication. An Admin or Owner must configure it. The endpoint stays off until the exact destination is approved and published. Creating a preview does not copy a Sentry subscription; configure Sentry to use that destination's returned URL. Rotating a signing secret creates a new endpoint version under the same logical integration so retransmissions continue to deduplicate.

The legacy production endpoint flow remains available through POST /api/webhooks or POST /api/v1/webhooks. Target-aware requests include the saved nodeId and executionTargetId.

Ingress (FLUXUS_ENABLE_SENTRY_INGRESS) and Telegram delivery (WORKFLOW_LIVE_TELEGRAM, FLUXUS_DISABLE_TELEGRAM_DELIVERY) are independent operator gates for the hosting deployment. A named workflow preview requires those capabilities to run real alerts, plus its own approved destination and connections.

Rolling back

Open Production's deployment history and choose the previous snapshot. Restore deployment can reuse a still-valid approval that explicitly allows reactivation of that exact snapshot. Otherwise, Prepare rollback approval prepares its version and connections for a new AIMS decision while the current deployment keeps running. After approval, publish the prepared rollback. Git, connections and dependencies are checked again; the outgoing generation is canceled.

Restoring a graph into the candidate editor only prepares changes. It does not switch Production. Use the destination's off switch to stop it and prevent new trigger execution; runs already in progress show Stopping until cancellation finishes. Publications and stops are recorded in the audit log.

Next steps