Skip to content
Nexa Platform Docs

Promotion

Automations are authored in dev and moved forward one environment at a time — dev → test → prod. Promotion is pull-request based: Nexa copies the automation’s files onto the target environment’s branch and opens a PR that the receiving team reviews and merges in GitHub. This page covers how promotion works and how to follow a deployment through its workflow logs.

The promotion chain

Section titled “The promotion chain”

Each automation tracks which environment it currently lives in and where it can go next:

Current environment Promotes to
dev test
test prod
prod — (final stage)

The Promote action is only offered when a valid next target exists.

How promotion works

Section titled “How promotion works”

  1. Open the automation. From the Agentic Automation list, use the row’s action menu, or open the detail page (/agentic-automation/view/:id).

  2. Choose Promote. Select Promote from the action menu. A confirmation dialog states the target environment (for example, “Promote automation-name to TEST”).

  3. Confirm. Nexa copies the automation files and opens a pull request targeting the next environment’s branch. The dialog spells this out: it “will copy the selected automation files and open a PR targeting the TARGET branch. The target team will review and approve the PR in GitHub.”

  4. Review and merge in GitHub. The receiving team reviews the PR in GitHub and merges it. Merging triggers the deployment workflow for the target environment.

  5. Track the deployment. After promotion, Nexa opens the workflow logs so you can watch the GitHub Actions run that deploys the automation into the target environment.

Because promotion goes through a real pull request, it is auditable and reversible with the same controls as any other change in your repository — the target team owns the merge decision.

Tracking the deployment: workflow logs

Section titled “Tracking the deployment: workflow logs”

Every deployment (initial or promoted) runs as a GitHub Actions workflow. The workflow logs viewer polls the run and shows its live state. It appears in the deployment tracking modal from the list, and on the Deployment tab of the automation’s detail page.

The viewer surfaces:

Field Meaning
Workflow Name of the GitHub Actions workflow
Run ID The dispatched run’s identifier
Status Run state — queued, in_progress, or completed, combined with a conclusion of success, failure, cancelled, or skipped
Commit Id The commit the run is deploying

Below the summary, each job in the run is listed with its individual steps and their status, and an Open GitHub Actions Run link takes you to the run in GitHub. The viewer refreshes roughly every 10 seconds until the run reaches a final state.

The automation detail page

Section titled “The automation detail page”

Beyond deployment, the detail page (/agentic-automation/view/:id) organizes everything about an automation into tabs:

Tab Shows
Configuration Name, alias, description, agent, prompt, trigger, status, and the configured actions
Plan The saved execution plan (graph, steps, JSON)
Validation & Artifacts Validation state, target branch, commit SHA, and the committed automation files
Deployment The GitHub workflow logs for the current deployment
Execution History The runtime job and recent runs pulled from platform observability

Execution history

Section titled “Execution history”

The Execution History tab lists recent runs of the automation’s job with each run’s ID, life-cycle state, result state, task count, and a link to the run on your data platform. You can expand a run to see its output, or trigger a fresh run with Run Now.

Removing an automation from an environment

Section titled “Removing an automation from an environment”

Alongside Promote, the action menu offers Delete, which removes the automation from its current environment. Like promotion, environment deletion is a governed operation rather than an irreversible local wipe.

Section titled “Related”