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.

If AIMS blocks the publication dialog, select Open AIMS approval to open the same destination's governance detail. Complete the preparation or review action shown there. An old link with an unavailable governed version offers Open current destination; this reloads the destination without approving or publishing anything. See AI governance for the separate workflow and governance version numbers and the Owner authorization requirements.

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 deployed destination's connection takes precedence over the account shown in a block's selector. When they differ, a notice beside Credential or Account names the account used by deployed steps. Choose Edit destination connections to open this destination's connection choices. Saving a different node selection does not change an existing deployment; save the destination connections and publish the approved configuration to change live execution. Run deployed step uses the deployed version and bindings, while Execute step tests the candidate with simulated effects. A simulation does not verify a provider account or its credits.

Step results show Credential, its resolved account name, and whether it came from the node selection or a destination binding, including after a provider error. This records names and sources without secret values. Historical results without this metadata do not infer an account from today's selections.

If publication reports missing connections, select Configure destination connections in the notice. This closes the publication dialog and opens the connection choices for the same destination. Select the existing account and Save connection choices, then retry publication. A workspace account alone does not select a destination connection or grant AIMS approval.

In Editor → Resources, a credential warning offers Open node. If compatible accounts already exist, select one and choose Use this account to save it on that node. Validation and deployment preparation use that selected account, including its required permissions. Connecting or successfully testing an account does not select it for every node with a similar name. Check each pending node, including those sharing an account alias. For an account required by a called workflow, Open workflow opens that workflow’s own setup. Credentials shows one row with all node names when they share the same configured account, credential type and alias within one workflow; pending selections and different accounts remain separate. Test configured credentials uses the selected accounts; different accounts are tested separately and pending node selections stay pending. Expand Connection details only when you need the connection test's technical information.

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.
• Form Trigger. Publish the configured form and use Open production form in its block settings. Form links use a random capability; access defaults to members with execution permission. Public submission requires explicitly choosing Anyone with the link. Each destination keeps its own deployed version. Temporary test listeners use the candidate and do not change production.
• 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.

Jenkins finished builds

A workflow with the Jenkins build finished trigger needs a Jenkins event source on each destination that should listen. After saving the trigger, choose Add event source on the destination, select Jenkins finished builds, the connection, the jobs and the build results, then Configure source. The source polls only while the destination is on and its deployed version has the trigger; a source added with a new trigger starts polling when you deploy it. Each job starts from a baseline, so builds that existed before the source started polling never start the workflow. See Jenkins for the status, skipped builds and deploy restrictions.

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