is it possible to use "Subscribed By" on CI to receive notification

[alexandreinthip]

Hi All, i found questions with the same subject, but i don't find my answer.

What is the real use of "Subscribed by" (to find it we have to go to configure->Form Layout and add the field) and what is the difference with the link Subscribre/unsubscribe ?

I would like to know if it's possible to use the feature "Subscribed by" where i can add some users to receive any notification about Inc,Pbm,Chg which are related to a CI?

Thanks a lot for your time.

Alexandre INTHIPHAB

[alexandreinthip]

it's fun, i created other notification with other table like base on the same event Ci.affected

CI affected_byCHG, table : Change

Ci affected by PBM, table : PBM

and sometimes, i don't know why, after 10 minutes i created my incident, one of the notification is launched and send a mail to the subscribers.

But i don't know why sometimes it works, and other times is not.... I will retry to do the same action i did...

[Sebas Di Loreto]

[SOLVED] A few days ago I had the exact same question and figured how the whole "CI affected" notification works. I will explain it here for the benefit of everybody.

The "CI affected" notification process has 4 components that you must understand:
1 - The actual subscribe/unsubscribe button on the CIs,
2 - A Business Rule in the task table ("Sync CI with Affected CIs") that copies the CI on the ticket (INC/CHG/PRB, etc.) to the affected CIs table (task_ci) whether you display task_ci as a related list or not on your ticket. This happens every single time.
3 - A ASYNC Business Rule in the task table ("Affected ci notifications") that triggers the whole process (scripted) to discover what subscribed CIs (including the upwards relationships) should be notified and to whom. This business rule is where you can add conditions to only notify in the INC/CHG process for example (task_type=CHG & state changes to assess OR task_type=INC & state changes to in progress). This will minimize the amount of notifications, otherwise it will send one every time the ticket is updated which could be too much.
This is how it works: it gets all the affected CIs for the task at hand, then aggregates all upward related CIs to them (var batch in the script), then checks who subscribed to the batch list and finally will trigger the ci.affected event for each CI. The notification will pick up the rest.
4 - A "CI affected" notification for the incident table that will fire based on the ci.affected event. The key here is to ensure it is "subscribable", Affected field on event=parm1 and item table=cmdb_ci (who will receive section of the notification). This is the out of the box. You may want to put a checkmark on the "Send to event creator" during your testings.

The final result is that you will see on the ticket's notes, one notification for each affected CI to all the people that subscribed to that CI.

Observations: even though that notification (4th component) is on the incident table, it works for any other task since it is fired through an event. There is no need to create separate events nor notifications for each stream (CHG, PRB, etc.).  Try the out of the box first with a change or problem and you will see what I mean. 

As you noticed, you don't need to subscribe to every CI in the relationship to be informed. Subscribing to the top of the relationship (usually the application layer) will be enough to receive "CI affected" notifications when any CI underneath (server, DB, etc.) is used as an affected CI on a task.

I hope this helps you using this great notification feature in ServiceNow.