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. Open the Changed Files 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 (requires pushing the approved changes)
3. Reuse the current branch, or check Create new branch and enter a branch name. A new branch is selected automatically when needed, and required when all PR repositories are on their target branch or a protected branch.
4. Review the Target branch selector for each repository. Source and target must differ.
5. Click Commit Changes. The PR is created after approval using the commit message for its title and description. If additional review or authorization is needed, complete the separate PR dialog.

When creating a new branch, the suggested target remains the branch selected at task launch. When reusing the current branch, CoderFlow chooses a distinct target from the launch branch, configured repository branch, or provider default. Changing Create new branch refreshes the target defaults; review them before committing.

After Approval

If you already approved and pushed an existing or new feature branch, even without selecting the PR option:

1. Click Create Pull Request in the task actions
2. Review the title, description, and target branch
3. Click Create Pull Request

The button appears when an approved repository has a recorded successful push, a supported provider, and a distinct target, and the task has no PRs yet. A direct push to the only configured/default target does not qualify. Older approvals are checked against the current repository targets too.

Requirements

• Approved changes successfully pushed to an existing or new branch with a distinct target
• 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.

From the Task Page

Sync does not require approval. Run it from the task page whenever the task has changed files — before approving, after approving, or repeatedly across a QA cycle. See Syncing Across a QA Cycle.

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 when the task container is running, 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.

Note that syncing an unapproved task writes source to IBM i that is not yet committed to Git. Approve the task when the change is ready so the work is committed and pushed.

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.