How to question: Display Windows "Service Name" in Email Notification Subject Line

Hi Saiyad,

You’re correct: the $Target/...$ syntax you see in Alert Name/Description is evaluated in the monitor/rule runtime. Email notifications, however, are rendered from the Alert DataItem payload, so an SMTP notification channel can only use the

$Data/Context/DataItem/...$

variables (plus the special $Target/...AlertNotificationSubscriptionServer... variables for things like the Web Console URL).

Option A (native / simplest): use the alert’s “Managed entity” fields

For Windows Service monitoring (NT Service / Microsoft.SystemCenter.NTService), the alert’s managed entity is typically the service instance. In that common case you already have what you need:

• Service (display name): $Data/Context/DataItem/ManagedEntityDisplayName$
• Computer (hosting path): $Data/Context/DataItem/ManagedEntityPath$

So your subject can be something like:

SCOM ($Data/Context/DataItem/ResolutionStateName$): $Data/Context/DataItem/ManagedEntityDisplayName$ on $Data/Context/DataItem/ManagedEntityPath$

This is the same general pattern many people use to inject the computer name (via ManagedEntityPath) into the subject.

Quick validation tip: in the SCOM Active Alerts view, add columns Source and Path (or open the alert properties). If Source/Managed Entity Display Name shows the service and Path shows the server, you’re done.

Option B (still “built-in SMTP”, but needs one extra workflow): populate CustomField1/2 and use them in the subject

If your alert’s managed entity is the computer (so you only get server name from ManagedEntityDisplayName/Path) and you need the service name as a separate token, there’s no native SMTP-channel token that can “re-evaluate” $Target/...$.

In that case, the standard approach is:

1. write the service name into an Alert Custom Field (CustomField1..10), and then
2. reference it in the subject as $Data/Context/DataItem/Custom1$ (etc.).

A common implementation is a subscription + command channel + PowerShell that receives $Data/Context/DataItem/AlertId$, looks up the alert via SDK, and updates CustomField1/2. Microsoft has a published pattern for updating custom alert fields using subscriptions + PowerShell.

Option C (maximum flexibility): send the email via a command channel script

If you want full control (exact short ServiceName vs DisplayName, custom formatting, extra lookups, etc.), use a command notification channel and send mail in PowerShell (instead of the built-in SMTP channel).

P.S. Is your other issue (from this post) already resolved? Did my reply help you out?

Regards

Stoyan
"If my response was useful, please consider marking it as the answer. It keeps the forum clean, structured, and more helpful for everyone. Thank you for supporting the community."