Skip to main content

Approval & Deployment

Once a task completes successfully, you review the changes and decide whether to approve and deploy them. This is the final step before code goes into your repositories.

Reviewing Changes​

Before approving, carefully review what the agent changed.

Changes Review Process​

  1. Open task detail page for completed task
  2. Scroll to "Results" section
  3. View files changed showing git diffs for each repository
  4. Review test results (passed/failed counts)
  5. Read activity feed to understand what was done

Approving Tasks​

When you're satisfied with the changes, approve them to commit and optionally push.

Approval Workflow​

  1. Click "Approve" button on task detail
  2. Adjust generated commit message if desired
  3. Choose deployment options:
    • Pull from remote after commit (rebase): Keep local branch up to date
    • Push to branch: Immediately push to the current/default branch
    • Create new branch: Create a new branch for this work
    • Commit only: Commit but don't push (manual push later)
  4. **Click Commit Changes when ready

Approval Restrictions​

You cannot approve if:

  • No changes: Task made no file modifications
  • No container: Environment has been deleted
  • Task is queued or running: Wait for task to complete
  • Permissions: You don't have permission to approve for this environment

After Approval​

Once approved:

  • Changes are committed with your commit message
  • Changes are pushed (if you selected that option)
  • Task status shows "Approved"
  • Approver info is recorded (name, email, timestamp)
  • Previous approval status is cleared if you provide follow-up instructions

Creating Pull Requests​

After approving task changes, you can create pull requests on GitHub or Azure DevOps to merge your work into target branches.

From Approval Dialog​

Create pull requests directly when approving:

  1. Click Approve button
  2. Check Create pull request (auto-enables push and new branch options)
  3. Enter branch name (applied to all repositories)
  4. Click Commit Changes
  5. Review auto-generated PR title and description
  6. Click Create Pull Request

Pull requests target the branches you selected when creating the task.

After Approval​

If you already approved and pushed to a new branch:

  1. Click Create Pull Request button (top-right actions)
  2. Review auto-generated PR title and description
  3. Click Create Pull Request

The button appears only when the task is approved, pushed to a new branch (different from target), and no PRs exist yet.

Requirements​

  • Approved and pushed to new branch
  • Git provider supports PRs (GitHub, Azure DevOps)
  • OAuth connection authorized (prompted if needed)

After Creation​

  • PR links appear in task detail
  • Review and merge through Git provider

IBM i Sync​

For environments with an IBM i connection that has the Sync feature enabled, you can sync changed source files directly to an IBM i library. This writes source members to the target library—useful for getting code onto IBM i for integration with traditional source member-based IBM i source control / change management systems.

Sync / Deploy Credentials​

How member sync and UI deploy authenticate depends on the Sync / deploy credentials setting on the connection (configured in Environments > Connections):

  • Prompt (default for new connections) — You are prompted for a user profile and password each time you sync or deploy. The password is used once to establish the connection and is never stored.
  • Connection — Sync and deploy use the SSH user and key already configured on the connection. No additional credentials are needed at runtime.

From Approval Dialog​

Sync as part of the approval step:

  1. Click Approve on a completed task
  2. Check Sync to IBM i (appears when source-member sync or htdocs deploy is configured)
  3. Enter a library name (max 10 characters, alphanumeric)
  4. If the selected actions use Prompt mode, enter your user profile and password
  5. Select files to sync from the file tree
  6. Click Commit Changes — approval proceeds, then the sync runs automatically
  7. A live log streams the sync progress

The library is created if it doesn't exist. Source physical files and members are created from the changed files.

After Approval​

If you already approved without syncing, or need to sync again to a different library:

  1. Click the Sync to IBM i / Deploy htdocs button (top-right actions on task detail). The button label adapts based on which types of changed files exist: Sync to IBM i for source members only, Deploy htdocs for Profound UI htdocs files only, or Sync to IBM i & Deploy htdocs when both are present.
  2. Enter the target library name when syncing source members
  3. If the task also has changed Profound UI htdocs files, the same dialog includes those files in the selection tree and shows the IBM i IFS target path
  4. If the selected sync or deploy actions require prompted credentials, enter your user profile and password
  5. Select files to sync or deploy from the file tree
  6. Click Sync, Deploy, or Sync & Deploy to start
  7. A live log streams the progress

If both source sync and htdocs deploy files are selected, source sync runs first and htdocs deploy runs second. The button appears only when the task is approved, the environment has an IBM i connection with Sync, Profound UI htdocs, or Agentic Display Files enabled, and there are eligible changed files to operate on.

File Selection​

The sync dialog shows a file tree of all changed files. Files with recognized IBM i extensions are pre-selected. Files that can't be IBM i source members (name too long, non-source file types like .gitignore, *.md, etc.) are disabled.

Sync Details​

After a sync completes, the task metadata shows the synced library name, timestamp, and a link to view the full sync log.

File mapping follows IBM i conventions:

  • Member name — filename without extension (max 10 characters)
  • Source type — last file extension (e.g., RPGLE, SQL)
  • Source physical file — parent directory name (e.g., QRPGLESRC)

Deployment Workflow​

Full Task Lifecycle​

  1. Create task with instructions
  2. Agent runs autonomously
  3. Review changes (patches, logs, tests)
  4. Provide feedback if needed (follow-up instructions)
  5. Agent resumes and refines work
  6. Repeat until satisfied (steps 3-5)
  7. Approve changes when complete
  8. Changes deployed to your deployment target

Multi-Variant Deployment​

When comparing multiple agents (task groups):

  1. All variants complete
  2. Judge tasks evaluate (if auto-judge enabled)
  3. You select winner (manually or via judge recommendation)
  4. Approve winner variant
  5. Changes from winner are deployed
  6. Other variants remain available for reference
  7. Loser variants can be deleted or archived

Approval Audit Trail​

CoderFlow tracks:

  • Approver: Who approved the changes
  • Approval time: When approval was given
  • Commit message: What was written
  • Branch deployed to: Where changes went
  • Remote push: Whether changes were pushed

This creates an audit trail for compliance and history.