Deliver client work with reviewable boundaries
Keep client scope, environments, approvals, and evidence separate while using a repeatable delivery workflow.
What does this client delivery workflow workflow cover?
Keep client scope, environments, approvals, and evidence separate while using a repeatable delivery workflow.
What should an evaluator inspect?
Inspect the stated requirements, workspace boundary, validation evidence, approval points, and stated deployment scope rather than inferring results from an example workflow.
Is this customer proof?
No. Workflow pages describe an evaluation model and may use fictional product artifacts. They do not assert customer adoption, outcome, or availability evidence.
Can we run this workflow today?
A released self-managed artifact and tested quickstart are not published. Review the self-hosted requirements or register interest in future Cloud or Enterprise offerings.
What is the next step?
Use the ungated sample run and pilot scorecard to frame the evaluation, then choose a request path only if the operating model fits.
Starting condition and desired outcome
An agency operates across clients with different repositories, credentials, acceptance criteria, and approvers. The outcome is a client-specific delivery record without cross-client environment or evidence leakage.
The current manual workflow
The BranchRunner workflow
- 01Bind client scope
Turn acceptance criteria and exclusions into requirements with named owners.
- 02Provision separately
Use client-specific workspace, credentials, network policy, and retention.
- 03Implement and validate
Run agreed checks and previews within the client boundary.
- 04Approve the package
Present change, evidence, exceptions, and delivery target to the authorized approver.
Evidence produced
The run keeps claims separate from checks and decisions. The evidence below describes the record, not a guaranteed outcome.
Product example. Repository, checks, and identities are illustrative; configure them for your system.
Where a person stays in control
Repository and secret access is scoped to the engagement.
New requirements return to the accountable owner.
Client-specific checks and exceptions stay visible.
Only named people can approve external delivery.
What the workflow can produce
Integrations, deployment, and edition fit
Validate the workflow against one real repository
Bring the starting condition, required checks, and approval boundaries. We will identify what can be configured today and what remains deployment work.