Work item @mention emails silently not generated for some users — no delivery record and no diagnostic path for the mention event

Alexandre Bouffard 31 Reputation points
2026-07-30T00:40:25.9066667+00:00

Summary

In our Azure DevOps Services organization, @mention email notifications on work item comments are not generated for some users, while being delivered normally to others in the same work item. Other notification types (for example "a work item is assigned to me") are delivered correctly to the affected users, so mail delivery itself is working. We cannot find any configuration difference that explains which users are affected, and we cannot find any diagnostic surface for the mention event.

Repro

In a single work item, three comments were posted seconds apart by the same author. Each comment mentioned exactly one user. Every mention was created manually in the web UI by selecting the user from the identity picker — not typed as plain text and not created through the REST API. We confirmed afterwards via the API that each stored comment contains the correct identity GUID for the intended user, so all three mentions were properly resolved.

  • User A: received the mention email.
  • User B: no email.
  • User C: no email.

An Exchange Online message trace for users B and C confirms that no mention email was ever transmitted to them, while other Azure DevOps notification mail arrives normally. The notification is not being generated at all — this is not spam filtering or a delivery failure.

What we have verified as identical between the working and non-working users

  • Notification subscriptions: the same 10 default subscriptions with the same statuses — byte-identical between the working user and a non-working user.
  • Subscriber record: deliveryPreference: preferredEmailAddress with the correct address for all users.
  • Identity properties: Mail and Account set correctly.
  • Effective permissions: permissionEvaluationBatch returns true for read on both the work item's area path node and the team project, for all users.
  • Mention markup: correct identity GUID for each user in each comment.
  • All users are active and have signed in recently.

Why we cannot self-diagnose this

  • Mentions do not appear to use the notification subscription system. No user in the organization has a mention subscription, and the working user's subscription list is identical to a non-working user's. The organization does have the event types ms.vss-mentions.identity-mention-event and ms.vss-mentions.identity-mention-failed-event.
  • Because there is no mention subscription, subscription logging (/_notifications?diagnostics=true → Enable Diagnostics) cannot be enabled for this event — there is no row corresponding to a mention. As far as we can tell there is no admin-visible diagnostic path for the mention pipeline, and no way to see whether the event fired or why it was dropped.

This is the core of our request: a notification that is silently never generated, with no delivery record and no diagnostics, leaves us with nothing to inspect.

Possible regression

We believe @mention notifications previously worked for at least some users in this organization who receive access through Entra ID group rules, including external/guest users. This has not been retested recently and we cannot currently confirm it, so we offer it only as a possible lead: it may indicate a regression rather than a configuration issue. If anyone can confirm whether mention notification behavior changed recently, that would help us narrow this.

Attributes that differ, which we cannot isolate

The two failing users differ from the working user on several attributes at once, and we have too few users in the relevant configurations to separate them:

  • access level source: Entra ID group rule vs direct entitlement
  • the PUID identity property: absent on both failing users, present on the working user
  • identity creation date: recent vs several years old
  • license tier: Basic vs Visual Studio Enterprise subscription

We are not proposing a mechanism. We cannot tell which of these matters, or whether any is causal — and our recollection above that mentions once worked for group-rule users argues against the group-rule attribute being the explanation.

Questions

  1. Is there any supported way to obtain diagnostics for ms.vss-mentions.identity-mention-event, given that subscription logging requires a subscription and mentions do not have one? This is our main ask.
  2. What conditions cause the mention pipeline to drop an event for a specific recipient while delivering the same batch to another recipient?
  3. Has mention notification behavior changed recently for users whose access comes from an Entra ID group rule, or for guest users?
  4. Does the mention pipeline depend on identity properties such as PUID?
Azure DevOps

2 answers

Sort by: Most helpful
  1. Marco Niederberger 0 Reputation points
    2026-08-11T09:57:41.7233333+00:00

    Same issues here and i think this is related to https://learn.microsoft.com/en-us/answers/questions/5971568/azure-devops-%40mentions-fail-when-the-mention-user

    The user i received complaints about this from is having a guid that starts with a alphabetic character

    Please Microsoft investigate and fix this annoying bug

    Was this answer helpful?

    0 comments No comments

  2. kagiyama yutaka 4,835 Reputation points
    2026-07-30T03:26:09.9233333+00:00

    I think Azure DevOps has no admin‑side way to see or adjust how ms.vss-mentions.identity-mention-event works, since @mention runs on a separate pipeline with no diagnostics. All four questions fall under that same limit. The only practical step is to take one failing work‑item example and have Microsoft support check that mention event on the service side.

    Was this answer helpful?

    0 comments No comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.