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
- 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.
- What conditions cause the mention pipeline to drop an event for a specific
recipient while delivering the same batch to another recipient?
- Has mention notification behavior changed recently for users whose access
comes from an Entra ID group rule, or for guest users?
- Does the mention pipeline depend on identity properties such as
PUID?