Copilot Studio Real-World Agent Publishing: From Development to Production | Day 96

Day 96 of 365 Days of Copilot Studio follows an illustrative HR agent from development to production. Imagine an agent designed to help 5,000 employees with leave policies, benefits and HR support. The goal is to make it useful and accessible while protecting employee information.

From build to business

The publishing journey has six practical stages: build, test, publish, connect, deploy and monitor. Publishing an agent version is one step in the journey; a production rollout also requires channel setup, appropriate access, communication and support.

Define what the HR agent should do

Before release, agree on the questions the agent is expected to handle. For this example, HR owns the leave and benefits policy content, while the technical team owns the agent and its integrations. Employees can ask about policies and find the right support channel. A personal leave balance requires an approved connection to an authoritative HR system and access appropriate to the signed-in employee; a general policy document alone cannot provide that answer.

Write down what is outside the first release, such as making changes to employee records or answering questions that require an HR specialist. Define a clear handoff for sensitive cases and questions the agent cannot answer. The 5,000-employee audience is a planning scenario, not proof that the agent or its dependencies can support that load.

Build and validate in controlled environments

Build and configure the agent in development. Identify its audience, approved knowledge sources, actions, dependencies and owners. Move the solution through your organization’s release process into test or user acceptance testing (UAT), then production. Check environment-specific connections, credentials and settings at each stage.

Invite HR and representative employees to test common questions, ambiguous requests, missing information and escalation to human support. Verify that answers reflect current policies and that any action produces the intended result. Record defects, resolve them and obtain the agreed UAT approval before release.

Run a practical UAT

Prepare expected outcomes with HR before testing. Use approved test accounts and synthetic data where possible; avoid placing real employee details in test conversations unless the environment and process are approved for them.

For each test, record the account and environment used, the observed result, the expected result, the defect owner and the decision to pass or retest. Repeat critical journeys in the production channel after release using an approved smoke-test account.

Publish and connect Microsoft Teams

Publish the approved agent version in the production environment. Configure the Teams channel and follow the applicable organizational app approval and distribution process. Share it with the intended users or groups, then test the experience in Teams with representative accounts. Confirm that users can find the agent and that conversations and actions work in the actual channel.

Configure authentication appropriate to the audience and review permissions for the agent, knowledge sources and connected services. Verify which identity actions use and test both allowed and denied access. An HR agent must not expose one employee’s private information to another simply because it is reachable in Teams.

Prepare the production release

1. Review the release: identify the approved agent version, its dependencies, the business owner, the release owner and the acceptance decision.
2. Check production configuration: verify connections, environment settings, knowledge sources and access with the responsible owners. Confirm that production points to the intended systems.
3. Publish and set up Teams: follow the organization’s channel, app approval and distribution process. Allow time for any required reviews.
4. Smoke-test the live experience: use authorized accounts to find the agent, ask a policy question, exercise an approved action if present, and check a denied-access case and support route.
5. Make the release decision: record the test results and decide whether to proceed, pause or use the documented recovery process if a critical check fails.

Keep a record of the version and configuration released, the deployment time, test results and support contacts. This makes it easier to investigate an issue and coordinate recovery. The exact promotion and recovery steps depend on the solution, environment and channel configuration.

Release, monitor and improve

Start with a controlled audience and expand once the team has reviewed early feedback and operational results. Tell employees what the agent can and cannot do, how to reach HR, and how to report a problem. Assign a business owner and support contacts before launch.

After release, review available usage and conversation analytics, unresolved requests, errors, feedback and connected-system health. Triage issues, keep policy content current, test fixes and republish changes through the same release process. Plan how to respond to an incident or recover from a problematic release.

Plan the first weeks after launch

Begin with a pilot group representing different employee needs and locations, then expand in agreed stages. Set the pilot’s success criteria before launch: for example, whether critical journeys work, policy answers are accepted by HR, and support teams can respond to reported issues. Review actual traffic and connected-service capacity before extending access to all 5,000 employees.

Agree who reviews feedback, how frequently policy owners check content, and where incidents are recorded. A useful review considers adoption, unanswered questions, response quality, failed actions and user feedback together. Protect conversation data according to organizational policy and grant monitoring access only to appropriate personnel.

Common mistakes to avoid

• Skipping UAT: a successful maker test does not establish that employees can complete real tasks.
• Assuming sign-in is enough: check authorization in each knowledge source and downstream service, including denied cases.
• Publishing without channel verification: validate Teams availability, organizational approval and sharing with actual user roles.
• Leaving ownership unclear: name people responsible for policies, technical support, access and release decisions.
• Stopping at launch: monitor feedback and failures, maintain content and retest changes before publishing updates.

Production readiness checklist

• Representative responses, actions and error paths have been tested.
• Authentication and permissions have been reviewed with representative users.
• Teams channel configuration, app approval and intended sharing have been verified.
• Business users have completed UAT and provided the required approval.
• Production connections, knowledge sources and environment settings are validated.
• Monitoring, support ownership and an escalation path are in place.

A careful launch makes the agent available to the right people and gives the team evidence to improve it. For broader operational planning, continue with Day 95: Scaling Enterprise Copilots.