ServiceNow Flow Designer in Production: Patterns I Trust and Patterns I Don’t
A client called me a few weeks ago because their new HR onboarding flow had been failing silently for eleven days. Nobody had noticed. The error handler on the parent flow caught the exception, logged a one-line message to a custom table, and quietly moved on. Twelve new hires started that fortnight without laptop requests, access provisioning, or payroll setup. The flow was green in Flow Designer. The dashboards were green. HR found out when the first employee emailed asking why she had no laptop on day three. That is the problem with ServiceNow Flow Designer in production. It makes building the happy path trivial, so teams build the happy path and move on. The error paths, the retries, the idempotency, the observability, the subflow boundaries, the integrationhub rate limits, none of those get the same attention. Six months later the instance is covered in flows that work until they don't, and when they don't, nobody can tell. I spend a lot of my consulting time on ServiceNow Flow Designer, both greenfield builds and rescue work on flows other people wrote. The patterns below are what I have learned to trust, and the ones I have learned to rip out when I inherit them.
