Every ServiceNow developer, administrator, and architect has at one time or another, got a requirement from their client that they know is bad-practice, silly, or sub-optimal.

I often come across developers in the ServiceNow communities (such as the ServiceNow developer community forums, Discord, or Telegram groups), having conversations like this:

How do I do X?
“Why would you want to do that? What’s the goal?”
Because that’s the requirement from the client.

Even when told that what they want to do is technically impossible, some will refuse to go back to the client and tell them that.
It’s as if people sometimes can’t fathom telling a client “that’s not possible but, if you tell me why you want to do it, I might be able to find a better way”.

Never jump straight into implementing ‘as per requirement’. Think carefully about it first, and consider the following things:

1. Is what they’re looking for actually possible?
   Clients rarely understand the ServiceNow platform well enough to tell their developers prescriptively what to do - but that doesn’t stop them from trying! Before agreeing to build it, ask yourself: is what they’re looking for actually possible? And if it is, will what they’re asking for actually accomplish their goals?

2. Did the client tell you what they want to accomplish, or did they tell you how they want to accomplish it?
   If the latter, there’s a good chance that there’s a better way to do it, and a very good chance that you know best. Stop, and ask them what they’re really trying to accomplish. Understand not just how they want you to do something, but why they want you to do it and what the result they’re looking for is!

3. Do you understand the underlying business-need?
   If a client says “create a reference field on this table that points to that table and uses this reference qualifier with this auto-population logic”, then they’ve only told you how to accomplish something. This is no good (see point #1). If they instead tell you “Add a field to this table to store the caller’s manager”, that’s slightly better. Now you know what they want to accomplish, not just how; but it’s still no good. You need to understand why they want you to do that, in order to advise them properly.

4. Is there a better way to accomplish their goals?
   For example, imagine a client tells you they want you to create a new field on the Request Item table to store a reference to the manager of the requestor.
   Cool, you know how to do that… but, why? Why do they want that field? Ask them!
   If they tell you that they want to be able to create a report on which managers’ teams are submitting the most requests then, just by asking that question, you’ve saved both the client and yourself a fair amount of time, work, money, unnecessary customization, and technical debt - because there’s no reason to create a new field to accomplish that goal. Instead, you can educate them about “dot-walked” or “derived” fields that can be shown in lists, forms, and reports!

To put it another way: Before launching into developing for any given requirement, make sure that you understand what they want and why they want it, and that you have thought carefully about how to do it.
But that’s the beginning of the process; not the end. The next step is to think: “is there a better way?” - and if so, to tell the client about it! Tell them what the ‘better’ way is, tell them why it’s better, and - at least in broad terms - how you’ll implement it. List the advantages and, as it relates to their business-need, tell them if there are any disadvantages.

You have been hired by your employer or client precisely because they DON'T know how to do your job; because YOU are the expert!

If you're an expert on a dangerous jungle, someone might hire you to guide them through that jungle.
After all, you're the expert. You know which vines are poisonous, which animals are venomous, which paths are safe, and how to not get yourself killed.

If the people who hired you as their guide tell you they'd like to go for a dip in what you know to be piranha-infested waters, would you just say to yourself “Well, that's the requirement... Okay”?

Of course not!

You'd say “Trust me; you don't want to do that. You'll regret it. There be piranhas. 🐟 There's a safe place to swim just over here...”

What’s more; if you were the customer in this scenario, and your guide let you blithely walk into a deadly situation that they should've known how to avoid, would you not be FURIOUS!? (Up until you were eaten alive, at least.)

If you're a ServiceNow developer, then ServiceNow is the jungle and YOU ARE THE GUIDE. You have been hired to BE the guide.
Don't forget that.

❓ Question every requirement.
🚫Never implement a requirement without understanding the true purpose (including the underlying business-need).
✋Push back if they want something risky, wrong, or that can be accomplished in a better way.
🙋‍♂️Offer better solutions to accomplish their actual goals.

They will thank you for it.
And if they don't - if they give you flak for (politely and respectfully) asking questions - RUN.
Get out of there.
Find a new job, or new clients, as quickly as possible.

As Rob Fedoruk would say: don't make the mistake of robotically and thoughtlessly building things "as per requirement".

You are the guide.
Be the guide.

Have you run into other developers who don’t seem to get that they’re supposed to ‘be the guide’? Send them this article at betheguide.snc.guru to remind them that it’s not only okay to question requirements - it’s downright expected!