🔔 Teams Activity Feed Notifications From Graph for DevOps Alerts

There’s a difference between posting a message and getting someone’s attention, and a busy on-call engineer with forty channels muted knows it intimately. A card dropped into a channel competes with everything else in that channel. An activity feed notification lands in the person’s bell icon — the same place mentions and replies surface — with their name on it and a deep link straight to the thing that needs them. For “you specifically need to look at this now,” that’s the channel you want.

Activity feed notifications are sent through Microsoft Graph, targeted at a user, and they’re the most underused alerting surface in Teams for DevOps. Here’s how they work and where they shine.

What an activity notification is

It’s a personal entry in the recipient’s activity feed, defined by three things: a topic (what it’s about, with a click target), an activity type (a named template you register in your manifest), and a preview text (the human-readable line they see). You send it to a user, a chat, a channel, or a team via Graph.

The activity types are not free-form — you declare them in your app manifest first:

"activities": {
  "activityTypes": [
    {
      "type": "deployFailed",
      "description": "A production deploy failed",
      "templateText": "{actor} reports: deploy of {serviceName} failed"
    },
    {
      "type": "approvalNeeded",
      "description": "An approval is waiting on you",
      "templateText": "{actor} needs your approval for {changeName}"
    }
  ]
}

The {placeholders} in templateText get filled at send time. You can only send activity types you’ve declared — Graph rejects unknown ones.

Sending one to a user

The call is POST /users/{id}/teamwork/sendActivityNotification. The topic carries the deep-link target so the bell click takes them straight to the relevant place:

POST https://graph.microsoft.com/v1.0/users/{user-id}/teamwork/sendActivityNotification
{
  "topic": {
    "source": "text",
    "value": "checkout-api deploy failed",
    "webUrl": "https://teams.microsoft.com/l/entity/APP-ID/deploys?context=%7B%22subEntityId%22%3A%22INC-1234%22%7D"
  },
  "activityType": "deployFailed",
  "previewText": { "content": "Production deploy of checkout-api failed" },
  "templateParameters": [
    { "name": "actor", "value": "DeployBot" },
    { "name": "serviceName", "value": "checkout-api" }
  ]
}

The recipient sees “DeployBot reports: deploy of checkout-api failed” in their bell, and clicking it deep-links them into your app’s deploys tab, pre-scoped to incident INC-1234 via the subEntityId. That deep link is what turns a notification into action — they’re one click from the right context instead of hunting for it.

Targeting beyond a single user

The same capability targets chats, channels, and teams:

• POST /teams/{teamId}/channels/{channelId}/sendActivityNotification — notifies channel members about a channel event.
• POST /chats/{chatId}/sendActivityNotification — for a group chat (e.g., an incident chat).
• A recipient of type aadUserNotificationRecipient inside a team call lets you ping specific people about team-scoped content.

For an escalation, I send to the individual on-call user. For a “the war room needs eyes” nudge, I send to the channel.

Permissions and the consent reality

This is where the planning happens before the code. The relevant Graph permissions are TeamsActivity.Send (application or delegated). For application-permission sends — the usual case for an automated alerting system with no user in the loop — your app needs admin consent, and the user must have your app installed for the notification to reach them. That last constraint surprises people: you can’t notify someone who hasn’t installed your app. So your rollout has to include getting the app pre-installed for the relevant teams, which the admin can do via app setup policies.

Don’t turn the bell into noise

The bell is precious real estate, and the fastest way to get your app uninstalled is to flood it. My rules:

• Notify a person only when they personally need to act. “Your approval is required,” “you’re now the incident commander,” “your deploy failed.” Not “a deploy happened somewhere.”
• Use the channel target for FYI-to-a-group, the user target for “you specifically.”
• Always carry a deep link in the topic.webUrl. A notification you can’t act on from is just an interruption.
• Rate-limit yourself. Graph throttles, but more importantly humans tune out a noisy source. Coalesce ten flapping alerts into one notification, not ten.

Where it fits in the alerting stack

Think of activity notifications as the top tier of a layered scheme. Channel cards are the broadcast layer — context for the team, scannable, low-urgency. Activity notifications are the targeted layer — a specific person, a specific action, a deep link to where they need to be. And for true paging you still hand off to your pager system. Used that way, the bell stays meaningful: when it lights up from your app, the recipient knows it’s actually for them.

For more on getting alerts in front of the right people in Teams, see the Microsoft Teams category, and the prompt library has prompts for designing notification copy and deep links.

Graph notification APIs, permissions, and install requirements change over time. Verify current scopes and the app-install constraint in the Microsoft Graph docs before building.