Salesforce Dictionary - Free Salesforce GlossarySalesforce Dictionary
Full Custom Notifications entry
How-to guide

Creating a Custom Notification Type and firing notifications

Setup work has two halves: define the notification type in metadata, then wire up Flow or Apex to send notifications using that type. Type definition is one-time; the send wiring is per-use-case.

By Dipojjal Chakrabarti · Founder & Editor, Salesforce DictionaryLast updated May 16, 2026

Setup work has two halves: define the notification type in metadata, then wire up Flow or Apex to send notifications using that type. Type definition is one-time; the send wiring is per-use-case.

  1. Create the Custom Notification Type

    Setup, Quick Find, Custom Notifications. New. Enter a name (Approval Required), an API name (Approval_Required), and select supported channels (Desktop, Mobile, or both). Save. The type is now available to flows and Apex.

  2. Wire up the Flow action

    Flow Builder, add Action, search Send Custom Notification. Pick the type. Set the recipients (single user, public group, queue, or comma-list of IDs), the title (supports merge fields), the body, and the Target ID (typically the triggering record's Id). Activate the flow.

  3. Or wire up Apex

    Query the type ID, instantiate Messaging.CustomNotification, set typeId, title, body, targetId, then call send(Set of UserIds). Bulkify by passing a Set with up to 500 IDs per call. Wrap in Queueable for higher volumes.

  4. Test as the recipient

    Switch user to a recipient or use Login As. Confirm the notification appears in the bell icon. Click through to verify the target page resolves. Test mobile separately by triggering from a device where the Salesforce mobile app is installed and notifications are enabled.

  5. Audit user notification settings

    Each user can mute notification types in their personal settings. After rollout, check user adoption; muted notifications fail silently. Communicate the new notification type to users before enabling it on production data.

Supported Channelsremember

Desktop, Mobile, or both. Desktop covers the Lightning bell icon. Mobile covers iOS and Android push through the Salesforce mobile app. Enabling Mobile without device registration leads to silent drops.

Recipient typeremember

Single user, public group, queue, or set of user IDs. Flow exposes all four; Apex takes a Set of IDs and resolves group or queue membership at send time.

Target IDremember

Record ID for the click-through. Lightning resolves the page type from the record prefix. Custom destinations (tabs, URLs) require building a PageReference object instead.

Notification Builderremember

Setup, Notification Builder controls which standard and custom types are available org-wide. Disabling a type here hides it from all users without deleting the metadata.

Gotchas
  • Users can mute notification types in personal settings. Muted types silently drop on send; the Apex call returns success.
  • Mobile push requires the Salesforce mobile app installed, registered, and with notification permissions granted on the device. Otherwise the notification only appears on the desktop bell.
  • The 500-recipient-per-call cap requires batching for larger audiences. The platform does not auto-batch; you have to chunk the set yourself.
  • Custom Notifications and the older Push Notification API are independent. Migrating from one to the other requires rewriting the send logic.
  • Title and body are limited to 80 and 750 characters respectively. Long messages truncate silently on mobile push.

See the full Custom Notifications entry

Custom Notifications includes the definition, worked example, deep dive, related terms, and a quiz.