- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
16m ago
One thing I've learned working with ServiceNow is that not every problem needs to be solved with a Business Rule, Flow or Script.
Sometimes the real problem is simply that a team isn't following the process.
And this is where we often get requests like:
"Can we just auto-approve this?"
"Can we close the ticket automatically?"
"Can we reassign this so the team doesn't have to deal with it?"
Technically, yes. We can probably build it.
But should we?
When we keep adding automation to work around a broken process, we're not really fixing the problem. We're moving it somewhere else.
Today it might be a small Flow. Six months later, someone asks why it exists. A year later, the original team has changed, the process has changed, and nobody remembers why that logic was added in the first place.
The platform ends up carrying the cost of a process that was never really fixed.
As architects and developers, I think part of our job is knowing when not to build something.
Sometimes the right answer isn't another automation.
It's a conversation with the process owner and asking:
"Why are we trying to bypass the process in the first place?"
Good architecture isn't just about making the requested solution work.
Sometimes, it's about pushing back and fixing the problem before we turn it into code.