Discreetly positioned on the email notification form is the ability to subscribe, marked "subscribable." The property which has been both cleverly and imaginatively designed, adds a subscribe to a record mechanism. On one side, someone can interpret it as the 'mandatory' option and others like the option so users can subscribe to the notifications. I can say now, neither fish nor fowl. Two words very similar: subscribable and subscription. Have I confused you yet?

Let's talk about

• Notification 'Subscribable' , 'Mandatory' and 'Force delivery' options
• Subscribable option set to false
• Subscribable option set to true
• Testing the record-subscription based part when Subscribable is set to true

Subscribable, Mandatory and Force delivery options

On the email notification, you can set Subscribable , Mandatory and Force delivery to true or false to modify how recipients are included or excluded. These options define how the recipient list is generated from the notification user and group fields or from the cmn_notif_message table.

Here is the three email notification options in a nutshell:

Option	Value	Meaning	Purpose	Area of confusion
Subscribable	FALSE	Subscription based notifications	Normal notification	The value FALSE may look like the notification cannot be set on the notification preferences. Also the word subscribable make it looks like the mandatory field
Subscribable	TRUE	Subscribable based notifications	Add extra recipients to normal notifications based on records subscribed to by the users set on cmn_notif_message
Mandatory	TRUE	User Notification preference is mandatory to any user once they are valid recipients of the notification	User notification preference can be turn on/off but it is saved as ON whatever choice is selected	Field is hidden on the notification form whilst subscribable is not. Also it implies users will receive the notification no matter what like force delivery
Mandatory	FALSE	Normal on/off per user subscription allowed	User notification preference can be save as on or off
Force delivery	FALSE	No changes	No changes	Field is hidden. Force delivery may indicate the notification is sent immediately. There is a business rule "Update Email Devices" that makes cmn_notif_device inactive when the sys_user Notification is Disable which makes this option redundant
Force delivery	TRUE	Ignores sys_users Notification value.User Notification preference is created even if the are not valid recipients of the notification	Users receive the notification even if the user Notification field is set to Disable and their cmn_notif_device is active

Here is an example of some email notifications showing the Subscribable, Force delivery and Mandatory option set to true and the others set to false:

Subscribable option set to false

If you want a normal notification, you can set the "subscribable" to false. They use the 'Who will receive' information to generate the recipient list.

They are called subscription-based notifications because they allow users to choose which notifications they prefer to receive and which ones they don't

If the 'Mandatory' option is set to true, the notifications will be editable but will not save the "off" value on the user notification preferences. Subscribable alone does not make it mandatory.

Also mandatory respect the sys_user notification field. To ignore that, set 'Force delivery' to true, then users receive the notification even if the user Notification field is set to Disable. These fields only affect the current notification.

I have set four (4) users as follow:

User	Sys_user Notification	User Notification preferences
User1	Enable	All notifications enabled
User2	Enable	All notification disabled by setting off the dials
User3	Disable	All notifications enabled
User4	Disable	All notifications disabled by setting off the dials

Here is the result of the tests:

Notification	Final email notification
Name	Mandatory	Force Delivery	Original recipient list	Final recipient list	Email Logs shows
No1	False	False	User1User2User3User4	User1	Notification 'No1' included recipients via the notification's "Users" field: 'User1' Notification 'No1' excluded recipients because user's notification preference "Filter" filtered it (see "cmn_notif_message.notification_filter"): 'User2' Notification 'No1' excluded recipients because user's "Notification" setting is disabled: 'User3' (x), 'User4'
No2	False	True	User1User2User3User4	User1User2	Notification 'No2' included recipients via the notification's "Users" field: 'User1' Notification 'No2' included recipients because users would normally be excluded, but notification's "Force delivery" setting is enabled.: 'User2' Notification 'No2' excluded recipients because user's device is inactive (see "cmn_notif_device.active"): 'User3' (x), 'User4'
No3	True	False	User1User2User3User4	User1User2	Notification 'No3' included recipients via the notification's "Users" field: 'User2' (x), 'User1' Notification 'No3' excluded recipients because user's "Notification" setting is disabled: 'User3' (x), 'User4'
No4	True	True	User1User2User3User4	User1User2	Notification 'No4' included recipients via the notification's "Users" field: 'User2' (x), 'User1' Notification 'No4' excluded recipients because user's device is inactive (see "cmn_notif_device.active"): 'User3' (x), 'User4'

The 'Who will receive' section should not be EMPTY. If the system is not able to generate recipients, it will not generate an target email.

I created/set 3 users* aileen.mottern - aileen.mottern@example.com* alejandra.prenatt - alejandra1.prenatt@example.com* alissa.mountjoy - alissa.mountjoy@example.com I created/set 1 cmdb_ci_computer* "*DENNIS-IBM" (sys_id d0e8761137201000deeabfc8bcbe5da7)I created a new email notification test_subscription on incident as follows:Name=test_subscriptionTable=incidentInserted=checkedUpdated=checkedConditions=noneUsers=aileen.motternalejandra.prenattSubject=Test test_subscriptionBody=Test test_subscriptionI hardcoded aileen.mottern and alejandra.prenatt as recipients. I filled in the reset of the required fields so it looks like this:Then I create a new incident (e.g. INC0010021) to check the notification email results. The results confirm that notifications are sent to aileen.mottern and alejandra.prenatt.aileen.mottern and alejandra.prenatt can choose not to receive the notification if the mandatory field is set to false

Subscribable option set to true

Also called CI-based notifications build their recipient lists by two parts:

1. It generates a list of recipients like subscription-based notifications (same as with Subscribable set to false).
2. Plus, the second part which search on cmn_notif_message for users subscribed to the record received on the event as configured in the notification.

They are called subscribable notifications because the option is called subscribable and implies a "subscribe" action   similarly to a subscription business model.

The second part is complex. You MUST set the "subscribable" to true and specify 'Item table' and 'Item' fields in the notification.

Workflow to mantain the connections between the user preference on cmn_notif_message and the records may be required.

The record-subscription-based part, needs users subscribed to the 'Configuration Items' (or relevant column) on cmn_notif_message for the notification. The event itself will specify which specific record to match with the notification preferences.

There are a few subscribable notifications already provided on the system. They have 'Item table' set to cmdb_ci, sys_user, live_message, incident_alert, sys_user_group, cmn_cost_center,etc and the notifications are triggered by "xxx.affected" events. These notifications do NOT look for the data in the configuration item field on the task record (e.g. incident) as some people with good common sense may think. This is a common misconception. The subscribable notifications on the system look for affected cis related to the task.

If you are only interested on the record-subscription part, the 'Who will receive' section can be empty.

I've changed the 'Subscribable' to true (CHECKED), set 'Item table' = "cmdb_ci", and Item to event.parm1.Name=test_subscriptionTable=incidentInserted=checkedUpdated=checkedConditions=noneUsers=aileen.motternalejandra.prenattSubject=Test test_subscriptionBody=Test test_subscriptionSubscribable=checkedItem table=cmdb_ciItem=event.parm1I updated the incident created before e.g. INC0010021 and checked the notification emailResults: The notification is sent to aileen.mottern and alejandra.prenatt.Here is the example of the previous two notification sent:Note that the same notification is sent. This is because the "same as Subscription based notifications" is executed. As "subscribable" is set to true, the notification tried to match event.parm1 with the 'Configuration Items' on cmn_notif_message and can not find any matching.In a nutshell, setting the 'subscribable' = true does not affect the recipient list yet.Testing the record-subscription based part of Subscribable based notificationsThe record-subscription based part needs:Users subscribed to the 'Configuration Items' on cmn_notif_message for that notification.The notification to specify which record to match to the notification (e.g. event.parm1).To make the record-subscription-based work, you need a few users to subscribe to some Configuration Items.I logged with alissa.mountjoy. Then open "*DENNIS-IBM" on cmdb_ci_computer table and clicked the "Subscribe" link.To simplify this example, I opened the cmn_notif_message_list.do record for alissa.mountjoy and changed the Notification Message value to 'test_subscription' (from 'CI Affected').Next, I set up the notification to specify which record to match to the notification (e.g. event.parm1).To simplify the testing, I've also changed the same notification to be fired on 'ci.affected'.Name=test_subscriptionTable=incidentSend When=Event is firedEvent name=ci.affectedConditions=noneUsers=aileen.motternalejandra.prenattSubject=Test test_subscriptionBody=Test test_subscriptionSubscribable=checkedItem table=cmdb_ciItem=event.parm1Then, I manually queued the event for that CI.Note d0e8761137201000deeabfc8bcbe5da7 is the sys_id of the computer system.// Search for the incident to set the event targetvar target = new GlideRecord('incident');target.addQuery('number', "INC0010021");target.query();// Queue the eventif (target.next()) {       gs.eventQueue("ci.affected", target, "d0e8761137201000deeabfc8bcbe5da7", "*DENNIS-IBM");};The event generated was:As the event.parm1 matches the record on cmn_notif_message for the notification "test_subscription" on the notification recipients, you can see alissa.mountjoy was added.

To conclude, normal Subscription based notifications allows you to set the recipients based notifications 'Who will receive' information. This is simple and practical. Subscribable notifications allow you to notify users subscribed to reconds on the system in addition to using the 'Who will receive' fields. Subscribable set to true could add extra unwanted searches if used incorrectly.

I have tested the examples with Chrome an Fuji.

More information here: