Approval and urgent-ticket cards post to the Teams channels your team already watches — and the technician who owns the ticket gets @mentioned, so nothing sits unclaimed while an approval quietly counts down.
Your Teams channels can receive approval and urgent-ticket cards on their own — connect a channel and they start arriving, no Microsoft consent required. The Teams integration is the extra step that turns a card in a shared channel into a personal ping for the technician who owns the ticket.
When a Human-in-the-Loop approval expires before anyone claims it, the ticket falls back to the service desk. DaemonLayer @mentions the technician assigned to the ticket, so the right person is notified personally — even though the card sits in a shared channel.
It matches on email and caches the result, so every mention after the first is instant.
There's no Azure app to register. You grant a shared enterprise app consent once, as a Global Admin, in your own MSP tenant — never in a client's. It asks for a single read-only permission and nothing else, so it's a clean line item on any security review.
It never reads mailboxes, posts messages, or touches your channels directly.
Notification routing
Team channels connect a Teams or Slack channel to the queues that team owns. System alerts still reach your notification email and the in-app bell. It all lives under Notification Settings.
Common questions about this integration
No. DaemonLayer provides a shared enterprise application. You grant it consent in your tenant with a single Global Admin click — the same one-click admin-consent model as the Microsoft 365 Email integration. No client ID, secret, or tenant ID is entered by hand; DaemonLayer records your tenant ID from the consent response.
No — this integration is optional and additive. Teams channel delivery works on its own: you connect a channel by pasting its incoming webhook URL under Notification Settings, and approval and urgent-ticket cards post there without any Microsoft consent. The Teams integration only adds the ability to @mention the assigned technician on those cards.
No. Your client M365 connections (password resets, onboarding, and so on) authenticate against a customer's tenant. This one authenticates against your own MSP tenant and is used only to look up your technicians' Microsoft identities so they can be mentioned. It never touches client tenants.
A single application permission: User.ReadBasic.All. That lets DaemonLayer resolve a technician's email to their Entra Object ID from their basic profile. It never reads mailboxes, never posts messages, and never accesses Teams channels directly — card delivery happens entirely through the incoming webhook URLs you configure.
Mentions are matched by email: the assignee's PSA email must match a user in your Entra tenant. If the integration isn't connected, the assignee has no email on record, or the lookup fails, the card still posts — just without the mention. A card is never delayed or dropped because a mention couldn't be resolved.
Approval cards keep posting to your channels, without mentions. Technician Object IDs already cached remain and are still used; they're only refreshed while the integration is connected. To restore mentions after revoking consent, click Reconnect Microsoft 365 to grant consent again.
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →
