Integration Bindings Across Environments

A release carries what a workflow needs. Each environment supplies the actual connection and destination. Production integrations are configured once and reused by later releases while their identity and required capabilities remain valid.

What Travels

The displayed role names are illustrative, not a supported JSON schema. Bindings must be scoped by logical workspace, object, and requirement identity so similarly named roles in different workspaces cannot be confused.

A URL, tenant ID, table ID, channel ID, or provider account can be environment-specific without being secret. Capture these as declared requirements or reviewed overlays. A bundle must not silently retain a development destination because its text passed secret scanning.

First-Time Production Setup

1. Review each workspace's required integrations and the operations/scopes they need.
2. Choose the production account, service identity, or provider app. Prefer a managed identity with a documented owner and renewal process where the provider supports it.
3. Configure the production callback and webhook URLs, then authorize or provision the connection on production.
4. Map each logical requirement to the correct local connection and destination. Verify account, tenant, permissions, and workspace access rather than matching by display name.
5. Run read-only connectivity checks where available and a controlled validation using agreed test data. Do not use a health check that sends customer messages or mutates business records without an explicit test procedure.
6. Generate a fresh activation preflight after changing assignments. Review all remaining blockers before activation.

The current assignment API accepts references to already provisioned local resources. It does not create external provider accounts or transfer OAuth grants from development.

URLs and Provider Apps

Development and production have different public origins, so OAuth redirect allowlists and incoming webhook destinations need environment-specific configuration. Some providers permit several callback URLs on one app; others require separate registrations. GitHub Apps support multiple authorization callback URLs, and their authorization callback is distinct from their installation setup URL. See GitHub's callback documentation.

Treat callback URLs, setup URLs, and webhook delivery URLs as separate settings. Multiple OAuth callbacks do not establish webhook routing to both environments. Use separate apps where isolation or provider behavior requires them.

Recommended display names are Steel Engine App for production, Steel Engine Dev for development, and Steel Engine Local (Developer Name) for an individual's local setup. Customer-owned registrations may need a customer identifier to satisfy the provider's uniqueness rules. Names help operators identify an app; permissions and installation IDs establish actual access.

The GitHub connection used to transport releases is organization-owned within each installation. An integration a workflow uses to call GitHub is a separate runtime connection. Authorizing one does not automatically authorize the other.

Later Releases and Rotation

An unchanged logical requirement reuses the target binding. New requirements, revoked grants, changed account identity, insufficient scope, or removed resources require attention. Token refresh or key rotation for the same approved resource identity need not create a new release; an account or destination replacement must be reviewed and included in a fresh activation plan.

Existing activations retain their assignment targets. Editing a mapping must not silently redirect already active versions. In-flight executions follow the retained resource policy, including current authorization and credential validity; retention is not a promise that an expired or revoked credential keeps working.

Organization Readiness

The implemented release page groups failures by workspace name and shows the affected object, resource role, check code, and recovery action. Configure assignments with the existing target API/CLI, then select Check readiness and prepare again. The page contains no credential values. Any unresolved activation requirement blocks deployment of the complete organization.

Planned Assignment Editor

Each required binding should show its workspace, consuming objects, provider, approved target identity, last check time, and a specific next action. Suggested states are Needs connection, Needs authorization, Missing permission, Unavailable, Unsupported, and Ready. A timeout is unknown readiness, not a successful check.

An organization release stays blocked while any required binding is unresolved. The page should say, for example, “8 workspaces ready; Support needs a production connection,” and take an authorized administrator directly to the affected binding. Read-only users see status without access to secret values or administrative actions.

Blue/Green and Connection Continuity

Both production slots should use the stable public production origin and the same authorized production binding model. A cutover should not require new OAuth consent just because a pod or internal hostname changed. Provider webhook delivery must have one active owner, and inactive green must not start duplicate subscriptions or scheduled work.

If the design uses genuinely independent production databases instead of slots within one logical production environment, connection continuity and token storage require a separate state-sharing or replication design. A workflow bundle cannot supply that design by copying credentials.