Record producers let users submit incidents, problems, or custom table records directly through the service catalog interface without creating a RITM. You'll have a clean self-service form that inserts records straight into your target table with proper field mapping.
Why record producers exist instead of standard catalog items
Standard catalog items create Request Items (RITM) that someone has to fulfill manually or through automation. That's unnecessary overhead when users just need to report an incident or submit a problem record. Before record producers, admins either forced users through the full request process for simple record creation, or built custom UI pages that bypassed catalog benefits like entitlements and workflows. End users got frustrated with heavyweight processes for simple tasks, and IT teams maintained duplicate interfaces.
How record producers insert records directly
A record producer is a catalog item that writes directly to any table instead of creating sc_request records. You define which table receives the record, map catalog variables to table fields, and control where users land after submission. Start with basic variable-to-field mapping to get records flowing, then add client scripts for dynamic behavior and server scripts for complex field population. The key architectural difference: variable values become field values through direct mapping, not through fulfillment workflows.
Production improvements beyond basic field mapping
Once records are inserting correctly, add client scripts to show/hide variables based on user selections, implement proper entitlements so only the right people can access it, and configure email notifications to alert appropriate teams. Consider adding server-side scripting to populate fields that can't be mapped directly from variables. For high-volume scenarios, add proper indexing on fields users will search frequently, and implement business rules on the target table to handle downstream automation.
Before you start
- •catalog_admin or admin role
- •Write access to the target table
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Create the record producer
Navigate to Service Catalog > Catalog Definitions > Record Producers and click New. Fill in Name (what users see), Table (the table where records get inserted - typically incident, problem, or your custom table), and set Active to true. The Table field determines where your submitted records go - this is the critical difference from standard catalog items. Leave Template blank unless you're cloning an existing producer. Save the record.
Choose your table carefully - you can't change it after users start submitting records without breaking existing data relationships.
Add catalog variables
Click the Variables tab and add variables for each field users need to fill. Create variables with appropriate types - String for text fields, Reference for lookup fields, Multiple Choice for dropdowns. Name them descriptively since users will see these labels. Don't worry about mapping yet - focus on getting the user interface right. The variable types should match your target table field types to avoid conversion issues.
Use the same variable names as your target table field names when possible - it makes mapping obvious later.
Configure variable mapping
For each variable, open it and go to the Default Value tab. Set Map to field to true and select the target table field from the Field dropdown. This is how variable values become field values in your target table. Variables without field mapping will be stored but won't populate table fields. For reference fields, ensure both the variable type and target field are reference types pointing to the same table.
Test your mapping with a single variable first - submit a test record and verify the field populates correctly before mapping all variables.
Set the submission redirect
On the record producer form, find the Redirect to this page field and enter where users should go after submitting. Use '$target_table.do?sys_id=$target_sys_id' to send them to the record they just created, or a static URL like '/nav_to.do?uri=incident_list.do' for a list view. The $target_sys_id variable contains the sys_id of the newly created record. Save the record producer.
Add to service catalog
Navigate to Service Catalog > Catalogs and open the catalog where this should appear. Click the Catalog Items tab, then Edit. Move your record producer from Available to Selected using the slush bucket controls. Set the order value to control where it appears in the catalog. Click Save to make it available to users.
Test the complete flow in a non-admin browser session to see exactly what users will experience.
Configure entitlements and security
Return to your record producer and click the User Criteria tab. Add groups, roles, or users who should see this item. Without entitlements, everyone with catalog access can use it. Test access by impersonating a user in the target group. Also verify the target table's ACLs allow your users to create records - record producers respect table-level security.
Check both catalog entitlements and table ACLs - users need both catalog access and table write permissions.
Best practices
Always test the complete flow as a non-admin user - admin privileges can mask ACL and entitlement issues that will block real users.
Map variables to required fields on your target table or provide default values through scripting - unmapped required fields will cause silent submission failures.
Use reference variables sparingly and always set up dependent dropdowns properly - reference fields with thousands of options create terrible user experiences.
Don't put business logic in record producer scripts that should live on the target table - keep validation and automation with the data, not the entry point.
Set explicit redirect URLs rather than relying on defaults - users expect to see their submitted record or get clear confirmation of what happened.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue