The Workflow Editor

Workflows are built in Admin → Workflows. The demo has the three workflows you'll recreate on the next page:

Click + New workflow (or the pencil on an existing one) to open the editor. It has four tabs: Basics, User Inputs, Steps, JSON.

Basics

Identifier, title, description, the operation (CREATE), the target blueprint (what entity kind this workflow relates to — deployment for all three demo workflows), and the Published toggle that makes it visible in Self-service:

User Inputs

The form users fill when they run the workflow, defined as a JSON schema. The demo workflows all use:

{
  "required": ["environment", "version"],
  "properties": {
    "version": { "type": "string", "title": "Version", "default": "1.0.0" },
    "environment": {
      "enum": ["dev", "staging", "prod"],
      "type": "string",
      "title": "Environment",
      "default": "staging"
    }
  }
}

enum renders as a dropdown; default pre-fills the field.

Steps

Steps are the heart of a workflow — an ordered list with dependencies, rendered as a DAG in the run view:

Select a step to configure it:

Each step has:

Field	Meaning
Identifier	unique id — referenced by other steps (dependsOn) and in jq templates (.steps.<id>.status)
Type	GITHUB (dispatch an Actions workflow), GITLAB (create a CI pipeline), APPROVAL (human gate), UPSERT_ENTITY (write to the catalog)
Condition	ON_SUCCESS (run only if dependencies succeeded) or ALWAYS (run even after failures — used for recording results)
Depends on	which steps must finish first; steps with the same dependencies run in parallel
Credentials	Default (environment) or Stored secret (see Secrets)
Config	type-specific JSON (repo/workflow for GITHUB, projectId/variables for GITLAB, mapping for UPSERT_ENTITY)
Timeout	minutes before the step is failed (or, for APPROVAL, before onTimeout applies)

jq templating

Config values support {{ ... }} jq templates evaluated against the run context:

Expression	Value
{{ .inputs.version }}	a user input
{{ .run.id }}	the run id (r_...)
{{ .user.email }}	who triggered the run
{{ .entity.identifier }}	the related entity (for entity-scoped actions)
{{ .steps.deploy_orders.status }}	another step's result (SUCCESS / FAILURE / SKIPPED)
{{ if (.steps.a.status == "SUCCESS") and (.steps.b.status == "SUCCESS") then "SUCCESS" else "FAILURE" end }}	computed values

Use underscores in step identifiers

.steps.deploy-orders.status is invalid jq (the hyphen parses as subtraction). Name steps deploy_orders, not deploy-orders.

JSON

The whole workflow as a single JSON document — handy for copy/pasting the demo workflow definitions or managing workflows via the API:

curl -X POST "https://<your-idp-domain>/api/v1/workflows" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d @workflow.json

Next: the three demo workflows, in full →