Custom Solution

[ShontuB]

How do we decide between using 'Out-of-the-Box' functionality and building a custom solution?

[glideFather]

Hi @ShontuB,

there's no universal answer to this. Every single organisation will manage this differently depending on their tools/product/industry/maturity in ServiceNow they have achieved. Even the same company will most likely give you different answer today and in a year :))

Customisations will make your process, needs and requirements more personalised but on the contrary it makes the maintenance more difficult. So it shall be a healthy compromise and the customisation shall be selected only if it has some big benefit. If you customise a half of the platform for a group of 20 people then it was not worthy (exaggeratng but you got my point right).

When I was enrolled to the ArchX class, there was one or two activities on this topic, how to communicate and explain it. Also there was recommended methodology called Business-smart customisation, you can read about it to get some ideas suggested by ServiceNow. 

Let me know what do you think about it.

PS: my technical experience is that heavy customisations are almost always bringing more troubles than benefit, at least from my understanding :)))

[Robb Perk]

How to decide:

• Start with: "Can I do this with built-in features?"
• Only build custom if the answer is clearly "no"
• If you do need custom work, try adding to the existing structure first, not building something completely separate

Out-of-the-box vs. custom in PSDS comes down to three decision gates:

1. Does the built-in software already do what you need?
   PSDS comes with standard features for cases, intake forms, tasks, and workflows that work for government agencies. If your work fits these standard patterns, use them. This keeps you compatible with software updates and makes it easier for ServiceNow to support you
2. Can you solve it by configuring, not coding?
   If you can set it up using forms, rules, fields, and workflows without writing code—do that. Configuration is simpler to explain, easier to test, and less risky. Only write code for things that really can't be done any other way (like connecting to an old system, doing complex math, or calling an outside service). This is especially important in government where you need to document and justify every change.
3. What will it cost down the road?
   Built-in features work with every software update. Custom code often breaks or needs fixing when the software updates. Custom code also means more testing, more documentation, and more risk in audits. Using built-in features stays simpler.