I advanced to ServiceNow architect this year, and I am proud of it. But if I am honest, most of what got me here I learned by getting it wrong first. It feels less like reaching a summit and more like turning around on the staircase to see every step I tripped on along the way. I keep thinking back to myself writing my very first business rule, full of confidence and with no real idea of what I was about to teach myself the hard way. Boy, do I wish I had known about some of this back then. So, I wrote down five things I genuinely wish someone had told me before that first rule. Maybe they will save you a scar or two. Maybe you just nod along, because you picked up the same ones yourself.
1. I wish I had said no.
Early on, every request felt like something I had to deliver, and I truly wanted to. The business asked, so I built. The problem is that yes compounds. Each yes adds a little more weight to the instance, and you rarely feel it on the day you say it. And because this often happens in small 5-degree iterations, everything is "just a small adjustment, else we cannot work". But you feel it two years later, when a small change implants a new business logic, the code is not really compatible, and now it quietly touches fourteen things you forgot existed. Saying no, or asking, what is it we are aiming to achieve in the long run? We might not be able to do it like this, however what we could possibly do is. That is a skill. It took me far too long to start practicing it. But when you start to do it, more often than not I hear it resonate with the recipient.
2. I wish I had used a script include.
I solved so much directly inside business rules that should have lived in a script include. It was, to me, easy, simple and fast – all in one place, no need to open 10 scripts just to find out how something worked. I used to be annoyed with senior developers who did it clean, nice and by the book. But I started to learn and found that script includes are just exactly that: Reusable, testable, callable, and out of the execution path when it did not need to run. At the time it felt faster to write the logic right where the trigger was. And it was faster that day. It was slower every day after.
3. I wish I were more knowledgeable regarding performance.
On a PDI, everything is fast - somebody might argue slow, but the point is that the instance usually is super clean and very close to a new OOB instance - One user, a handful of records, no load. Real life is not a PDI. Real life is a table with millions of rows, integrations hammering the API(s), and business rules running on every insert and update without anyone ever asking whether it should. I did not understand what my code cost until the day it visibly cost something. Now I think about the cost first, not last. Most of what "thinking about the cost" means is just clean, deliberate code.
Nested dot-walking is the classic example: something like current.assigned_to.department.manager.email reads as one innocent line, but every hop is another query behind the scenes, and inside a loop it multiplies fast.
Use getValue() for the fields you actually need, and if you already know exactly which record you are after, a simple get() beats building a whole query for it.
Then ask yourself how much data you really need?
If the question is "how many records match", you do not need the records at all. That is a GlideAggregate with a COUNT, not getRowCount(), and certainly not querying everything into an array so you can indexOf your way through it. If the question is "does at least one exist", add setLimit(1) and stop reading after the first hit.
And let the database do the filtering. Every condition you can express as an addQuery or an encoded query is work the database is built for, instead of your script looping over thousands of records it never needed. The same thinking applies to the rule itself: if the transaction does not need the result, make the business rule async, so the user is not standing in line behind your code.
4. I wish I understood the process better.
I used to write code for the requirement in front of me, without understanding the process that the requirement came from. Where it started, where it ended, who touched it along the way. So, I built point solutions for an end-to-end story I had never actually read. Good code sitting on top of a misunderstood process is still the wrong thing. It may be well made, but if nobody understood the bigger picture, and the testing and architecting were not made on a bigger scale, it doesn't really tie together.
5. I wish I did not try to solve everything with a business rule.
When the only tool you trust is a business rule, every problem starts to look like a business rule. But there are flows, script includes, a scheduled job, client-side logic, and sometimes the right answer is nothing at all. Some things are tackled better via the process, and not the tool. The business rule is not the answer to the platform. It is one answer amongst many and knowing when not to reach for it is part of the craft.
This is not about bad developers writing bad code
Here is the part I want to be honest about. None of this means the people who built before me did poor work. The goalposts have moved. What was completely fine five years ago can be a faux pas today. The platform develops, the practices develop, and we develop with them. We learn while we live. A lot of the patchwork you find in an older instance is not carelessness. It is the fossil record of a team learning in real time and shipping with the knowledge they had on the day.
That changes how I talk to the business. When something has been patched one degree at a time, you eventually reach the point where five more degrees will make the water boil. The honest answer at that point is not another patch. It is that we should rebuild this part from the ground up. That is a hard conversation, because the process was almost never designed to end. It grew. The code grew with it. And rebuilding costs time, money, and trust. But saying it early, respectfully, and with evidence is the job.
