How to Implement Multi-Touch Attribution in Salesforce
August 22, 2025
Salesforce Microsoft Teams Integration: The Complete Setup Guide
A six-figure opportunity closes on a Tuesday afternoon. The rep updates the record, and then goes to lunch.
Nobody else knows for three hours.
Not because anyone did anything wrong. The information was sitting in Salesforce the whole time, exactly where it belonged, and the people who would have acted on it were in Teams, where they spend their day. Two systems, both working, neither talking.
Connecting them is not a hard project. It is a project with one step that surprises people, one dependency you cannot resolve on your own, and a handful of places where a first attempt quietly fails. This guide covers all of it: what the setup actually involves end to end, what you need lined up before you start, and where teams get stuck.
At its core the integration is simple. When something happens in Salesforce, a message appears in Teams. A channel, a group chat, or a direct message, with whatever fields and formatting you choose, triggered from Flow. What varies between the available options is how much control you get and how much of it needs a developer.
We build one of those options, and I will be straight about where it fits further down. First, the setup.
What You Need Before You Start
Three things, and one of them is the reason projects like this stall.
You will need your Teams administrator for one step. Everything else here is yours as a Salesforce admin. Creating the bot in Teams is not, because it happens in the Microsoft side of the house and requires permissions you almost certainly do not have.
This is worth knowing on day one rather than discovering it on step three. It is a short task, but it means booking time with someone in IT, and if your IT team works on tickets with a queue, that queue is your real timeline. Send them everything they need in one message instead of three, and you will save a week.
You will need to create a Salesforce Site. This one surprises almost everyone, because it is not obvious why a notification integration needs a public Site at all. The reason is that the connection runs both ways. Teams needs somewhere to send information back to Salesforce, and a Site is how Salesforce exposes that endpoint.
You are not publishing anything to the internet in any meaningful sense. You are opening a door that only the bot walks through.
Do the first run in a sandbox. Not because production is fragile, but because your first notification will be wrong in some small way and you would rather find that out privately. Our covers what carries across and what does not.
The Six Steps, and What Each One Is Actually For
Here is the whole sequence. Each step links to the detailed instructions, so what follows is the arc rather than the clicks: what you are doing, who does it, and what goes wrong.
1. Install the package
into your sandbox first.
The decision here is who you install for. "Install for Admins Only" is the safe default and the one I would pick, because you can grant access deliberately in step six rather than working out later why a user sees something they should not.
Nothing much goes wrong at this step.
2. Create a Salesforce Site
, mostly because they were not expecting it.
You are creating the endpoint that Teams talks to. The Site needs to be active, and its guest user needs access to the right pieces of the package. If either of those is off, nothing fails loudly. You just won't get channel records populated in Salesforce, needed when you send your first test, which is a miserable way to debug.
So: confirm the Site is active before you move on, and confirm the guest user profile has what it needs. Two minutes now, versus half an hour of confusion in step five.
3. Create the bot in Teams
This is the one you hand off.
What you are asking for is a bot registration in Microsoft, pointed at the Site endpoint you just created. Your Teams admin will not need to understand Salesforce to do it, and they will not need to keep doing it. It is one task, once.
Make it easy for them. Send the endpoint URL, a link to , and a sentence about what the bot will and will not have access to, because that is the question they are going to ask anyway. Getting ahead of it turns a back-and-forth into a yes.
4. Add the bot to a team
, which tells you something.
Creating the bot and adding it to a team are separate things, and the bot cannot post anywhere it has not been added. If your first notification goes nowhere, this is the first place to look. It is also the step to repeat later, quietly, every time someone asks why the new channel is not getting messages.
5. Send a test notification
A successful test is unglamorous: you trigger it, and a message appears in the channel within seconds. If nothing appears, work backwards through the chain rather than changing things at random. Is the bot in that specific team? Is the Site active? Did the Flow actually run?
That last one catches more people than the integration itself ever does. Check your Flow ran before you assume the notification failed, because a Flow with entry criteria that did not match looks identical to a broken integration from where you are standing.
6. Assign permissions
because by now everything works, for you.
You installed the package, so you have access. Your users do not until you give it to them. If the integration works perfectly in your testing and does nothing for the first person you hand it to, start here.
Then repeat the whole thing in production. It goes faster the second time, and your Teams admin's part is already done.
Where People Get Stuck
Four patterns, in roughly the order we see them.
Nothing appears, and everything looks configured. Almost always the bot is not in the team you are posting to, or the Flow did not run. Check both before you touch anything else. The integration itself failing silently is rare; the two things either side of it failing silently is common.
The bot was added to the Team, however channels are not selectable in Salesforce. Sometimes Microsoft's webhooks are not sent to Salesforce. Simply remove the bot from the Team, wait a few minutes and then try again. Works almost every time.
It works in sandbox and not in production. Usually the Site, because that is per-org and does not travel. Occasionally permissions, for the same reason.
It worked, and then it stopped for one channel. New channel, bot never added. This one recurs forever, and it is worth telling your team what it looks like so they can spot it themselves.
Comparing the Options
Not all integrations are created equal. Here is a closer look.
UnofficialSF Integration
Pros: Free and open source.
Cons: Limited customization, fewer notification types, harder to adapt to complex business needs, can require developer help to get started.
iPaaS Solutions (e.g., Power Automate)
Pros: Highly flexible, connects multiple systems beyond Salesforce and Teams.
Cons: More technical expertise needed, ongoing costs, and potential performance overhead.
Third-Party Apps (like our own)
Pros: Purpose-built, rich feature set, admin-friendly, designed for Salesforce Flow.
Cons: Requires separate licensing, though often offset by the productivity gains.
Many organizations begin with the free option and hit its limits later. That is a perfectly reasonable way to find out what you need, and if UnofficialSF covers your case, use it.
What You Can Build Once It Is Running
The setup is the boring part. What it unlocks is the reason to do it.
With our you can send notifications to channels, direct messages, or group chats, personalize them with merge fields and mentions, format them with Markdown, manage Teams channels from Salesforce, show real-time user presence on a record, and retrieve messages and threaded replies for context. All of it from Flow, without code.
What that looks like in practice:
- An posting to the sales channel within seconds, tagging the rep and linking the record. The three-hour gap from the top of this post, closed.
- A reaching the support channel before it reaches anyone's inbox.
- A pinging the SDR who is going to follow up on it.
- , so a rep can see whether the specialist they need is available before they send a message into the void.
We have watched nonprofits use it to celebrate major gifts in real time, which was not a use case we designed for and is now one of my favorites.
Going Deeper
Once it is live, the things worth learning next are , because a wall of unformatted text gets ignored no matter how important it is, and mentions, because tagging a person converts a notification into an assignment.
Then capturing message IDs, which is how you build follow-up automation on top of a message you already sent.
If you want to try it, there is a on the AppExchange, and the is public whether you install anything or not. Read the setup steps before you decide. If the Teams admin dependency is a dealbreaker for your org, better to know that now than after you have spent an afternoon on it.
Getting Salesforce into Teams is not really an integration project.
It is deciding what your team should not have to go looking for.
