> Workplace notifications through Slack and Microsoft Teams reach users where they spend their workday, enabling faster responses and keeping context in one place.

## Why Slack and Microsoft Teams Notifications Matter

Your application tracks important events, and someone needs to act on them. Email isn't great for time-sensitive updates because people batch-check it throughout the day. [Slack and Microsoft Teams](https://www.courier.com/solutions/ms-teams-slack-channel) work because people keep them open. When your notification lands there, it shows up within seconds.

What makes workplace notifications interesting isn't just faster delivery. It's that people can act right there in the message. A finance manager reviewing an expense report in Teams can click 'approve' without opening your application. The notification becomes part of their workflow instead of an interruption.

Building these notifications turns out to be more involved than expected. Slack and Microsoft Teams use completely different authentication models, message formats, and delivery mechanisms. Slack needs OAuth flows with workspace-specific tokens. Teams requires Azure Bot Framework registration and multi-tenant architecture. You end up maintaining two separate codebases with different rate limiting rules, error handling patterns, and threading models.

![slack notification flow chart](//images.ctfassets.net/z7iqk1q8njt4/5fyDyN4Bs8kmXa0kHsMvrk/fbd69627998ff26216ca19ef01f34d70/Frame_163959.png?w=800)

This guide walks through what makes Slack and Teams notifications work well, how they fit within your overall notification strategy, and the infrastructure you need to make them reliable.

## Workplace Notifications

Most products send notifications through multiple channels. Email for receipts. SMS for urgent alerts. Push for mobile. [In-app notifications](https://www.courier.com/solutions/in-app-channel) for session-based updates. Slack and Teams fill a specific role that other channels can't replicate.

![Cursor slack](//images.ctfassets.net/z7iqk1q8njt4/6izuC7nakaiJPlssQg42fY/4ea3996d23d4308aa576e16931a544ba/Frame_13__1_.png?w=800)

### Greater Visibility

When you send an email about a budget approval, the recipient reads it alone. Send the same notification to Teams, and they can immediately ask colleagues who have context. The notification arrives where coordination already happens. This makes workplace notifications particularly valuable for anything requiring discussion, approval, or group decision-making.

### Interacting with Slack/Teams Notifications

Email and SMS are essentially read-only. Push notifications disappear after dismissal. In-app notifications only reach active users. Slack and Teams notifications persist in searchable history and support rich interactions like buttons, forms, and threaded discussions. You can build workflows where the notification itself becomes the interface for completing tasks.

### Cross-Channel Awareness

When someone clicks "approve" on an expense report in Teams, you don't also email them about it. When they acknowledge an alert in Slack, you don't send a follow-up SMS. This coordination requires infrastructure beyond just calling individual platform APIs.

## The Dual-Platform Reality

You ship Slack notifications, customers use them, then enterprise prospects ask: "Does this work with Microsoft Teams?" The answer determines whether you win or lose certain deals.

The split isn't random. Some teams, like software engineers, prefer Slack's threading model and developer ecosystem. But organizations invested in Microsoft 365 use Teams because it's bundled with their license. Neither platform is going away. Many large enterprises run both simultaneously.

Building Slack notifications gets you access to one set of customers. Building Teams gets you a different set. Building both means maintaining two separate integrations with different authentication patterns, message formats, and delivery models. The technical work roughly doubles, but supporting both becomes table stakes for enterprise sales, similar to how supporting iOS and Android became non-negotiable for mobile apps.

## Essential Components

Professional Slack and Teams notifications require several capabilities working together. Getting one piece right doesn't help much if the others are missing.

### OAuth & Token Management

Each customer workspace maintains its own credentials. You need to handle initial authorization, secure token storage, refresh cycles, and revocation gracefully. When tokens expire or get revoked, you need error handling and user-facing messages explaining what happened. Failure here means no notifications get delivered at all.

### Template Design

Your product team should be able to [design](https://www.courier.com/platform/design-studio) and update workplace messages without filing engineering tickets. This gets complicated because Slack uses Block Kit while Teams uses Adaptive Cards. Neither format is simple. You need a system that handles both, supports variables and conditional content, and previews messages before sending. Most teams end up building a custom abstraction layer or accepting the maintenance burden of dual templates.

![template for slack](//images.ctfassets.net/z7iqk1q8njt4/7m0VG9DrBLr3XA2bRpGfE3/d60a2566afab9d3c6bd46bd2edc6dcf7/Screenshot_2025-09-05_at_11.25.46â__AM.png?w=800)

### Routing & Delivery Logic

When you begin to add multiple channels, getting messages to the right place is not a trivial problem. When you layer in preference management, priority systems, scheduling, and channel selection for DMs versus team channels, it gets even more complicated. Both Slack and Teams restrict how quickly you can send messages, so you need queuing, retry logic, and fallback strategies.

### State Management & Threading

These tools maintain conversational context. Follow-up messages about a deployment should appear as threaded replies under the original. This keeps channels organized. Threading works differently on each platform, so you end up building abstractions that work across both implementations.

### Webhooks

Webhooks turn notifications into product workflows. When someone clicks a button, Slack or Teams sends a webhook to your application. You need endpoints to receive these, verify authenticity, respond quickly (platforms time out fast), and maintain enough context to understand what action was taken on which notification.

### Analytics & Observability

You need to answer questions about what's working and why something keeps failing. Track delivery rates, measure engagement, debug failures. When a customer reports a missing notification, you need enough logging to figure out whether it was filtered, rate-limited, failed authentication, or delivered but ignored.

### Compliance & Security

Audit logs, encryption, data retention policies, and certifications like SOC 2. This needs to be baked into architecture from the start.

## Building vs. Buying

Teams face a choice between implementing all this infrastructure or using specialized platforms that provide it as a service.

Building makes sense in specific situations: you're sending billions of notifications monthly, your needs are so unique that existing platforms can't support them, or notification infrastructure is core to your competitive advantage.

For most products, notifications are important but not differentiating. A project management tool needs reliable notifications, but users don't choose it based on notification infrastructure. The infrastructure requirements we outlined represent months of engineering work. For a team of three engineers, that's roughly a year to build and reach production quality. That's time that could go toward features that actually set your product apart.

Specialized notification platforms handle this infrastructure so you don't have to. They manage authentication, offer template designers for non-engineers, handle delivery orchestration, track state across channels, and maintain integrations as platform APIs change. When Slack updates their API, the platform updates. Your code stays the same.

---

Why workplace notifications matter for B2B products. Covers omnichannel strategy, the dual-platform reality, and essential components for production systems.

Slack and Teams Notifications for B2B SaaS: Introduction

Why workplace notifications reach users faster than email and enable action without context switching. Covers the dual-platform reality facing B2B teams, where Slack and Teams fit within omnichannel strategy, and the essential components for production systems including OAuth, templates, routing, state tracking, and compliance.

Why Use Slack and Microsoft Teams Notification Tools

> Getting Slack and Teams notifications working involves platform setup, Courier configuration, and understanding the capabilities you can build for your users.

## Setting Up Slack for Notifications

Head to the [Slack API Apps page](https://api.slack.com/apps) and create a new app from scratch. The OAuth scopes determine what your app can access. For [sending notifications](https://www.courier.com/blog/how-slack-builds-smart-notification-systems-users-want), you need `chat:write` for posting messages, `users:read` and `users:read.email` for looking up users by email, and `im:write` for direct messages. Add `chat:write.public` if you want to post to channels without joining them first.

Install the app to your development workspace to get a bot token starting with `xoxb-`. This token authenticates your API calls. In production, each customer workspace will have its own token.

![Slack setup](//images.ctfassets.net/z7iqk1q8njt4/2yEEXT2Z4P3hZhFN3tuNvt/36890862532a59cc509a568f45a09db2/Integrate_AI_directly_into_Slack.png?w=800)

## Setting Up Microsoft Teams for Notifications

Teams requires more infrastructure because it's built on Azure Bot Framework. Start by registering an app in the [Azure Portal](https://portal.azure.com/) under App Registrations. You'll receive an Application (client) ID and need to generate a client secret.

Next, create the bot through the [Teams Developer Portal](https://dev.teams.microsoft.com/). Add a bot under App Features and link it to your Azure app registration. Configure the bot endpoint URL where Teams sends incoming messages. This URL must be publicly accessible with HTTPS, requiring a deployed endpoint even for development.

The admin consent requirement adds friction for enterprise customers. When a company installs your app, their IT admin might need to approve it first. The [Microsoft Teams integration guide](https://www.courier.com/docs/external-integrations/direct-message/microsoft-teams) covers complete setup including admin consent handling.

![MS Teams setup](//images.ctfassets.net/z7iqk1q8njt4/2xdwhikdpOZ0hwKamTn9gi/72e2106cc99e4d0d8eecea6bb2ba93c0/Frame_163990.png?w=800)

## Configuring Integrations in Courier

Once you've created apps in Slack and Teams, connect them through the [Courier Integrations page](https://app.courier.com/integrations). For Slack, you can either connect your own app using your bot token, or use Courier's OAuth flow where customers authorize directly through Courier. The OAuth approach is simpler for multi-tenant scenarios because Courier manages tokens automatically.

For Teams, enter your Azure Application ID and client secret. Courier handles Bot Framework communication and credential storage. The [Slack](https://www.courier.com/docs/external-integrations/direct-message/slack) and [Teams](https://www.courier.com/docs/external-integrations/direct-message/microsoft-teams) documentation provide step-by-step instructions. Configuration happens once, then you use the same API for both platforms.

## Sending Notifications with Courier

With Slack and Teams configured, sending notifications uses the same API. Install the Courier SDK (available for JavaScript, Python, Ruby, Go, and other languages) and initialize it:

```javascript
const { CourierClient } = require("@trycourier/courier");
const courier = new CourierClient({
  authorizationToken: process.env.COURIER_AUTH_TOKEN
});

const { requestId } = await courier.send({
  message: {
    to: {
      slack: { email: "engineer@company.com" }
    },
    content: {
      title: "Deployment Complete",
      body: "Production environment updated to version 2.4.1"
    }
  }
});
```

The email-based targeting works without managing Slack user IDs. Courier looks up the user and delivers the message. The content structure translates to Block Kit for Slack, Adaptive Cards for Teams, or plain text for SMS depending on channel.

Target multiple providers by including both `slack` and `ms_teams` in the recipient object. The [routing documentation](https://www.courier.com/docs/platform/sending/send-message#routing) covers fallback logic and conditional delivery. For platform-specific control, [provider overrides](https://www.courier.com/docs/external-integrations/direct-message/slack#advanced-features-customization) let you specify custom Block Kit or Adaptive Card layouts.

## Targeting Channels and Users

Courier supports several targeting patterns. For channel messages in Slack, specify the channel ID:

```json
{
  "to": {
    "slack": {
      "access_token": "xoxb-your-token",
      "channel": "C1234567890"
    }
  }
}
```

For Teams channels, provide tenant ID, team ID, channel name, and service URL:

```json
{
  "to": {
    "ms_teams": {
      "tenant_id": "your-tenant-id",
      "team_id": "your-team-id",
      "channel_name": "General",
      "service_url": "https://smba.trafficmanager.net/amer"
    }
  }
}
```

For multi-channel delivery, use routing preferences:

```javascript
await courier.send({
  message: {
    to: { email: "sarah@company.com" },
    content: {
      title: "Budget Approval Needed",
      body: "Q4 marketing budget requires your approval: $45,000"
    },
    routing: {
      method: "all",
      channels: ["email", "chat"]
    }
  }
});
```

The [message targeting documentation](https://www.courier.com/docs/external-integrations/direct-message/slack#message-targeting-reference) covers additional patterns including user IDs, incoming webhooks, and conversation IDs.

## Designing Notification Templates

For recurring notifications, templates separate content from code. Go to the [Courier Designer](https://app.courier.com/designer/notifications) and create a notification with both Slack and Teams channels. Use the Block Kit editor for Slack and Adaptive Cards editor for Teams. Add variables using `{{variable_name}}` syntax.

Reference the template when sending:

```javascript
await courier.send({
  message: {
    to: { slack: { email: "sarah@company.com" } },
    template: "budget-approval-request",
    data: {
      budget_amount: "$45,000",
      department: "Marketing",
      quarter: "Q4"
    }
  }
});
```

Your product team can update notification copy in the designer without code deployments.

## Adding Interactive Elements

Interactive notifications let users take action directly from the message. In the template designer, add action blocks with buttons for Slack or use the Adaptive Cards editor for Teams.

![interactive slack elements](//images.ctfassets.net/z7iqk1q8njt4/1fSrzWxJ21lzXkgmaNhyra/241b9040ca2abeb4a97fec414368f52c/sDKsOM9R5jWcFc2oZOstbdjQbpY.png?w=800)

When someone clicks a button, Courier receives the webhook from Slack or Teams, verifies authenticity, and tracks the interaction in [message logs](https://app.courier.com/logs/messages). For custom handling, configure webhook endpoints in workspace settings to receive interaction events directly. The [webhooks documentation](https://www.courier.com/docs/reference/webhooks) covers setup for interaction events and delivery confirmations.

## Handling Rate Limits and Delivery Failures

Slack's rate limiting uses tiers. Most message-posting falls into Tier 3, allowing approximately one message per second per channel. Burst above that and Slack queues messages. Sustain high rates and you get `rate_limited` errors. Note: Slack's `Retry-After` headers aren't always accurate. Developers report needing 60+ seconds even when headers say 3 seconds.

Teams allows approximately 30,000 event deliveries per workspace per app per hour. For most applications this is plenty, but high-volume notifications need queuing.

Courier handles rate limiting automatically, queuing messages and retrying with appropriate backoff. Check delivery status through [Courier Logs](https://app.courier.com/logs/messages) without building custom debugging tools.

## Testing and Debugging

Neither platform provides sandbox environments, so you test against real workspaces. Use the Preview tab in the template designer to send test notifications with sample data. Click Send and verify formatting, variables, and interactive elements in your actual Slack or Teams workspace.

> **Test from your IDE:** The [Courier MCP](https://www.courier.com/docs/tools/mcp) lets you send test notifications directly from AI-enabled editors like Cursor or VS Code with Copilot. Ask your AI assistant to "send a test Slack notification to my email" and it will call the Courier API without leaving your editor. Useful for rapid iteration while building notification logic.

![testing and debugging slack teams](//images.ctfassets.net/z7iqk1q8njt4/3UrI3enRG2V6cg2c1xt4qs/060fe2fb678b53bd587e09fb2faa4ddf/Frame_163979__5_.png?w=800)

When notifications don't arrive, check [Courier Messages](https://app.courier.com/logs/messages). Search by recipient email, user ID, or notification ID. The logs show the complete delivery timeline including errors. Common issues: authentication failures from expired tokens, rate limiting showing as queued status, bots not being channel members for private channels.

For Teams, verify admin consent was granted and your bot has necessary Microsoft Graph permissions. The [Messages API](https://www.courier.com/docs/reference/messages) provides programmatic access to delivery data for custom dashboards.

## Updating Messages as Status Changes

Instead of sending separate notifications for each status change, update the original message. Configure a replacement key in your template's Slack channel settings (typically `ts` for timestamp). For Teams, activity IDs are tracked automatically.

```javascript
// Initial notification
await courier.send({
  message: {
    to: { slack: { email: "engineer@company.com" } },
    template: "deployment-status",
    data: { status: "Deployment initiated", tracking_id: "deploy-2024-001" }
  }
});

// Update with same tracking_id
await courier.send({
  message: {
    to: { slack: { email: "engineer@company.com" } },
    template: "deployment-status",
    data: { status: "Deployment complete", tracking_id: "deploy-2024-001" }
  }
});
```

Courier recognizes matching tracking IDs and updates rather than creates. This keeps channels clean and shows status progression in one place.

## Security Considerations

Notifications often contain sensitive information. Key requirements:

**Verify webhook signatures.** When Slack or Teams sends a webhook, they include a signature. Without verification, someone could send fake webhooks pretending to be user interactions. Reject any webhooks that don't verify.

**Store tokens securely.** Bot tokens grant full access to send messages as your application. Use environment variables or secrets management. Never commit to source control. Rotate periodically. Encrypt at rest.

**Implement access controls.** Just because someone is authenticated doesn't mean they should send arbitrary messages. Notifications should follow the same authorization rules as other actions.

**Audit notification sending.** Enterprise customers need to know who sent what when. Some industries require this for regulatory reasons.

Courier handles these by default: tokens encrypted at rest, HTTPS for all communication, automatic webhook signature verification, and [SOC 2 Type II certification](https://security.courier.com/) with HIPAA and GDPR support.

---

Set up Slack OAuth and Teams Bot Framework with Courier. Covers API integration, templates, interactive buttons, webhooks, rate limits, and delivery debugging.

Slack and Teams Notification Setup: Technical Implementation

Step-by-step setup for Slack OAuth and Teams Bot Framework, then connecting both to Courier. Covers sending notifications through the unified API, designing templates in the visual editor, targeting users and channels, adding interactive buttons, handling webhooks, managing rate limits, and debugging delivery issues.

Technical Implementation

> Getting notifications delivered is the baseline. Making them useful requires thoughtful design, appropriate timing, and respect for user attention.

## Designing Messages That People Actually Read

Users scan notifications in seconds. **Frontload the important information** so they can decide quickly whether to act. "Budget approval needed: $45,000 for Q4 marketing" tells someone immediately what they're looking at. "Update on your request" makes them click through to find out what happened.

![design slack templates](//images.ctfassets.net/z7iqk1q8njt4/2n7DN8owkAnSDEKfYaA5aE/29618692da14084e574154b7b3254c81/Frame_163985.png)

**Specificity helps users prioritize.** "Server db-prod-01 connection failed" beats "Error occurred." "Sarah Chen commented on the Q4 roadmap document" beats "New comment on your document." You have the specific information when sending. Include it instead of making users click through for basic context.

**Action buttons work when they're obvious and limited.** Two or three clear options are fine. Five buttons with ambiguous labels create decision paralysis. "Approve" and "Reject" are immediately clear. "Process," "Review," and "Consider" require thought about what each does.

**Tailor content to the recipient's role.** A "Deal closed" notification means something different to a sales rep (commission incoming) versus a support engineer (provision the new customer's environment). What matters to them? What action do they need to take?

## Preventing Notification Fatigue

Users tolerate notifications up to a point. Cross that line and they disable notifications entirely or start ignoring everything you send.

**[Batch similar notifications](https://www.courier.com/docs/platform/automations/batching) when it makes sense.** If ten people comment on the same document within an hour, send one notification: "10 new comments on Q4 Roadmap" instead of ten separate messages. The information value is nearly identical but the interruption cost is ten times lower.

**Implement frequency caps.** When one user generates fifty events in an hour, sending fifty notifications trains others to ignore your app. Cap notifications per user per time period. Queue extras for later or batch into a digest.

**Timing affects reception.** A reminder about tomorrow's meeting sent today is helpful. The same reminder a week early is noise. Non-urgent notifications can wait for business hours in the recipient's timezone instead of arriving at 3am.

![Workflow](//images.ctfassets.net/z7iqk1q8njt4/6jjkysHmVJzUAtMCDq6Pzw/f16bf181d6ee16e88a18f6c9ad6ccb2b/Work.png)

[Courier Journeys](https://www.courier.com/platform/workflow-automations) handles batching and timing through workflow rules. Configure digest windows, add timezone-aware delays, and implement frequency caps without building custom scheduling logic.

## Platform-Specific Optimization

Slack and Teams have different cultures that affect how users receive notifications.

**Slack users expect asynchronous communication.** Notifications arrive anytime; people respond when convenient. Thread replies work well because threading is central to how Slack organizes conversations. Ephemeral messages let you show information to one person without cluttering channel history.

**Teams users expect more structured communication.** Teams is built around organizational hierarchy, so notifications relating to ongoing work should go to the appropriate Team's channel. The Office 365 integration means you can link directly to SharePoint documents or Calendar events.

**Message formatting differs.** Slack's Block Kit includes dividers, context blocks, and specific layouts. Teams' Adaptive Cards support different elements like fact sets for key-value pairs. Design for each platform's constraints rather than forcing identical layouts.

## Delivery Reliability

Notifications that don't arrive are worse than no notification system. Users expect reliability, and failures erode trust.

**Implement retry with exponential backoff.** When delivery fails due to network issues or temporary outages, retry after a short delay. If it fails again, wait longer. After several failures, give up and log the error. Distinguish between retryable errors (network timeouts) and permanent failures (invalid tokens, channel not found).

**Circuit breakers prevent cascading failures.** If Slack's API starts failing consistently, stop sending new notifications for a cooldown period. Monitor failure rates and open the circuit breaker when they exceed thresholds.

**Queue notifications when delivery fails.** Store them for retry when the platform becomes available. Users would rather get an alert fifteen minutes late than not at all.

**Fallback channels provide alternatives.** If Slack fails after retries, send via email instead. The [Courier routing engine](https://www.courier.com/docs/platform/sending/send-message#routing) handles this with `method: "single"` and an ordered channel list, trying each until one succeeds.

## Monitoring

Track delivery metrics by channel and notification type. What percentage succeed? Which types have highest failure rates? If Slack fails 20% but Teams succeeds 99%, you have a Slack-specific issue.

![Analytics Notifications](//images.ctfassets.net/z7iqk1q8njt4/4leD8stL8TMPtDir2hrjdG/63dacb673528f3c37a6e099ddb3e1890/Frame_163930__1_.png)

Measure engagement beyond delivery. Which notifications get clicked? Which actions do users take? Low engagement suggests a notification isn't providing value.

Set up alerts for anomalies. If volume drops significantly, something might be broken. If failure rates spike, a platform might be down or authentication failed. Catch problems before customers report them.

The [Courier Analytics dashboard](https://www.courier.com/docs/platform/analytics/analytics-overview) provides delivery rates, engagement metrics, and failure patterns across channels with detailed logs for debugging.

## User Preferences and Control

Without preferences, even useful notifications become spam when they're too frequent or poorly timed.

![preference management](//images.ctfassets.net/z7iqk1q8njt4/34fUnrJe38TYtArT9XRd6U/97fa7f9ef26ab6180b3ff06099adc1ef/Frame_163911__3_.png)

**Category opt-outs** let users want task assignments but not routine status updates. Breaking notifications into toggleable categories gives meaningful control without all-or-nothing choices.

**Channel preferences** matter too. Critical alerts via both Slack and SMS, routine updates only in Slack. Per-category channel selection.

**Quiet hours** respect work-life boundaries. Non-urgent notifications wait for business hours. Critical alerts might break through; feature announcements can wait.

**Frequency preferences** help power users. Someone collaborating on fifty documents might prefer a [daily digest](https://www.courier.com/docs/platform/automations/digest) summarizing all activity. Others want real-time everything.

[Courier's preference management](https://www.courier.com/platform/preferences-management) provides a hosted preference center that automatically filters notifications based on user settings.

## Platform-Specific Tips

**For Slack:**
- Use ephemeral messages for responses only one person needs to see
- Thread replies keep channels organized. Post first message to channel, updates as replies
- Mention users sparingly. `@user` triggers additional alerts; use only when you need attention
- Update messages instead of posting separate status updates ("Deployment: 10%", "20%", "30%")

**For Teams:**
- Understand channel types: standard channels work normally, private channels require bot invitation, shared channels span tenants with additional complexity
- Adaptive Card versioning matters. Use latest version but verify rendering in Teams clients
- Save activity IDs to update messages later, similar to Slack timestamps

## Handling Edge Cases

Production surfaces scenarios that don't appear during development:

- **Workspace deletion or reinstallation**: Detect when tokens stop working and notify customers to reauthorize. Don't silently fail.
- **User deletion**: Check for this error and remove users from future notifications instead of continuing failed attempts.
- **Channel archiving**: Update records to stop targeting archived channels. Notify admins the destination is invalid.
- **Permission changes**: Handle gracefully when admins remove scopes or restrict bot access.
- **Rate limit exhaustion**: Queue messages instead of dropping them. Consider batching if you're hitting limits regularly.
- **Platform outages**: Queue for recovery, provide email fallback for critical notifications, monitor status pages.

Courier's delivery infrastructure handles these through automatic retry logic, error categorization, fallback routing, and queue management.

---

Design workplace notifications users read. Covers message structure, timing strategies, platform-specific optimization, delivery reliability, and preferences.

Slack and Teams Notification Design Best Practices

Message design principles that respect user attention, timing and frequency strategies to prevent fatigue, platform-specific optimization for Slack vs Teams threading and formatting. Covers delivery reliability patterns, error handling, monitoring and observability, user preference management, and edge case handling.

Best Practices and Optimization

> Choosing how to implement Slack and Teams notifications means understanding the landscape: building custom, using platforms, and what to expect from each approach.

## The Platform Landscape

Several platforms specialize in notification infrastructure. They differ in capabilities and which use cases they optimize for.

![Slack and Courier Integration](//images.ctfassets.net/z7iqk1q8njt4/6Dey4dAmRKX0bgFXHPn1eX/2714a3c69aaffa10043bf3e03729e5ba/Frame_163990__2_.png?w=800)

**[Courier](https://www.courier.com/)** focuses on [product notifications](https://www.courier.com/blog/transactional-product-and-marketing-notifications-what-are-the-differences) for [B2B SaaS](https://www.courier.com/solutions/saas). Full [Slack](https://www.courier.com/docs/external-integrations/direct-message/slack) and [Teams](https://www.courier.com/docs/external-integrations/direct-message/microsoft-teams) support through a unified API. Free tier includes 10,000 notifications/month. [Pricing](https://www.courier.com/pricing) scales with usage. SOC 2 Type II, HIPAA, GDPR compliant.

- [Visual template designer](https://www.courier.com/docs/platform/content/notification-designer)
- [Workflow automations](https://www.courier.com/platform/workflow-automations)
- [Preference management](https://www.courier.com/platform/preferences-management)
- [Multi-tenant architecture](https://www.courier.com/docs/platform/tenants/tenants-overview)
- [Analytics and observability](https://www.courier.com/docs/platform/analytics/analytics-overview)

**Knock** takes a similar developer-first approach with Slack and Teams support. Code-centric configuration, workflow orchestration. Starts at $250/month. Teams support less comprehensive than Slack.

**Novu** offers open-source, self-hostable infrastructure. Appeals to strict data residency requirements. Tradeoff: you handle infrastructure, scaling, security patches. Supports Slack but not Teams.

**SuprSend** provides Slack and Teams with transparent, usage-based pricing. Growing adoption, less comprehensive feature set than mature platforms.

**MagicBell** focuses on in-app notification feeds. Slack is secondary. No Teams support.

**Customer.io** and **OneSignal** focus on marketing automation and push notifications respectively. Slack support exists but workplace notifications aren't the primary focus. Neither supports Teams.

**The Teams gap is notable.** Only Courier, Knock, and SuprSend provide [Microsoft Teams support](https://www.courier.com/docs/external-integrations/direct-message/microsoft-teams). If your customers use Microsoft 365, this immediately narrows your options.

## Why Courier

![platform comp](//images.ctfassets.net/z7iqk1q8njt4/1QnpjbLuGGz59ieIcSWL1B/c43ec0d78be180a4345433bba50baac7/Frame_163976__1_.png?w=800)

**Full Slack and Teams parity.** Both platforms get equal treatment, not one well-supported and the other as an afterthought. Same templates, routing logic, and analytics for both. When enterprise customers require Teams, you're ready without separate integration work.

**Email-based targeting.** [Send notifications using email addresses](https://www.courier.com/docs/external-integrations/direct-message/slack#message-targeting-reference) you already have in your user database. Courier looks up the corresponding platform user and delivers. No Slack or Teams user ID mapping infrastructure needed.

**Automatic template conversion.** Design once in the [visual designer](https://www.courier.com/docs/platform/content/notification-designer), and Courier renders to Block Kit for Slack and Adaptive Cards for Teams. Preview both platforms before sending. You're not maintaining separate templates for every notification type.

**True multi-tenancy.** Each of your customers gets separate configurations, branding, and rate limits through [Courier's tenant system](https://www.courier.com/docs/platform/tenants/tenants-overview). If you're building a product that sends notifications on behalf of thousands of companies, this foundation is essential.

**Visual workflow builder.** The [Automations](https://www.courier.com/platform/workflow-automations) interface lets product managers set up batching rules, marketing adjust timing and frequency, and support configure escalation workflows. No code changes or deployments needed.

**Comprehensive debugging.** Query [message logs](https://www.courier.com/docs/reference/messages) by user, notification type, status, provider, time range, and other criteria. When a customer reports a missing notification, you have 13+ filter parameters to track down what happened.

**Enterprise compliance built in.** SOC 2 Type II certification, HIPAA compliance options, GDPR data handling, audit logging, and data residency controls come standard. Review [Courier's security documentation](https://security.courier.com/) during vendor evaluation without waiting for compliance features to be built.

## Build vs Buy

**Building in-house** means implementing OAuth flows for both platforms, managing token storage and refresh, handling rate limits, building retry logic, maintaining templates in two formats, and keeping up with API changes. That's months of engineering time upfront, plus ongoing maintenance. And the work stays with engineering: every copy change, new notification type, or workflow adjustment requires developer involvement.

**Using a platform** means integration in weeks. The platform handles authentication, delivery reliability, and API updates. But the bigger shift is who can work on notifications. Product teams design templates and set up workflows in visual builders. Growth teams adjust timing and frequency without filing tickets. Marketing manages promotional messages alongside transactional ones. Engineers focus on integration points, not notification infrastructure.

**Unified preference management** becomes possible when transactional and marketing messages run through the same system. Users control all their notification settings in one place instead of managing separate preferences for product updates versus promotional content. This consolidation improves the user experience and simplifies compliance.

**Build when:** notifications are your core differentiator, you have compliance requirements platforms can't meet, or you're operating at massive scale.

**Use a platform when:** you need to ship quickly, you'll support multiple channels, your team is small, you want non-technical teams contributing to notification strategy, or notifications support your product but aren't what makes it unique.

## Running a Pilot

![slack channels](//images.ctfassets.net/z7iqk1q8njt4/6AM0itwac2Lj6CcyhFoNqX/a5c26bfdbabd51ed96be123dce1fe651/Frame_163988.png?w=800)

Pick one notification type. Something important enough for real feedback but not so critical that failures create major problems. Budget approvals or project updates work well. Production incident alerts don't.

Limit to a subset of users initially. Define success criteria before starting: faster response times? Higher engagement than email? Positive feedback?

Run for at least a month to see patterns. Track metrics, gather qualitative feedback, scale gradually based on results.

## Migrating from Custom Integrations

Common drivers: adding the second platform, reducing maintenance burden, enabling non-technical teams to update content.

Migration typically takes 1-2 weeks. Move authentication to the platform's OAuth flow, convert templates, update send logic to call the platform API. Historical data stays in Slack/Teams.

Test thoroughly in staging. Run both systems in parallel during transition if you want extra confidence.

## Who's Using Courier

**[DroneDeploy](https://www.courier.com/customers)** (drone mapping software) needed notifications when map processing completed. Building a notification center would have consumed months.

> "Notifications are not our core competency, so it made complete sense to integrate rather than build out and support our own implementation."
> — **James Pipe, VP of Product**

**LaunchDarkly** (feature management) uses Courier for approval workflows where engineers request changes and team members approve through action buttons.

> "We were able to build the in-app notification experience that we wanted with excellent support and communication from the Courier staff."
> — **Lucy Wonsower, Software Engineer**

**HiPages** modernized their notification infrastructure by moving out of their monolith.

> "It used to take four weeks to get a new message type into the monolith. Post Courier, it takes less than one day."
> — **Clayton Bell, Head of Platform** ([Full case study](https://www.courier.com/use-cases/hipages))

**Twilio** chose Courier for internal operations when they [deprecated their Notify API](https://www.courier.com/blog/what-you-need-to-know-about-twilio-notifys-end-of-life).

![Twilio branded inbox](//images.ctfassets.net/z7iqk1q8njt4/7fFZOYlh6eA1GU2VZgFJUJ/41991ee58c80448fa4b675ac02ee5666/Frame_163968__2_.png?w=800)

> "We chose Courier because the depth of the inbox and multi-channel integrations allowed us to choose one notification platform for all products and teams at Twilio."
> — **Raghav Katyal, Technical Lead** ([Full case study](https://www.courier.com/use-cases/twilio))

## Getting Started

**Week 1: Setup**
- Sign up at [app.courier.com](https://app.courier.com/signup)
- Configure [Slack](https://app.courier.com/integrations) and [Teams](https://www.courier.com/docs/external-integrations/direct-message/microsoft-teams) integrations
- Install SDK: [Node.js](https://www.courier.com/docs/sdk-libraries/node), [Python](https://www.courier.com/docs/sdk-libraries/python), [Ruby](https://www.courier.com/docs/sdk-libraries/ruby), or [Go](https://www.courier.com/docs/sdk-libraries/go)
- Send test notifications

**Week 2: Templates and preferences**
- Design templates in the [visual designer](https://www.courier.com/docs/platform/content/notification-designer)
- Set up [user preferences](https://www.courier.com/docs/platform/preferences/preferences-editor)
- Configure [routing rules](https://www.courier.com/docs/platform/sending/send-message#routing)

**Week 3: Production**
- Move credentials to secrets management
- Configure [webhooks](https://www.courier.com/docs/reference/webhooks) and [monitoring](https://app.courier.com/logs/messages)
- Deploy and monitor

**Week 4: Optimization**
- Add [automation workflows](https://www.courier.com/docs/platform/automations/automations-overview) and [digests](https://www.courier.com/docs/platform/automations/digest)
- Set up [analytics](https://www.courier.com/docs/platform/analytics/analytics-overview)
- Optimize based on metrics

Most teams move faster than this. You're integrating an SDK, not implementing OAuth flows from scratch.

---

Questions? Visit [Courier docs](https://www.courier.com/docs/) or [get in touch](https://www.courier.com/request-demo).

Compare notification platforms on Teams support, calculate ROI, and decide between building or buying. Includes customer examples from Twilio and LaunchDarkly.

Slack and Teams Notifications: Build vs Buy Comparison

Platform landscape comparison covering Courier, Knock, Novu, SuprSend, MagicBell, and others with focus on Teams support gaps. Includes ROI expectations, pilot program guidance, build vs buy cost analysis, migration strategies from custom integrations, and customer examples from DroneDeploy, LaunchDarkly, HiPages, and Twilio.

Evaluating Your Options

How to build Slack & Microsoft Teams notifications

Build production-ready Slack and Teams notifications with Courier. Covers setup, templates, interactivity, delivery reliability, and build vs buy decisions.

Slack and Microsoft Teams Notifications: Complete B2B Guide

A complete guide to building Slack and Microsoft Teams notifications for B2B SaaS. Covers platform setup, Courier integration, message design, and delivery reliability. Includes platform comparisons, build vs buy analysis, ROI frameworks, and best practices for respecting user attention across workplace channels.


How to build Slack & Microsoft Teams notifications

Highlights

Contents

Products

Solutions

Platform