What led me to this thread?
After observing the format used in the event registry - incident.commented, attachment.deleted, it left me wondering if registering events in a certain format in the event registry does help the platform recognize what action has happened. And I overlooked the answer which was there right in front of me.
The IF condition - that validates the action!
So, the if condition says if an action happens, trigger an event log with some inputs from the record the event is triggered.
And why is it (Event registry entries) named so?
It is done so to identify what action has happened while on the Event logs or if I name the action - commenting on incidents as INC_CMT, there are chances others cannot interpret it. So, entries in Event registry follows a sort of naming convention there to give a common understanding.
<table_name>.<event_to_react_to>
And the actual purpose is to dynamically pass record or session related info.
Product documentation - Events are special records the system uses to log when certain conditions occur and to take some kind of action in response to the conditions.
The system uses business rules to monitor for system conditions and to generate event records in the Event [sysevent] table, which is also known as the event log or event queue.
Registering an event in the Event registry and calling that via a Business rule:
Event-generating business rules typically use this script logic:
If [some condition is true for the current record], then [add a specific event to the queue].
********Product documentation text ends*****
This is what we saw in the incident events BR.
So, gs.eventQueue() basically adds the registered event (entry found in the Event registry) into the queue or the event log. (sysevent.LIST)
Based on the parameters provided in the gs.eventQueue() method, Parm1 and Parm2 stores the record or session relevant information.
Which record? - the record on which the event is run. For example the event 'incident.commented' registered on the incident table (OOTB) passes session related info to Parm1 and Parm2 when an incident is commented.
Instead I can chose to pass incident related info as well by replacing the 3rd and 4th parameters on the gs.eventQueue() method with current.<field_name> arguments. So, that will store the field values in the Parm1 and Parm2 respectively.
And these values can be accessed from places we write scripts in ServiceNow using 'event' or 'current' objects. (not all though)
Well, that was some learning for the day!
Cheers to all learning the platform!
