Environments

Task walkthrough: Manage environments. This page is the full configuration and troubleshooting reference.

An environment is a target — such as test or production — that workflows and service requests are deployed to.

No permission covers environments — the permission catalog has none — so roles do not control who can create, change or delete one.

Model

Field	Notes
name	Unique per tenant. 1–100 characters, and unlike most objects it must read as an identifier: start with a letter or digit, then letters, digits, _ or - only. See Object naming.
description	Optional.
environmentType	DEV, TEST, STAGING, or PRODUCTION.
status	active, inactive, or degraded. A new environment starts active. Once services are registered to it, the status follows their health — see below.
metadata	Free-form key/value used by provisioning.
lastHeartbeatAt	Shown as Last Heartbeat. Nothing reports a heartbeat in the current build, so it stays empty. Use the services' health instead.

Registered services

Each environment has one or more services:

Field	Notes
serviceType	runtime-service or notification-service.
healthStatus	healthy, unhealthy, or unknown.
baseUrl, version	Endpoint and version.

Continuum checks each registered service's health in the background and sets the environment's status from the result:

The environment's services	Status
All healthy	active
Some unhealthy	degraded
All unhealthy	inactive

The environment selector lists only active environments. A degraded or inactive environment drops out of it until its services are healthy again.

An environment is a boundary for what you can reach

A run belongs to exactly one environment, and the platform enforces that when you address one of its jobs directly. A job instance identifier from another environment reports not found — for reading the job, for every action on it (hold, release, cancel, restart, force start, skip, kill, mark fixed, under review, mark finished OK, mark failed, edit), for its output files, and for its history. Reporting not-found rather than "forbidden" is deliberate: it doesn't confirm that the identifier exists somewhere else.

Earlier builds resolved a job-instance identifier without checking which environment it belonged to, so a job in one environment could be read and acted on through another. That's closed.

The same now holds for a whole workflow instance. A workflow-instance identifier from another environment reports not-found for reading it, for hold, release, start, cancel and close, and for its dependency graph and job history — where previously only delete and adding a job to it were checked. As with a job, the answer is not-found rather than forbidden, so it doesn't confirm the identifier exists elsewhere.

One consequence worth knowing: a job whose workflow instance has been deleted now reports not-found too, where its history previously came back empty. There is no environment to place such a job in, and serving a job whose run no longer exists is the worse answer.

How an environment is created

Creating an environment kicks off asynchronous provisioning (a background process that stands up the per-environment runtime service). Provisioning runs fire-and-forget: a provisioning failure is logged but does not fail the create request. So a newly created environment can exist before its runtime is fully ready.

Good to know

• The Environments screen isn't in the main navigation — it's reachable by direct link.
• A new environment that "isn't working yet" may still be provisioning — check whether its services are registered and what health they report (unknown/unhealthy).
• degraded/unhealthy indicate the environment's services aren't fully healthy — a deployment target issue, not necessarily a workflow problem.
• Provisioning runs only when the environment is created. There is no way to run it again for an existing environment.

Troubleshooting

Symptom	Likely cause	Resolution
New environment not running workflows	Provisioning hasn't finished or failed (fire-and-forget)	Check the environment's registered services and their health. Provisioning can't be re-run, so if no healthy runtime service appears, contact support before deleting and re-creating the environment (Administrator).
Service shows unhealthy/unknown	The registered service isn't reporting healthy	Check the service's endpoint (Administrator).
An environment is missing from the environment selector	The selector lists only active environments, and this one is degraded or inactive because some or all of its services are unhealthy	Check its services' health on the Environments screen (Administrator).
A job link or identifier reports "not found", but the job plainly exists	The link is for a job in a different environment, or its workflow instance was deleted	Switch to the environment the run belongs to and open the job there (Operator).
An action on a workflow instance reports "not found", but the run plainly exists	The run belongs to a different environment than the one you're working in	Switch to that environment and act on the run there (Operator).

Contact support when

• Provisioning silently failed (the environment exists but its runtime service never registers, or never reports healthy).

Include the environment id/name, type, status, and the registered services' health.