Copilot Studio End-to-End Deployment Demo | Day 97

Day 97 of 365 Days of Copilot Studio follows an illustrative HR agent from development to test and production. The example builds on Day 96: Real-World Agent Publishing and shows how a solution and a controlled release process fit together. It is a walkthrough, not a claim that a deployment was performed.

The scenario and prerequisites

The HR agent answers questions about approved leave and benefits policies and directs employees to HR support. The release team has a development environment, a test environment for user acceptance testing (UAT), and a production environment. HR owns policy content and acceptance; a technical owner manages the solution, connections and release; support owners handle incidents after launch.

Before starting, confirm the required environment access, Dataverse and solution prerequisites, licensing, security roles, and an approved pipeline or equivalent deployment process. The exact options and permissions depend on the tenant and configuration. Use test accounts and approved sample data; avoid exposing employee information in development or UAT.

1. Build and test in development

Configure the agent’s instructions, topics, approved knowledge sources and any supported actions. Test common policy questions, ambiguous requests, failure messages and the route to a human. Verify authentication and check both allowed and denied access. If the agent provides a personal leave balance, that feature needs an approved connection to an authoritative system and authorization for the individual employee; policy documents alone cannot supply personal balances.

Record the solution version, intended changes, dependencies, owners and acceptance criteria. Review the identities used by integrations and avoid storing secrets in solution configuration or release notes.

2. Package the agent in a solution

In the development environment, create or select the appropriate custom solution and include the agent and its required solution components. Review related topics, flows, connection references, environment variables and other dependencies that apply to the design. Some configuration or external resources may require separate preparation: inventory and validate them instead of assuming every dependency moves with the package.

Microsoft notes that agents are created within Power Platform solutions and that components added to an agent must also be added to the unmanaged solution before export where applicable. Use the organization’s managed-solution and versioning strategy for target environments. See Microsoft’s solution import and export guidance.

3. Prepare environments and deploy to test

Confirm that the target environment has the required access, dependencies and data policies. Map each connection reference to the correct test connection and supply environment-specific values where prompted. Check that knowledge sources are reachable by the intended identity and that the agent points to test systems rather than production systems.

Use the configured Power Platform pipeline to deploy the solution to test, or follow the approved manual export and import process if a pipeline is not available. Review the deployment result and resolve errors before UAT. Microsoft documents that a pipeline deploys the same solution artifact through its stages in sequence; later development edits do not silently replace the artifact already deployed to test. See Run pipelines in Power Platform.

4. Validate with business users

Agree expected outcomes with HR before testing. Capture the account, environment, result, defect and retest decision for each scenario. Use the same approved artifact for the subsequent release through the pipeline.

Resolve critical defects, retest and record HR approval before promoting the release. A successful import alone does not show that answers, actions, permissions or the intended user experience work.

5. Promote and validate production

Promote the approved artifact through the configured pipeline stage. Supply and verify the production connections and environment values; confirm source access, authentication, security roles and any external setup. Review the deployment result and identify the version deployed. Check that production connections point to the intended systems and use appropriately authorized identities.

Run an approved production smoke test with representative accounts. Check a common policy question, any permitted action, a denied-access scenario and the support route. For actions that modify data, use an approved safe test and verify the actual outcome. If a critical check fails, pause the rollout and follow the documented recovery process; avoid blindly retrying a write that may already have succeeded.

6. Publish and launch in Microsoft Teams

Open the production agent, complete final checks and publish the approved version as required. Configure the Teams channel and follow the organization’s app approval and distribution process. Publishing the agent, deploying its solution and making it available to the intended Teams users are distinct steps. Test the published agent in Teams with representative users, including sign-in and access to the correct knowledge and actions.

Start with a pilot audience, explain the agent’s scope and how to contact HR, and expand only after reviewing results. Monitor available usage, unresolved requests, errors and feedback. Assign owners to keep knowledge current, respond to incidents and release fixes through the same controlled process.

Release checklist

• The agent and required components are included in the solution and dependencies are inventoried.
• Target connections, environment values, access and external resources are verified.
• UAT covers common questions, security, failures and human support; approval is recorded.
• The approved solution artifact is deployed to production and smoke-tested.
• The production agent is published and Teams approval, distribution and access are checked.
• Support contacts, monitoring, a recovery plan and a staged rollout are ready.

Worked example: prepare the HR agent release

Imagine the development agent answers questions from an HR policy site and uses a flow to direct employees to a support request form. The team plans a release named HR Agent 1.0. HR checks the policy wording, the agent maker reviews topics and instructions, and the platform team reviews the target environment and connections. This is an example plan; it does not represent a deployment or a test already performed.

1. List the agent, its topics and the support flow in the solution inventory. Record the policy source and any external resources separately if they are not carried by the solution.
2. Record which test and production connections will be used, which identity each connection uses, and who can maintain it. Confirm the support URL or other environment-specific configuration in each target.
3. Agree on the expected answers for common leave-policy and benefits questions with HR. Define how the agent should respond when the policy is unavailable or an employee asks about personal information.
4. Deploy to test, resolve any missing dependencies or connection prompts, and run the agreed UAT cases with representative accounts. Record observed results and approval.
5. Promote the approved artifact, validate production connections and policy access, publish the production agent, and verify Teams distribution with a pilot account.

If the test results require a change, return to development and run the updated solution through the release process again. A later change in development does not automatically alter the artifact already submitted to a pipeline.

Keep an environment configuration record

Keep this record free of passwords and tokens. Store secrets in an approved secure location and follow your organization’s access and rotation practices.

Troubleshoot common deployment problems

• Import reports a missing dependency: review the solution dependency details, add or provision what is required, then create and test a corrected release. Avoid assuming the agent alone includes every related component.
• A flow works in development but fails in test: inspect the target connection mapping, connection owner, permissions, environment values and run history. Confirm the flow is using the intended test system.
• Answers are missing or outdated: check the target knowledge source, its content and the identity used to access it. Test the same question with an authorized representative account.
• The agent is published but unavailable in Teams: verify the channel configuration, organization’s app approval and distribution rules, and the user’s access. Retest in the actual channel.
• UAT and production behave differently: compare the released artifact, configuration, identities, knowledge and downstream systems. Record the differences before changing production.

After launch: ownership and recovery

Set a review cadence for unresolved conversations, failed actions, usage and employee feedback. HR should own policy corrections; technical support should own connection and release incidents. Track a reported issue through diagnosis, correction, test and republishing, with the affected audience informed through the organization’s support process.

Before launch, document how the team will restrict access or restore service if a release causes a serious problem. The correct recovery steps depend on the solution and channel; rehearse them in a safe environment and verify the resulting user experience. Preserve an incident record and confirm whether consequential actions already completed before repeating them.