Need End-to-End Guidance for Integrating a UiPath Conversational Agent with Microsoft Teams

Help Chatbots
, , , ,
1

Hi everyone,

I’m working with UiPath Conversational Agents and would like to integrate one with Microsoft Teams. I went through the official documentation on the Dedicated Microsoft Teams App:

I have a few questions and would appreciate guidance from anyone who has implemented this successfully.

Questions

  1. Is there an end-to-end, step-by-step guide for configuring a Conversational Agent with Microsoft Teams?

  2. Besides creating a Dedicated Teams App, are there any other supported methods to access a Conversational Agent from Microsoft Teams?

    • Using the UiPath Autopilot app?

    • Microsoft Copilot integration?

    • Microsoft Bot Framework or Azure Bot Service?

    • Embedding or any custom integration?

  3. What are the prerequisites on both the UiPath and Microsoft Teams sides?

  4. Is any Azure configuration required, or does UiPath handle all Azure Bot provisioning automatically?

  5. What Microsoft Teams admin permissions are required to upload and publish the app?

  6. Can multiple Conversational Agents be exposed within the same Teams environment? If so, what is the recommended approach?

  7. What are the differences, advantages, and limitations between using the UiPath Autopilot for Teams app and a Dedicated Teams App?

  8. How can authentication and user access be managed for different users or departments?

  9. What are the common issues encountered during deployment, and how can they be resolved?

  10. Are there any best practices or architecture recommendations for enterprise deployments?

Scenario

For example, suppose I have a Medical Equipment Support Conversational Agent that can:

  • Answer user queries.

  • Execute UiPath automations.

  • Retrieve information from Context Grounding.

  • Call APIs and workflows.

I want users to interact with this agent directly from Microsoft Teams. Which deployment approach would you recommend, and why?

If anyone has implemented this in a production or enterprise environment, I would really appreciate it if you could share your architecture, setup steps, screenshots, or lessons learned.

Thank you!

2

Hi Vikas,

for the scenario you described i would go with the Dedicated Teams App, not Autopilot. Autopilot is the shared entry point, its great when you just want people asking questions to whatever is available, but you dont get a persistent context for that specific agent. Since your medical equipment agent runs automations and uses context grounding, having its own app keeps the conversation scoped to it and the users know exactly what they are talking to

on the azure part, the bot provisioning is handled on the UiPath side when you create the dedicated app, you dont need to stand up an Azure Bot Service yourself. What you do need is somone with Teams admin rights, because uploading a custom app is blocked by default in most tenants. In my experience thats where these projects get stuck for a week, so i would check the custom app upload policy before anything else

about multiple agents, the pattern that I think works better is one app per agent instead of trying to make one app route to several. Its cleaner for permissions too, you publish each app to the specific teams or groups that should use it, so the department separation you asked about comes basically from who you install the app for

one thing worth planing early, decide what the agent should answer when it doesnt know. In teams people ask anything, and an agent that runs automations answering out of scope stuff generates weird tickets. Setting that guardrail in the prompt saved me a lot of noise

hope this helps :slight_smile:

3

Step 0: Decide the Deployment Pattern (do this first, not last)

If this is true Choose
1–2 agents, internal pilot, speed matters Autopilot for Teams
Agent has a defined audience (HR, IT, Finance) and needs its own brand Dedicated Teams App
Front door must be M365 Copilot; UiPath is the specialist backend Copilot / agent-to-agent
You need custom channel logic Teams-native options can’t express Custom bot via Bot Framework (last resort - you own the lifecycle)

image
image1536×1024 171 KB

Step 1: Prerequisite Gate (block the project until all are green)

UiPath side

  • Automation Cloud tenant with Agents / Conversational Agents enabled and licensed
  • Roles: you need agent create/publish rights; the deploying identity needs tenant-level access
  • Target Orchestrator folder(s) created, with the processes/queues the agent will invoke already published and tested standalone
  • Integration Service connections created in the folder scope the agent will run under, not personal scope

Microsoft side

  • Named Teams Administrator identified and committed (this is the #1 schedule risk)
  • Org-wide app setting “Allow custom apps” = On, or an exception approved
  • A security group per intended audience already exists in Entra ID (HR-Agent-Users, etc.) create these now, not at rollout
  • M365 Developer tenant provisioned for dry runs

Cross-cutting

  • Automation Cloud federated with the same Entra ID tenant as Teams (SSO). If it isn’t, stop and fix this first every downstream auth problem traces back here.

Step 2: Build and Harden the Agent (before any Teams work)

  1. Author the agent in UiPath: system prompt, tools, contexts (Context Grounding indexes), escalation paths.
  2. Set an explicit fallback behavior what it says when it can’t answer, and who it points to. Teams users judge harshly on the first failure.
  3. Constrain the toolset to least privilege. Every tool = a capability exposed to whoever can open the chat.
  4. Test exhaustively in the UiPath preview/test panel: happy path, ambiguous input, out-of-scope input, tool failure, and a hostile prompt-injection attempt.
  5. Publish the agent. Note the version Teams binds to a published version, not your draft.

Gate: do not proceed until the agent is correct in the UiPath test chat. Teams adds zero diagnostic value while you’re still fixing agent logic.

Step 3: Generate the Teams App Package

  1. In the agent’s channel/deployment settings, select the Microsoft Teams / Dedicated Teams App option.
  2. Set the app identity properly this is user-facing and expensive to change later:
    • Name: functional, not technical. “Ask HR” beats “CA_HR_Prod_v2.”
    • Short + long description: state scope and limits (“Answers benefits and leave policy questions. Cannot process payroll changes.”)
    • Icon: color + outline versions, per Microsoft’s spec.
  3. Generate/download the app package (.zip containing the manifest and icons).
  4. Version and commit the package to source control. Treat it as a release artifact with a changelog. Republishing a package your team can’t reproduce is a real outage scenario.

Step 4 Dry Run in the Developer Tenant

  1. In the dev tenant’s Teams Admin Center, enable custom app upload.
  2. Sideload the package via Teams → Apps → Manage your apps → Upload a custom app.
  3. Validate: install, first-run sign-in/consent flow, three real questions, one out-of-scope question, one tool-invoking action end to end.
  4. Confirm the audit trail: the run appears in UiPath with the correct user identity attributed, not a generic service account.
    If step 4’s identity attribution is wrong, your compliance story is broken. Fix before production.

Step 5 Production Publish (Teams Admin Center)

  1. Teams apps → Manage apps → Upload new app upload the package.
  2. Leave the app Blocked initially, or publish it with a permission policy that includes nobody. Publish first, expose second.
  3. Create an App Permission Policy per audience, allowing only this app’s audience group.
  4. Create an App Setup Policy if you want the app pinned to the Teams left rail for that group (drives adoption dramatically).
  5. Assign policies to the Entra security group from Step 1.
  6. Wait. Policy propagation can take several hours, occasionally up to 24. Do not debug during this window you will chase ghosts.
  7. Unblock the app for the pilot group only.

Step 6: Access Control Design (the part people skip)

Layer it deliberately - each layer answers a different question:

Layer Controls Managed by
Teams app permission policy Who can see and install the agent Teams Admin
Entra SSO / federation Who the user is to UiPath Identity team
UiPath group + role assignment Whether that identity is entitled at all UiPath Admin
Folder scoping Which processes/connections the agent can reach UiPath Admin
Agent tool definitions What the agent is capable of attempting Agent owner

Departmental pattern: one agent per department → one Teams app per agent → one Entra group per app → one UiPath folder per department. Clean 1:1:1:1 mapping. It looks like more objects, but it makes every access question answerable in one lookup, and it makes offboarding a single group removal.

Anti-pattern: one mega-agent with tools for every department, gated by prompt instructions. Prompts are not an authorization boundary. Do not do this.

Step 7: Rollout and Operations

  1. Pilot: 10–25 users, 2 weeks. Collect transcripts, not just satisfaction scores read what people actually asked.
  2. Tune: most day-one failures are scope/expectation mismatches, fixable in the system prompt and description.
  3. Widen by adding groups to the permission policy. Never by removing the policy.
  4. Monitor: agent run history and Orchestrator job logs for failures; watch tool error rates and escalation frequency as your leading indicators.
  5. Change process: agent logic changes → republish agent (usually no Teams action). Name/icon/description/manifest changes → regenerate package, upload new version in Admin Center. Know which bucket a change falls into before you promise a timeline.

Troubleshooting Runbook

Symptom Root cause Fix
Can’t upload app Custom apps disabled org-wide Teams Admin Center → org-wide app settings
Uploaded, users can’t find it Permission policy not assigned, or still propagating Verify policy assignment; wait up to 24h
Bot replies with auth error Teams identity has no matching UiPath user Federate Entra with Automation Cloud; invite/assign the user
Works in UiPath test chat, not Teams Draft ≠ published version Republish the agent
Tool calls fail only from Teams Connection created in personal scope, not folder scope Recreate the connection at folder level
Sign-in loops inside Teams Conditional Access / tenant restriction policy Work with identity team on a CA exclusion or compliant-device path
Cosmetic changes not reflected Manifest change requires new package version Regenerate and re-upload

Enterprise Architecture Recommendations

  • Environment separation: separate UiPath tenants for Dev/Test/Prod, and a separate Teams dev tenant. Never test manifest changes in the production Teams tenant.
  • Agent registry: maintain a table of agent name → owner → UiPath tenant/folder → Teams app ID → audience group → data sources touched. Auditors will ask; you want a lookup, not an investigation.
  • Ownership model: every agent has a named business owner (content correctness) and a technical owner (runtime). Unowned agents rot and become a support liability.
  • Publishing governance: restrict who can publish agents to Teams. Without this you get agent sprawl within a quarter, and users lose the ability to tell which agent to ask.
  • Data boundary review: for each agent, document which systems its tools and grounding indexes reach. This is your real risk surface, not the Teams channel.
  • Lifecycle: define a decommission path deprecate the Teams app, block it, notify the audience, then unpublish the agent. Orphaned bots that fail silently damage trust in the whole program.

Hope this is helpful. Cheers!