Environments and release management

FastHook does not add an environment field to a Workflow, Source, Destination, or connected account. Model development, staging, and production with separate resources and an explicit inventory. Use separate teams when an environment needs a hard membership, API-key, credential, or data boundary.

Choose the isolation boundary

| Model | Use it when | Boundary | Important limitation | | --- | --- | --- | --- | | Separate FastHook teams | Production access, credentials, stored execution data, or project keys must be isolated | Each team owns its Sources, Workflows, connected accounts, reusable Destinations, Filters, Transformations, and API keys | Resource IDs cannot be reused unchanged across teams | | One team with separate resources | The same team may administer every environment and only logical separation is required | Naming and separate resource IDs distinguish environments | Team members and project credentials still share the same team boundary |

A name such as [prod] Billing failure alert improves identification but does not create authorization isolation. Do not treat naming conventions as an access-control feature.

The older Manage environments guide remains the reference for direct Source, Destination, and Connection routes. This page extends the model to multi-step Workflows and release operations.

Environment topology

Create an inventory before building the first production Workflow:

| Logical dependency | Development | Staging | Production | | --- | --- | --- | --- | | FastHook team | Team ID | Team ID | Team ID | | Trigger | Source ID and provider event | Source ID and provider event | Source ID and provider event | | Provider access | Connected account and tenant | Connected account and tenant | Connected account and tenant | | Reusable Step resources | Destination, Filter, or Transformation IDs | Destination, Filter, or Transformation IDs | Destination, Filter, or Transformation IDs | | Secrets | Non-production secret owner | Staging secret owner | Production secret owner | | Workflow | Workflow ID and current version | Workflow ID and current version | Workflow ID and current version | | Operations | Test owner and data policy | Release approver and canary window | On-call owner, alert route, and rollback decision maker |

Store logical names in the inventory, not secret values. Keep environment API keys and credential material in the deployment system’s secret manager.

Isolate every external side effect

An environment is only as isolated as the systems its Actions can change. Check all of these before testing:

• the Source receives events from the intended provider tenant or webhook sender;
• each connected account points to the intended provider workspace, organization, site, or user;
• reusable Destinations use environment-specific URLs and authentication;
• email, chat, ticket, CRM, storage, and billing Actions target non-production resources;
• test payloads contain no production personal data or credentials; and
• alert receivers clearly identify the environment.

A staging Workflow connected to a production account can still create production side effects. The Workflow name and FastHook team do not override provider permissions.

Build order

1. Create or select the destination FastHook team.
2. Provision the environment-specific Source and verify its Trigger.
3. Connect provider accounts using least-privilege permissions.
4. Create reusable Destinations, Filters, and Transformations required by the graph.
5. Record the destination IDs in the environment inventory.
6. Promote the Workflow graph as a new draft with configuration promotion.
7. Test with an environment-specific event and inspect every Step in Workflow Audit.
8. Complete the Workflow release checklist before activation.

Ownership and change control

Assign one owner for the automation’s business outcome and one operator for production incidents. Record who may approve a release, rotate credentials, activate or pause the Workflow, initiate replay, and accept duplicate-side-effect risk.

FastHook’s protected resources use the team-membership boundary; the product does not currently expose per-Workflow roles. Apply separation of duties through team membership, provider permissions, secret-manager policy, and the external release process. See Security and governance for the exact access model.

Verify the boundary

Before accepting the topology:

1. authenticate with the API key intended for each environment;
2. retrieve the expected Source and Workflow using that environment’s x-team-id;
3. verify that production IDs are absent from non-production promotion mappings;
4. trigger a synthetic event and confirm the provider tenant and destination that changed; and
5. retain the Workflow ID, version, run ID, request ID, and provider result as release evidence.

Continue with Configuration promotion, Secrets and credential rotation, and Production readiness.