If you've ever tried to solve this problem with one or two 'after' Business Rules that simply copy comments from one record to the other… congrats, you've discovered recursion!
Unfortunately, you've also discovered infinite loops.
If you next tried adding .setWorkflow(false) to the Business Rule that copies the field to the other record, then unfortunately you've also discovered that that breaks all the other Business Rules, notifications, and automation that should be happening.

In this article, I'm going to share two patterns for solving this problem that I think are pretty neat, clean, and effective. Both of these patterns allow you to sync journal entries between two linked records without infinite loops, without adding any fields to your tables, and without suppressing workflow.
Option 1 uses an invisible marker in the journal entry text to indicate that the update was caused by the sync process.
Option 2 is even more clever, and although it requires a tiny bit more setup (I provide the code below), it can actually work with any field(s), not just journal entries! It uses a session-scoped, record-pair-specific 'lock' to prevent the receiving Business Rule from acting on updates that were caused by the sync process.

We have a few challenges here: no .setWorkflow(false), no Task-based-table schema changes, and no ugly journal entry pollution.

Here's the scenario --
You’ve got two task-based tables that are linked.
Let's say Incident and Case.
These tables are linked in a 1:1 relationship; that is, when Incident A points to Case B, Case B always points back to Incident A, and vice versa.
(It doesn't matter if this is your exact setup or if your records are linked 1:1, this is just the example setup. This can be applied to any synced pair of records.)

There are several different ways that a 1:1 relationship could exist, and this same question could apply to two linked records in the same table, or in different tables - but just for simplicity (and clarity), let's say our setup looks like this:

• Case has an Incident [u_incident] reference field.

• Incident has a Case [u_case ] reference field.

• When someone adds a comment to either record, you want the same comment to show up on the other record.

  • (You could just as well apply this logic to work_notes or any other journal field, but we'll use comments as the example.)

• …and you want that to happen exactly once, not in an infinite summoning-circle that consumes your instance and eventually summons an angry DBA.

You can’t just do .setWorkflow(false) because you’re not trying to turn off automation. You’re trying to turn off recursion. You still want any other Business Rules to fire, notification emails to be sent out, etc.

I feel like I've solved this problem a thousand times, but it's always felt hacky and ugly... I don't think I've ever seen a solution that felt "clean" and performant, or that didn't make my brain itch because it just felt wrong and fragile.

Today, I've come up with two ways to solve this problem.
Both work. Both are pretty neat, clever, and clean. Both solve a problem that I feel like I've been plagued by a dozen times throughout my career, and for which I've never had a really solid, effective, clean solution - until now…

Some of our existing ServiceNow outbound REST calls were being made through a Flow Designer action, using an imported RestMessage with OAuth authorization (typical OAuth Application Registry and OAuth Profiles). This was initially set up since our /oauth/token endpoints were internal and not on the internet and hence had to go through a MID server to access the token endpoint and the REST step in Flow Designer supports that.

Ignoring the above reasons, since this was being triggered by a UI Action button, from a user experience perspective, there was a noticeable delay in calling and running the Flow Designer action. I decided to investigate, from a raw performance perspective, how much faster it would be to use a script instead of a Flow Designer action with a typical REST step…

I made a thing.

The script at the bottom of this article scans all scripts in a given table/field for GlideRecord queries that use if (gr.next()) {} WITHOUT a preceding .setLimit(1) before .query().

Unfortunately, since there is no way (to my knowledge) to filter out-of-box records, you're probably going to find far more massively inefficient queries in ServiceNow's out-of-box code, than in your own. In my OOB PDI with only a few SN apps installed, this script finds about 1,450 violations in OOB code (ಠ_ಠ).

But still, this should help you to identify some of the major performance-impacting scripts running in your instance, at least by this particular metric.

Why is this important?

Every time you query a table for a single record, especially if you're not querying by a well-indexed field, you're doing a "full table scan". This means that the database server is going to scan the entire table looking for ANY records which match your query, and helpfully return all of those records to the application server... but if your script running on the app server only uses the first record returned and throws the rest away, then all the rest of that work done by the database server was pointless!

Even if there is only one record matching your query in the entire table, you're still wasting about HALF of your query performance on average.

Think about it - if you tell the database server that you actually only need ONE record, then it isn't going to bother continuing to search after it's found one, right?
You can use .setLimit(1) to tell the database to stop searching after the first record is found. Otherwise, this would be like continuing to search for your keys, after you've found them.

If there are 100 places where your keys might be found, assuming they're all equally likely, then every time you lose your keys you may find them in the first place you look, or the last place you look, but on average you're going to find your keys in about the middle - about the 50th place you look.
Which means that continuing to search after you've found your keys would sometimes cost you 100x as much time as if you stopped after finding them, or if may not cost you anything extra if you found them only in the last place you looked... but on avreage, it'll cost you about DOUBLE the amount of time you would've spent if you'd stopped looking after you found them.

That's what .setLimit(1) is for.

I was sending dank memes in the ServiceNow developer community Discord server this morning instead of being at all productive in any way whatsoever - as we do be doin' over there - when someone went and ruined it by asking an intelligent question.
Unfortunately, I found this question really interesting and was thus compelled to write this article about the ideas that flowed from that conversation.
And now you have to read it.
I'm sorry, everyone.

Background Info

The specific question doesn't matter for the point that this article is trying to make (which is about how to communicate changes to your ServiceNow environment), but it helps me illustrate the point of this article (which does, I assure you, have a point).
The question was about how to modify which fields are visible in the ServiceNow Incident activity history formatter thingy - for everyone in the instance.

If you need to calculate the distance between two Location records in the cmn_location table in ServiceNow, as long as both of those locations have latitude and longitude values, you can do so using the script below!

Usage examples at the bottom.

You can turn these functions into methods of a Script Include if you like; whatever boats your float, mate.

EDIT 3/26/25: Nevermind, I turned it into a Script Include for you. 😎

Your ServiceNow instance DEFINITELY has DANGEROUS CODE executing in it RIGHT NOW, causing performance issues, unexpected behavior, and hiding records from people who should be able to see them (including you)!

This isn't a fear-mongering tactic; it's a fact we all overlook - until it's too late.

In this article, we'll unveil the top five quick and efficient methods to uncover this concealed, risky, and performance-degrading code in your instance. But that's not all - we'll also shed light on other lurking risks that could be silently sabotaging your instance's performance or security - even as you read this!

“I have some records in a table which are duplicates. In this case, I can only identify “duplicate records” by whether several fields are identical; not just one. For example, let’s say I want to identify Incidents where the Short description, Assignment group, and Assigned to user are all the same. If only one or two of those fields match, but one of them is different, then the records are not duplicates. The’re only duplicates if all three fields are the same.

Is there any way to accomplish this with a script? Maybe by using GlideAggregate?”

Thanks for your question, and indeed, there is a way to identify duplicate records based on multiple matching fields in a script in ServiceNow!

At first glance, you might think that the GlideAggregate APIs do not support any direct mechanism by which to identify duplicate records across multiple identical fields. However, there is a way!
By getting just a smidge clever, we can call the .groupBy() API method multiple times, in combination with the .addAggregate() and .addHaving() methods, to accomplish our goal of identifying duplicate records with more than one field that are identical.

Read on to learn more!

If you got your ServiceNow certifications or made progress in courses on NOW Learning using a ServiceNow partner or customer account, you may find that when you move on to another company, you no longer have access to those certifications or training progress. This can be frustrating, and unfortunately the process for migrating your certifications and progress from an account linked with your business email to your personal account is not always clear. Googling the question (at the time of writing), I found that the top several results were from old ServiceNow Community articles that are either no longer accurate, or perhaps never were.

This ServiceNow Pro-Tip article was inspired by a thread on the ServiceNow Developer community Discord server, and aims to give you an up-to-date and accurate answer as to how you can merge your old corporate ServiceNow / NOW Learning account from your ServiceNow partner or customer business email into your personal account, so you can retain your certifications and progress even after you’ve left the customer or partner company. If ServiceNow changes the process by which this is done (again) and you notice that this article becomes outdated, please leave a comment below and let me know the updated process so I can update this article and keep folks informed.

I believe that Richard Feynman can teach ServiceNow developers (and any software developers) a great deal - about physics, sure; but also about our own discipline.

I'm something of a physics nut myself (insert Spider-Man meme here), which has led me to something of an obsession with Richard Feynman. His work, of course (I've even got a Feynman diagram tattooed on the back of my neck), but also his life and upbringing. I'm interested in how someone like Richard Feynman was raised, and what lessons can be taken about how to raise children to become people with his best qualities. Qualities like intellectual curiosity and earnest, unabashed, confident-yet-humble exploration.

I once talked about the importance of confident-yet-humble exploration of new topics on a podcast with Robert Fedoruk and Cory Wesley. You can jump straight to the relevant time-code in that episode if you're interested in hearing it, here. (https://perspectives.snc.guru). This is a topic about which I am deeply passionate. I strongly believe that if we had more people with the sort of confident and humble intellectual curiosity of Richard Feynman, the world would be a much better and better-off place.

So, to that end, here are a couple of lessons I've taken about software development, from the late great physicist, Richard Feynman.

While watching this video by the venerable Jace Benson, I was inspired by an idea presented around the 4-minute mark: a more effective way to manage instance-specific System Properties. So inspired was I, that I decided to not only adopt his suggestion, but to write a little tool to handle it for me as well! I call this tool "Local Properties". 'Local', here meaning "instance-specific"; properties which should have one value in one instance (such as your dev environment), and a different value in a different instance (such as production).

As many developers will know all too well, this is a problem that we face often: How do you use one property value in one instance and another value in another instance, without risking poisoning the data in the higher instance just by modifying the value in a lower instance (and perhaps not even realizing that it's been captured in your update set)?

In this article, we're going to discuss the idea that Jace presented to solve this problem in a robust and elegant way, as well as a free tool that I've built to handle this for you!