Record Producer routing flow
The producer maps user input to the Incident. A maintained routing table decides ownership, with a safe fallback for unmatched combinations.
Map only valid target fields
Map producer variables to the created record using backend field names. Validate optional custom fields before setting them, and keep the mapping readable so future changes are safe.
- Use backend names
- Handle empty values
- Validate custom fields
- Keep routing separate from display logic
Centralise assignment logic
When assignment depends on category, subcategory, technology or application, use a maintained mapping table or Decision Table. This is easier to support than a long chain of hard-coded conditions.
Minimum test set
Test every supported combination, an unsupported combination, empty optional values and inactive mappings. Confirm the created incident values, assignment group and user-facing error behaviour.
Implementation steps
Follow these steps in a personal developer or sub-production instance. Validate backend names and choice values before using the solution in production.
Create clean variables
WHERE: Record ProducerUse backend names for category, subcategory, technology, application and description. Keep labels human readable.
Control dependent choices
WHERE: Catalog Client Script or data lookupShow only valid subcategories and technologies. Do not rely on hidden invalid values.
Create a routing mapping
WHERE: Decision Table or mapping tableStore category, subcategory, technology, assignment group and active status in a maintained table or Decision Table.
Map producer values
WHERE: Record Producer scriptSet only valid target fields and handle empty optional values.
Apply safe fallback
WHERE: Server-side routingWhen no active mapping exists, assign a triage group and log the unmatched combination.
Test every combination
WHERE: ATF and manual testCover valid, inactive, missing and unsupported combinations as multiple personas.
Practical Record Producer mapping script
Replace table and field names with the verified backend names from your instance. Add a governed fallback instead of silently leaving assignment empty.
(function producerScript(current, producer) {
current.contact_type = 'self-service';
if (producer.category)
current.setValue('category', producer.category.toString());
if (producer.subcategory)
current.setValue('subcategory', producer.subcategory.toString());
if (producer.description)
current.setValue('description', producer.description.toString());
var route = new GlideRecord('u_ultimatix_incident_mapping');
route.addActiveQuery();
route.addQuery('u_category', producer.category.toString());
route.addQuery('u_subcategory', producer.subcategory.toString());
route.setLimit(1);
route.query();
if (route.next())
current.assignment_group = route.u_assignment_group;
})(current, producer);How to test it
- 1Every active mapping routes correctly
- 2Inactive mapping is ignored
- 3Empty optional value does not break submission
- 4Unsupported combination reaches triage
- 5Created incident contains correct producer values
- 6User cannot manipulate a hidden group value
Common mistakes
- Hard-coding dozens of if-else conditions
- Using labels instead of backend values
- Trusting client-side assignment
- No fallback group
- No test for inactive mappings
Can you explain this solution under pressure?
Practice real scenarios covering this topic, architecture decisions, troubleshooting and security.
Explore more implementation guides or request the next topic.