Grouping toast notifications under different headers in Action Center – Windows 10 Creators Update

Note: The new feature(s) covered in this post are available to Windows Insiders running build 15002 or newer. If you are using the NuGet UWP notification extension library, the feature(s) can be found in the beta version here.

New in Creators Update: In the most recent Windows 10 Creators Update, we added several exciting improvements and new features to toast notifications and Action Center. One of them is allowing developers to group and categorize different notifications under different headers inside Action Center.

Notifications inside Action Center are ordered on a per app basis, with the most recent notifications on top. When an app is sending multiple notifications of different kinds to the user, it is sometimes helpful to further separate these notifications, so that users can visually distinguish one category of notification from another.

Let's take Cortana as an example. Based on each user's needs, Cortana can surface multiple types of notifications, including future commitments, event reminders, flight reminders, etc. When these notifications are presented to the user inside Action Center, it helps if these notifications can be viewed and managed separately.

As you can see in the picture below, Cortana has created several different headers for their various notifications, helping users clearly distinguish between upcoming events and upcoming flight information.


The new notification header has several properties that may or may not be obvious to you just by looking at the picture:

  • The header visually separates notifications for the user; it doesn't change the fact that each app can send up to 20 notifications under the app title (in the image above, the app title would be "Cortana") and notifications are arranged in a First-In-First-Out manner. In comparison, we have a separate upcoming feature - toast notification collections - that lets you create separate titles, each with their own 20 limit. The collection API's will be covered by a separate blog post once the feature makes its way to Windows Insider builds;
  • Note: The header feature is available in Windows Creators Update on Desktop SKU devices. The same feature will be made available to mobile in a future release. Collection APIs - another method to separate notifications inside Action Center as mentioned above, will be available universally on both desktop and mobile SKUs.
  • Notifications under different headers are ordered as follows: within each app title, the most recent notification, along with its header, along with all the notifications belonging to the same header, go on top;
  • Each header is clickable by users - the developers can define the title string as well as the launch argument and activation type for each header, and it will launch as if it is a toast notification activation. You can check out the code sample below for more details;
  • Developers can update an existing header without affecting the notifications under it by reusing an existing header id and providing a new title and launch arguments;
  • Creating headers doesn't change the number of notifications shown inside Action Center before the user clicks on the "See more" button to expand the full list (this number is 3 by default and can be configured by the user for each app in Windows notifications setting);
  • Clicking on the header, just like clicking on the app title, does not clear any notification belonging to this header (your app should use the toast API's to clear the relevant notifications).

Let's take a look at how a header is created. The code and XML samples below match the very first notification in the image shown earlier.

ToastContent toastContent = new ToastContent()
    Header = new ToastHeader()
        Id = "Cortana_interest_3",
        Title = "Don’t forget what’s coming up.",
        Arguments = "navigate_interest_3",
    Visual = new ToastVisual() { ... },
    Actions = new ToastActionsCustom() { ... }

"I’ll share the sales updates with you by EOW." Sent to: Satya Nadella Review in Outlook

As you may have noticed from the sample code, each header is defined by a header element inside the XML payload. You have to include all properties every time you send a toast notification, including title and launch arguments, even if you've already "created" the header in a previous notification.

Here are the definitions of the new elements and attributes in the XML schema:

<header> Header element is a direct child of the root element <toast>. It indicates that the notification needs to be visually shown under a "header" for content separation and categorization. It contains all the information required for the OS to render the header.
id Required string, uniquely identifies a header.

When a new id is used, Action Center will treat this as a separate header. Any other notifications with the same header id will be displayed under this header. The header information (like title) from the newest notification will be rendered. Therefore, you can "update" an existing header when you send a new notification by simply using the same id and providing different title, arguments, and activationType values.

title A required string value.

This is the header string that is displayed in the notification and Action Center.

arguments A required string value.

The arguments attribute describes the app-defined data that the app can later retrieve once it is activated from user taking this action.

In case of a protocol activation, the arguments is a Uri that OS will try to launch with LaunchUriAsync(). Otherwise, activation behaves identically to toast notification activation.

activationType An optional enum value.

activationType? = "foreground | background | protocol"

This is an optional attribute, indicating whether clicking the header should trigger a foreground activation of the app, a background activation of the app, or a URI protocol activation.

Default value is "foreground".

Comments (4)

  1. That’s the plan. Long paths will work if (1) the OS supports it and (2) the app is targeting .NET Framework 4.6.2. However, it’s important to keep in mind that Windows is large not every API and component will support long paths but we consider those bugs at this point. Same is true with .NET itself. We haven’t yet updated the VM to support loading DLLs on long paths. So take this feature in .NET Framework 4.6.2 as a large step in the right direction, but don’t expect that Long Path issues are completely gone yet.

  2. I’m running into a conflict between System.Globalization and the new System.Web.Globalization namespace introduced in this version, that only appears at runtime. Details at you take a look?

  3. This doesn’t make any difference. I have installed the dev pack and uninstalled it and re-installed it but it does not show up inside VS. Also I cannot find any trace of 4.6.2 in C:\Windows\Net.Framework dlls.

  4. Rudy H says:

    Little issue with the example, the header is not displayed cause there is a little typo: it’s activationType instead of “activationtype”

Skip to main content