Publish, approve and deploy solutions

Save as version

Records a meaningful state of the project before publication or major changes.

Publish

Makes a completed Agentic Worker available for use inside Designer and, where authorised, through the Store.

Deploy

Connects channels, workers and supporting capabilities in an environment and activates that environment.

Human approval

Pauses sensitive flow activity until an authorised person decides what should happen.

• Confirm that the correct workspace is active.
• Complete the Testing and troubleshooting guide.
• Resolve the visible project issue count.
• Confirm that all important business routes have been tested.
• Save the current draft.
• Decide which state should be recorded as a version.
• Confirm whether an Agentic Worker must be published for use by a flow.
• Identify sensitive actions that require human approval.
• Agree who may approve those actions.
• Prepare a non-production deployment environment.
• Confirm that the required channels, workers, providers and capabilities are available.
• Know who is authorised to approve production deployment.

• Saving does not publish.
• Publishing does not automatically create a live customer channel.
• Deploying does not replace runtime human approvals.
• A Human Approval step does not approve the project release.
• A worker may need to be published before it can be selected by a flow.
• An environment must contain the required resources and connections before deployment.

Enlarge

• The readiness check runs as the project moves toward publication or deployment.
• A successful result says that no issues were found.
• The summary may include the number of cards and process steps.
• Let’s go continues to the next stage.
• The figures shown belong only to the ACME demonstration.
• The dialog uses the word “bot”; this guide refers to the project or solution.

1. 1Save the current draft.
2. 2Complete representative Run Demo tests.
3. 3Resolve the visible issue count.
4. 4Start the deployment or publication journey.
5. 5Review the readiness result.
6. 6Return to the Editor if an issue remains.
7. 7Continue only when technical validation and business review have both succeeded.

Enlarge

Version history

Review the project versions currently available.

Save as version

Record the current state as a meaningful version.

Auto-layout

Rearrange the visual canvas. This changes presentation, not the purpose of versioning.

Import flow

Import supported flow content.

Export flow

Export the flow through the supported Designer format.

Export to GitHub

Send supported project content to a connected GitHub destination.

1. 1Complete the intended design changes.
2. 2Save the draft.
3. 3Run the priority test scenarios.
4. 4Complete the readiness check.
5. 5Open the project actions menu.
6. 6Select Save as version.
7. 7Add a meaningful version label or description where requested.
8. 8Review Version history to confirm that the state was recorded.
9. 9Continue editing in the draft when further changes are required.

Enlarge

Local only

Saves the worker to this Designer so it appears in the Agentic Worker flow step. Use this when the worker is intended for solutions in the current Designer context.

Local and publish to Store

Saves the worker locally and also publishes it to the Store. The dialog shows that Store sign-in is required in this state.

1. 1Open the Agentic Worker in Composer.
2. 2Complete direct worker testing.
3. 3Confirm the model, tools, guardrails, memory and limits.
4. 4Save the accepted project state as a version.
5. 5Select Publish.
6. 6Review the version displayed in the dialog.
7. 7Select Local only when the worker is required inside the current Designer.
8. 8Select the Store option only when signed in and Store distribution is intended.
9. 9Select Publish.
10. 10Confirm that the worker is available to the intended Flow project.

Enlarge

• The Approvals page is the operational inbox for work paused while waiting for approval.
• A request can be created when a flow reaches a configured Human Approval step.
• The screenshot shows an empty inbox.
• An empty inbox means no request is currently visible in the shown workspace state.
• It does not prove that approval policies are absent.
• It does not prove that no flow contains a Human Approval step.

Flow reaches Human Approval
             ↓
Flow references an Approval Policy
             ↓
Request appears in Approvals
             ↓
Authorised person responds
             ↓
Flow continues

Enlarge

• About this policy
• Levels
• If nobody responds
• Channels

Name

The human-readable name operators see in the list and on paused work.

Policy ID

The identifier a flow uses to reference the policy. The interface states it cannot be changed after the policy is created.

Description

Explains the policy’s business purpose and when it should be used.

Requester cannot self-approve

When enabled, the person who requested the action may not approve it. When disabled, the policy itself does not prohibit self-approval, although the requester must still satisfy any other approver rules.

Summary

The right-hand panel summarises the number of levels, the requester self-approval state, what happens when all levels are exhausted and the configured channels.

Automatic saving

Changes save automatically in the interface shown.

1. 1Open Approval policies.
2. 2Create a policy or open the policy to configure.
3. 3Enter a clear operator-facing name.
4. 4Choose the Policy ID carefully.
5. 5Add a description explaining the protected action.
6. 6Decide whether the requester may approve their own request.
7. 7Review the Summary panel.
8. 8Continue to Levels.

Enlarge

• Each level is asked in sequence.
• If a level receives the required approvals, the request can continue.
• If a level reaches its time limit without an answer, the request moves to the next level.
• What happens after the final level is controlled by If nobody responds.

Who may approve

The current interface supports choices such as administrators only or any member of the workspace. Treat these as examples from the current interface.

Approvals needed

The number of approvals required at that level.

Named approvers

Optionally limit the level to specified people. Naming people narrows the level to exactly those approvers.

Escalate after

The number of minutes the level waits before moving to the next level. Left blank, the level waits indefinitely instead of escalating automatically.

Add level

Adds another approval level for escalation or additional review.

Ordering

Use Move up and Move down where available to control the level sequence.

1. 1Open the Levels tab.
2. 2Choose who may approve Level 1.
3. 3Set the number of approvals required.
4. 4Add named approvers only when the level must be limited to specific people.
5. 5Enter an escalation time where automatic movement to the next level is required.
6. 6Leave the escalation field blank only when indefinite waiting is intentional.
7. 7Select Add level when another approval stage is required.
8. 8Order the levels from first response group to final escalation group.
9. 9Review the Summary panel.

Enlarge

Deny

The request is turned down and the flow continues along its refused path. The interface states that every flow has a refused path.

Time out

The request expires and continues along the flow’s timed out path. The interface states that only some flows have a timed-out path.

1. 1Open If nobody responds.
2. 2Review the process risk.
3. 3Choose Deny when the safe fallback is to refuse the action.
4. 4Choose Time out only when the flow has a defined timed-out path.
5. 5Confirm that the receiving flow handles the selected outcome.
6. 6Review the Summary panel.

Enlarge

• The Channels tab records a preferred delivery order.
• No channels are configured in the state shown.
• A channel name can be entered and added.
• The interface states that preferences are saved but not yet acted on.
• Approvals are currently answered from the Approvals inbox.

Enlarge

Environment

The screenshot shows an example environment name. Treat it as demonstration data, not as a default environment.

Add a channel

Adds the place through which users or systems reach the solution.

Add a worker

Adds the worker intended to respond through the environment.

Additional resources

The top Add controls show resources such as Provider, Agentic Worker and Capability.

Wiring assistant

A control offered by the environment. Its internal workflow is not shown, so it is not documented here.

Deploy environment

Starts the environment deployment process after the required resources and connections have been prepared.

Channel
   ↓
Worker
   ↓
Provider and approved capabilities
   ↓
Deployed environment

1. 1Open Deploy.
2. 2Open the intended non-production environment.
3. 3Review the environment name.
4. 4Select Add a channel.
5. 5Add the worker intended to handle that channel.
6. 6Add any required provider or capability resources.
7. 7Connect the resources according to the environment design.
8. 8Review the wiring.
9. 9Use the Wiring assistant where appropriate.
10. 10Select Deploy environment.
11. 11Complete the deployment prompts presented by the product.
12. 12Perform a controlled test after deployment.

1. 1Complete worker and flow design.
2. 2Run direct worker tests.
3. 3Run end-to-end Flow tests.
4. 4Resolve the project issue count.
5. 5Complete the readiness check.
6. 6Save the accepted project state as a version.
7. 7Publish Agentic Workers locally where a Flow must select them.
8. 8Confirm approval policies and Policy IDs.
9. 9Test Human Approval paths using safe data.
10. 10Open the target non-production environment.
11. 11Add channels, workers and supporting resources.
12. 12Review environment wiring.
13. 13Deploy the environment.
14. 14Complete a post-deployment test.
15. 15Obtain the required business approval before production use.
16. 16Repeat the controlled process for the production environment where available.

Edit draft
   ↓
Test changed behaviour
   ↓
Run nearby regression tests
   ↓
Complete readiness check
   ↓
Save as a new version
   ↓
Republish affected worker where required
   ↓
Review environment wiring
   ↓
Redeploy
   ↓
Complete a post-deployment test

1. 1Make the change in the editable draft.
2. 2Test the changed scenario.
3. 3Retest related paths.
4. 4Run the readiness check.
5. 5Record a new version.
6. 6Republish any Agentic Worker whose published configuration changed.
7. 7Review approval policies when the change affects a sensitive action.
8. 8Review the target environment.
9. 9Redeploy using the supported deployment process.
10. 10Confirm the solution still behaves correctly.

• The correct workspace is active.
• Priority worker tests pass.
• Important Flow branches pass.
• Missing and invalid inputs are controlled.
• The project issue count is resolved.
• The readiness check succeeds.
• The accepted state is saved as a version.
• Required Agentic Workers are published locally.
• Store publication is used only when intentionally required.
• Approval policies use the correct immutable Policy IDs.
• Requester self-approval matches the business control.
• Approval levels contain the correct roles and approvers.
• No level accidentally requires zero approvals.
• Escalation timing is intentional.
• The no-response outcome matches a valid flow path.
• Operators know to use the Approvals inbox.
• The deployment environment contains the required channel and worker.
• Required providers and capabilities are present.
• The environment wiring has been reviewed.
• A non-production deployment was tested.
• Production authorisation has been obtained separately.
• No real customer data was used in unsafe testing.