Skip to main content
The Microsoft Teams integration puts your helpdesk inside your clients’ Teams. Employees describe their problem in a 1:1 chat with a bot that carries your brand, and the agent files the ticket in your PSA. Every ticket gets its own named group chat where the requester and your technicians talk through the ticket without leaving Teams.
Microsoft Teams is connected in MSP Settings → Integrations. Its configuration (branding, app package, ticket intake routing, and tenant links) lives on the integration’s detail page and is also available from MSP Settings → Teams.

​
Prerequisites

  • A connected PSA that supports ticket intake. Teams intake files tickets in ConnectWise Manage or HaloPSA (whichever your MSP has connected).
  • The Microsoft 365 Tenant ID of each client you want to enable
  • For the auto-setup path: a tenant admin willing to grant admin consent and complete a sign-in that publishes the app.

​
How to connect

Connecting the integration is the ON switch for the entire Teams surface: app package, branding, tenant links, message intake, and ticket chats all require it.
1

Connect the integration

In MSP Settings → Integrations, find the Microsoft Teams card and click Connect. There are no credentials to enter. The bot identity is provided by Rallied.
2

Set your branding

Go to MSP Settings → Teams and click Branding. Set the app display name (defaults to your MSP name), an accent color, and your logo. One logo upload produces both icon sizes Teams requires (192×192 color and 32×32 outline).
3

Link each client's tenant

In the client table on the Teams page, click Link tenant and paste that client’s Microsoft 365 Tenant ID. If you have the Microsoft 365 integration connected, tenant IDs are pre-filled from its GDAP sync and you just confirm each link. The row shows Linked — awaiting install. Linking is what ties messages from that tenant to the right client. Rallied drops messages from unlinked tenants.

​
Setup wizard and guided tour

After you connect the integration, a setup wizard walks you through the remaining steps. The wizard opens automatically for new connections and is mandatory until the first client is fully provisioned. The steps are:
  1. Branding (optional): set display name, accent color, and logo.
  2. Ticket routing (required): pick the PSA, board, and optional new-ticket status where intake tickets are created.
  3. Link your first client (required): choose a client and link their Microsoft 365 tenant.
  4. Publish and admin consent (required): grant admin consent and publish the app to the client’s tenant catalog.
After you finish the wizard, a guided tour spotlights the next client’s row on the configuration tab. This reminds you to link and grant consent for each additional client. The tour runs once and marks itself seen. You can always return to any unfinished setup from the Continue setup banner on the integration detail page.

​
Tenant setup: auto-setup and manual

After linking a tenant, choose how to get the app into the client tenant. Each row supports two paths: Click Admin consent on the row. The consent screen asks the client’s tenant admin to approve the app. After consent is verified, the admin is signed in a second time so Rallied can publish the white-labeled app package into the tenant’s catalog (Microsoft requires this sign-in for catalog writes). The app is then available to users. If consent succeeds but publishing fails, the row shows Publish failed with the error. Click Republish to retry (for example, after a network error or when you update branding). If the app was already published and you bumped the package version, click Publish update to push the new version. You can also copy the consent link or the publish link from the row’s More actions menu to forward to the client’s admin instead of opening it yourself. If the app gains new permissions later (for example, chat rename), already-consented tenants need Re-consent to grant the new scopes. This option is also available in More actions.

​
Manual upload

Click Download app to generate one white-labeled Teams app package (a .zip) that carries your brand to every client tenant. Send the package to the client’s Teams admin. They upload it to their tenant’s app catalog and roll it out to their users. When the app is installed, the row flips to Installed automatically.
If you change branding later, tenants using auto-setup get the update on the next Republish or Publish update. Tenants using manual upload need the admin to re-upload a new package with a higher version number.
A row’s Setup column tells you which path is in use: Auto-setup ✓ for consent + published, Manual for the hand-upload flow, Publish failed if consent completed but the publish step did not, or Consented if consent is recorded but the publish is still pending.

​
Ticket intake routing

The Ticket intake section on the Teams configuration page controls where tickets filed from Teams land in your PSA:
  • PSA — which connected PSA receives Teams intake tickets. The selector shows every connected intake-capable PSA. Pick one explicitly or leave it on Automatic to use the first available. If the selected PSA disconnects later, a paused callout appears until you pick again.
  • Board — the board where the agent creates new Teams tickets. With ConnectWise Manage connected, you pick from a live list of your service boards. HaloPSA shows its ticket types.
  • New-ticket status (optional, ConnectWise Manage only) — the status new Teams tickets start in. Leave it on Board default to use the board’s own default, or pick a status to keep Teams intake tickets in a dedicated status. Changing the board clears the status pick, since statuses belong to a board.
  • Ticket type (HaloPSA only, required) — the Halo ticket type for Teams intake. Without it, filing fails.
Click Save intake routing to apply. Saving requires the integrations:write capability. Read-only users see the saved values but can’t change them.

​
How employees use it

​
Filing a ticket

Employees open a 1:1 chat with your branded bot and describe their problem. The bot asks follow-up questions until it knows the affected system, the symptom, and the impact, then files a ticket in your PSA. The requester’s identity comes from their verified Teams sign-in and is attached as the ticket contact automatically. The first reply in every conversation includes an AI disclosure. Employees can also ask “what tickets do I have?” in the 1:1 chat to list their own open tickets. Tickets opened through Teams show a Go to chat button when a dedicated group chat exists.

​
Opening a ticket chat for an existing ticket

If an employee has an open ticket that was filed by email or phone, they can ask to open a dedicated Teams chat for it. The bot creates the chat and sends them a Go to chat link. This only works for tickets that belong to them.

​
The per-ticket chat

When a ticket is created or opened as a chat, Rallied creates a dedicated named group chat through Microsoft Graph. The chat is named #{ticket number} — {summary} and contains exactly two members: the bot and the requester. The chat is a live, two-way bridge to the ticket:
  • Requester writes in the chat — the bot posts the message to the ticket as a client-facing note, attributed to the requester. Only messages from the original requester are relayed; messages from anyone added later are answered with a notice and dropped.
  • A technician or the agent posts a client-facing note on the ticket — the note text appears in the chat, verbatim. Internal notes are never relayed.
  • Ticket status changes — when a ticket moves to a new non-closed status, a status update card appears in the chat.
  • The ticket is closed — the chat is renamed to [Closed] #{ticket number} — {summary} and the bot posts a closing card.