As ServiceNow developers, we've all seen the temptation to drop a sys_id directly into a business rule for assignment logic. It works... until it doesn’t.
In this episode of Did You Know: Best Practices, Shamma Negi walks us through the dangers of hardcoding sys_ids in your logic. Specifically, she demonstrates how code that assigns groups based on sys_ids can fail when moved across environments because those IDs may not exist in the target instance.
Instead of relying on brittle IDs, Shamma shows how to use Assignment Rules, a powerful out-of-the-box feature in ServiceNow. She walks us through a demo where an incident gets automatically assigned to a database group when the communication channel is Chat, using only names and conditions, no hardcoded IDs.
But the learning doesn’t stop there. We wrap up with four best practices:
-
Use System Properties for sys_ids if absolutely necessary. This makes your config more portable.
-
Leverage Decision Tables for complex assignment logic that evolves over time. They’re visual, scalable, and maintainable.
-
Include Key Records in Update Sets or seed data to ensure consistency of critical configuration across instances.
-
Run Instance Scans regularly. These help catch hardcoded references or other no-no's before promoting to production.
Whether you're building new apps or maintaining legacy ones, this episode is a quick but critical reminder: clean logic is portable logic.
If you’ve got a clever trick or a lesson learned from the trenches, we’d love to hear it! Drop it in the comments or tag us in the community!
