Search for a command to run...
Optimize ServiceNow Usage: Effective Event Strategies
I am a technical architect and ServiceNow enthousiast. Since then I have been obsessed with development and later on application design & architecture. Today I'm using my skills to design solutions for IT companies within the ServiceNow industry whilst in my free time, spent the majority of my time creating applications for all kind of things unrelated to ServiceNow.
No comments yet. Be the first to comment.
What is the ArchX program? The ServiceNow ArchX program, a 4-week cohort-based program built by ServiceNow for early-career architects. The program aims to teach students how to excell in the world of
Today I successfully passed the ServiceNow Certified Implementation Specialist exam for Customer Service Management. In this article, I will be sharing my personal experience with the preparation, the training material provided by ServiceNow, and my ...
For developers, adopting coding habits is crucial to increasing productivity and enhancing the maintainability of their implementation solutions. This article will cover 5 must-know skills every ServiceNow developer should master. 1️⃣ D.R.Y (Don’t ...
Learn the Best Situations for Scoping and What Needs to Be Scoped
Understanding ServiceNow's Conditional Table Query Range ACLs
In ServiceNow, you can create something called an "event." These events are a powerful feature that can trigger numerous results as part of something happening in the platform. Yet, even the most experienced developers seem to misunderstand what an event is actually used for, how to name them, and furthermore, when and how to use them.
An event represents something happening. In ServiceNow, this is no exception. An event in ServiceNow represents something happening on the ServiceNow platform. Some examples of events in ServiceNow are:
attachment.read
task.approved
login
mid_server.down
Events are pushed into the event queue, after which they will be processed by the listeners.
A mistake I often see is events being written with the purpose of making something happen. Let’s look at a specific example:
incident.send_reminder_email
This example event describes what should happen, making this event only applicable for sending out a reminder email. This is wrong and not how events are supposed to be used.
Instead of sending out the event to trigger an email reminder, define an event that could result in sending out a reminder email. For example:
incident.pending_approval.wait_time_exceeded
In this case, we can define one or more triggers that should each act in their own way based on the occurrence in the system. Some example triggers are:
Execute a flow
Send out a notification
Run a script action
Each trigger has its own purpose and reason to act based on the event.
ServiceNow is not an OOP (Object-Oriented Programming) based platform. Therefore, extending events in ServiceNow is not an option. However, you can still make use of abstraction in events because of how business rules work in ServiceNow.
Let’s take the following examples:
| event | description | implementation |
| task.updated | triggers when a task record is updated | business rule on task table |
| incident.updated | triggers when an incident got updated | business rule on incident table |
If you implement the event calling based on the table described above, updating an incident record would trigger both the incident.updated and the task.updated events. This is because the incident table extends the task table, and thus the business rules of the task apply to the incident table.
This is where the power of abstraction comes into play. We could define a trigger on the incident.updated to act only upon incident updates, while at the same time, we might want something completely different to happen that should apply to all task records. Something that wouldn’t be directly tied to any process, but more to the platform itself.
Events are also very effective for listening to changes in other applications. When creating your application, consider defining events for certain occurrences in your application, even if you don’t have an immediate implementation for them yourself. This would allow other applications or implementations to listen for these events and act upon them. This is one of the many ways to allow others to build functionality on top of your application without needing to change anything in the application.
In ServiceNow, events are very important because they mark when something has happened. Events are meant to describe occurrences, not dictate what should be done next. Issues can arise if one attempts to do too much. A frequent example of this would be naming events after the actions they cause instead of the situation that brought them into that scenario. For instance, better defining an event does wonders for clarity. It’s better to describe “incident.pending_approval.wait_time_exceeded” because it is much more informative. Describing it as “incident.send_reminder_email” shifts the focus to response, not the trigger, which defeats the purpose.
It can be beneficial to think about abstraction when designing events, even if an object-oriented framework is not the base of ServiceNow. This is especially useful because business rules tend to cascade through related tables. That leads to more specific event listeners rather than wide-net listeners. That is when the power of the platform really stands out.