Environments and deployment

Environments isolate released versions and runtime configuration. A typical organization develops in one environment, validates in another, and executes production traffic in a final environment.

Development → Test → Production

Your organization may use different names or additional stages. The configured order controls valid promotion targets.

What changes by environment

An environment can have its own:

• deployed HubItem versions;
• Global Variable values;
• connector endpoints and credentials;
• solution API keys and rate limits;
• event subscriptions and publisher health;
• permissions to test or debug.

This allows Development to call sandbox services while Production calls live systems without embedding those differences in decision logic.

Create and order environments

Open Organization → Environments. Enter a required name, optional description, and active state. Describe the purpose and data restrictions, for example:

Name: Test
Description: Pre-production validation using synthetic or approved test data.

Reorder environments to establish progression. Before changing order, review pending deployments and automated consumers because the valid “next” target may change.

Deactivating an environment can affect tests, API calls, and event subscriptions. Deleting one should be treated as a governed operation after checking deployments, keys, variables, connectors, and audit requirements.

Prepare a release

Before creating a deployment request:

1. Create versions for changed assets.
2. Update parent Workflow dependency selections.
3. Run saved tests in the source environment.
4. Test environment-specific connectors.
5. Confirm Global Variables have target-appropriate values.
6. Document the purpose and expected outcome of the release.

Create a deployment request

Open Organization → Deployment Requests and select Create New Deployment.

Select environments

Choose the source and a permitted later target. Promotion is forward through the configured sequence; the form does not offer an invalid earlier target.

Describe the release

Use the optional description for business impact and validation evidence:

Raise Gold free-delivery threshold to 200. Regression pack DELIVERY-2026-08 passed in Test. Includes the pricing table and Order Delivery Workflow.

Select HubItems

Search by name/type and select the assets being promoted. DecisionHub analyzes references and includes dependencies. A Workflow can bring in selected Decision Tables, Rulesets, Scorecards, Coding/HTTP Clients, and Data Models.

Review the preview

The preview distinguishes selected items from dependencies and summarizes what will be created or updated. Check:

• item names and types;
• intended versions;
• unexpected dependencies;
• shared Data Models that could affect other processes;
• whether all parent Workflows are included.

Then create the request.

Approval lifecycle

Status	Meaning	Next action
Pending	Submitted and awaiting review	Approve or cancel
Approved	Authorized but not applied	Execute or cancel
Deployed	Applied to target	Smoke test and monitor
Failed	Could not complete	Inspect reason, correct, and retry/create a request as offered
Cancelled	Stopped before deployment	No changes applied by this request

Creation, approval, and execution are separate permissions. Organizations can assign them to different people for separation of duties.

Reviewer checklist

An approver should verify:

• description identifies the business change;
• selected versions match the review evidence;
• dependency list is complete and reasonable;
• source-environment tests passed;
• target connectors and variables are ready;
• rollback/forward-fix owner is known;
• release timing is appropriate for API and event consumers.

Approval confirms readiness; it does not change the target environment. A permitted operator still selects Execute Deployment.

After deployment

Run a smoke test using a non-destructive, recognizable payload:

{
  "applicationId": "SMOKE-PROD-20260815-01",
  "requestedAmount": 1000,
  "applicant": {
    "age": 30,
    "annualIncome": 70000,
    "existingDebt": 0
  }
}

Confirm:

1. the expected version appears in environment progression;
2. the response is correct;
3. Execution History contains the correlation record;
4. event/connector activity is healthy;
5. API-key limits and errors remain normal.

Never use a smoke payload that creates a real financial, customer, or regulatory action unless the process explicitly supports test records.

Failure and recovery

Deployment is not an editor undo operation. If a release produces incorrect behavior, stop or restrict affected traffic according to operating procedure, identify the last known-good versions, prepare a governed corrective deployment, and preserve execution/deployment evidence.

Do not delete the faulty version while investigating; it is part of the audit trail and may be needed to reproduce the issue.

Common problems

Symptom	Likely cause
Item is absent from promotable list	No eligible source version, wrong source/target, or permission
Unexpected items appear in preview	They are dependencies of a selected asset
Tests pass in Development but fail in Test	Different deployed dependency, variable, connector, or permission
API still returns old behavior	Key points to another environment or deployment did not include parent Workflow
Event workflow has no executions	Target subscription is not healthy or topic/configuration differs