- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 hours ago - edited 3 hours ago
It Started With a “Wait, What?” Moment
You know that feeling when you look at a technical solution and can’t help but think, ‘Wow, that’s… a lot’? I had one of those moments recently. While looking into a client’s ServiceNow setup for Incident tickets, I found a surprisingly complex system for what should have been a simple category selection.
The Requirement
The business requirement was straightforward:
- When an agent selects Category Level 1, the system should dynamically display dependent Category Level 2 and Category Level 3 options.
- This is a common use case in ServiceNow, typically handled using reference fields and dependent field configurations.
The Implemented Solution
To achieve this, below created:
- Three separate tables: one for each category level.
- Each table included a reference to the previous level (e.g., Level 2 referenced Level 1, Level 3 referenced Level 2).
- These tables were then linked via reference fields in the Incident form.
This setup was mirrored in their custom case management application, where they added even more tables to replicate the same logic.
Why This Is Problematic
So, what’s the big deal? It kinda works, right? Well, “kinda working” is the fast track to technical debt. This multi-table approach isn’t just clumsy; it’s a trap waiting to spring.
- The Maintenance Quicksand: Want to add a new laptop model as a Level 3 choice? First, you have to find its parent in the Level 2 table. Then, make sure that parent has a connection to the Level 1 table. It’s a tedious, error-prone process that turns a 30-second task into a 5-minute investigation.
- The Scalability Wall: The business just decided they need a fourth level of categorization. With the multi-table method, you’re now stuck creating a brand new table, adding more reference fields, and untangling all your logic. Your “solution” has hit a dead end.
- Reporting Spaghetti: Your boss wants a simple report on all hardware incidents. To get the full category path, you have to dot-walk across a spaghetti junction of tables: Category Level 3.Parent.Parent.Name. It’s messy, slow, and makes simple data analysis a chore.
- The House of Cards: With your data spread thin across multiple tables, the whole structure becomes fragile. One broken reference or an orphaned record can cause confusion and errors on the front end.
There’s a better way. A cleaner, smarter, and ridiculously scalable way. And the best part? It only uses one table.
A Simpler Alternative
The unsung hero of elegant data architecture in ServiceNow is the self-referencing table. The concept is brilliantly simple: you create a single table that holds all your category levels, and you add a “Parent” field that points right back to the table itself.
Think of it like a company org chart. A manager is still an employee, right? They just have other employees who report to them. Our category table works the same way. “Laptop” is just another category, but its “parent” is “Hardware.” It’s all in the same happy family.
- Create one Category table with fields for Level 1, Level 2, and Level 3.
- Use reference qualifiers or UI policies to filter dependent fields based on the selected parent category.
This approach is:
- Easier to manage
- More scalable
- Aligned with ServiceNow best practices
- Not a single line of code
Step-by-Step Guide: The No-Code Approach
Step 1: Create the Unified Category Table
First, we need a single home for all our category choices.
- Navigate to System Definition > Tables and click New.
- Create a new table “ Ticket Categorization” with the following details:
Step 2: Populate Ticket Categorization Table
Use either excel to upload the data or manually.
Manually upload the data like below:
Step 3: Configure the Incident(not limited to) Form
Now let’s add the fields to our Incident form.
- Open any Incident record and right-click the header to choose Configure > Form Designer.
- Create three new fields in a new Section on the Incident table:
Step 4: Add the Dependency with Reference Qualifiers
This is where we make the fields dependent on each other without writing a single script include or client script. We’ll use “Reference Qualifiers.”
- Go back to the Incident form. Right-click the label for Category Level 1 and select Configure Dictionary.
- In the Reference Specification tab, find the Use reference qualifier condition and set below:
Now, repeat for the other two fields, making them dependent on the previous selection.
For Category Level 2:
- Right-click the Category Level 2 label, select Configure Dictionary, and go to the advanced view.
- In the Dependent section, add the field name for level 1 i.e u_category_level_1. No need for the additional qualifiers
For Category Level 3:
- Right-click the Category Level 3 label, select Configure Dictionary, and go to the advanced view.
- In the Dependent section, add the field name for level 1 i.e u_category_level_2.
And thats it. The Hierarchy will work as expected with no messy data model and complex architecture
Demonstration
The Payoff: Why You’ll Love This Method
Go ahead, try it out on your Incident form. It works like a charm. But the real victory isn’t just that it works; it’s how it works.
- One Place to Rule Them All: Your entire category system is now in one list. It’s ridiculously easy to manage.
- Future-Proof Your Design: Need that fourth level? No problem. Just add the data and a new field on your form. You’re done in minutes, not hours.
- Reporting Made Simple: All category levels are direct references from the Incident. Reporting is clean, fast, and spaghetti-free.
- Build It Once, Use It Everywhere: That little “Table” field is your golden ticket. You can run categories for Incidents, Cases, Changes, and more, all from this single, elegant table.
So, the next time you’re tasked with building a hierarchy, remember to build smart, not hard. A single, self-referencing table isn’t just a “good” solution — it’s the clean, scalable, and maintainable foundation that you and your future self will be thankful for.
What are your favorite “simple” solutions for common ServiceNow challenges? Share in the comments below!
Happy learning!
Connect with me on LinkedIn