Protect and Edit Workflows

Protect an existing workflow and make reviewed changes on a source-control branch

Protection makes the repository default branch authoritative for a workflow's main draft. After protection, builders work on explicit source-control branches instead of editing main directly.

Protect a Workflow

Before protecting a workflow, confirm that the workspace has an active repository binding and that the workflow is in a valid, savable state.

  1. Open an existing workflow.
  2. In the source-control bar, confirm the status says Ready for source control.
  3. Select Protect.
  4. Review the confirmation and select Protect Workflow.
  5. When the pull request is ready, select View PR and review it in GitHub.
  6. Merge the protection pull request.

SteelEngine snapshots and sanitizes the current workflow, creates a temporary branch, commits its managed bundle, and opens the pull request. Direct editing is read-only while protection is pending so later edits cannot be overwritten by the protection merge.

If the pull request merges, SteelEngine applies the bundle and marks the workflow protected. If it closes without merging, the workflow returns to its normal editable state.

Protection is a repository change, not a deployment. The workflow's active runtime version is preserved throughout the protection flow.

Main Is Read-Only

Protected workflows open on main by default. On main, authorized users can:

  • View the workflow and its source-control status
  • Run the protected main draft manually
  • Inspect commit and validation history
  • Configure resource assignments when they have admin access
  • Deploy the synchronized draft when they have deploy access

Graph edits, metadata changes, imports, and Chat edits are blocked on main. Select or create a branch before changing the workflow.

Protected workflow placement is also stable: you cannot move the workflow, or rename or move an ancestor folder that contains it.

Create a Branch

  1. Open the branch selector in the source-control bar.
  2. Select New branch.
  3. Enter a descriptive name such as feature/update-triage-routing.
  4. Select Create branch.
  5. Wait for the branch to show open, then select it.

SteelEngine creates the remote GitHub branch from the repository's current default-branch head. GitHub branch names are normalized under a steelengine/ prefix.

A source-control branch belongs to the workspace, not to one workflow. You can open multiple protected workflows on the same branch when a change spans related workflows. Each workflow receives an independent autosaved working copy when first opened on that branch.

By default, a branch is writable by its owner and workspace admins. Other authorized workspace members can view it.

Edit and Run the Branch Draft

Branch editing behaves like normal workflow editing:

  • Changes autosave to the branch working copy in SteelEngine.
  • Other editors in the same authorized branch context receive realtime updates.
  • Manual editor runs use the current branch draft.
  • Chat in the workflow editor reads and edits the active branch.

Autosave does not create a Git commit. The amber dot and uncommitted changes status mean the branch draft differs from its last commit.

Manual branch runs do not create or update production schedules, webhooks, APIs, or hosted surfaces. Those continue to use the active deployment version.

Review and Commit Changes

  1. Select Commit changes in the source-control bar.
  2. Review the structured change summary:
    • Added, removed, and modified blocks
    • Edge and variable changes
    • Workflow metadata and resource requirement changes
    • Canvas context
    • Sanitized Git file previews, including prompt and code changes
  3. Enter a clear commit message.
  4. Select Commit.

SteelEngine validates the reviewed revision, converts it into the portable bundle, scans it for secret material, and advances the GitHub branch without force-pushing.

If someone edits the branch after you open the review, commit the newly reviewed revision instead. SteelEngine rejects stale commit attempts rather than committing a different draft from the one you approved.

Resource Assignments

Git stores logical requirements—for example, that a workflow needs a connection with a specific role. The actual credential, account, or environment-specific resource selected for that role remains in SteelEngine.

On protected main, an admin can select Configure resource assignments from the source-control bar and map every required role to an accessible workspace resource.

Changing an assignment does not create a Git diff. Changing which role or provider the workflow requires does create a branch change. Validation reports missing assignments separately from graph or bundle errors, and deployment remains blocked until all assignments are valid.

Branch Housekeeping

  • Commit history shows the branch commits known to SteelEngine.
  • Discard all branch changes restores the working copy to the committed branch state.
  • Delete branch removes a clean remote branch. SteelEngine refuses to delete it while local drafts have uncommitted changes.
  • Recreate remote repairs a branch whose remote ref was deleted while a local draft still had changes.

When the change is committed, continue to Review, Merge, and Deploy.

On this page