Record Producer

What It Is

A Record Producer is a specialized type of Service Catalog item that creates records directly in any table instead of following the standard catalog flow that generates sc_req_item records. While the term "record producer" might suggest something generic in broader IT contexts, ServiceNow uses it specifically to describe this catalog mechanism that bypasses the traditional request-to-request-item workflow. Unlike standard catalog items that create request items which then fulfill through workflows or flows, Record Producers execute immediately upon submission and generate the target record with populated field values directly from the catalog variables.

Architecturally, Record Producers sit at the intersection of the Service Catalog layer and the core data model, functioning as a bridge that translates catalog variables into table field values. They enable organizations to leverage the catalog's user interface design, approval workflows, and access controls while writing directly to operational tables like incident, problem, change_request, or custom application tables. This architectural position makes them essential for organizations that want consistent intake processes across different record types without forcing everything through the request management process.

From a business function perspective, Record Producers solve the fundamental problem of intake standardization across ITSM processes. Organizations often struggle with users creating incidents through multiple channels—email, phone calls, direct form submission, or walk-ups—resulting in inconsistent data quality and missed required information. Record Producers provide a controlled, catalog-style intake that can enforce required fields, apply business logic through scripts, and ensure proper categorization while still creating the incident, problem, or change record that operational teams expect to work with. This eliminates the overhead of request item management for processes that don't actually need request tracking and approval complexity.

ServiceNow designed Record Producers to address a specific gap in the original Service Catalog architecture. Early versions of the platform forced all catalog submissions through request items, which created unnecessary overhead when the business process didn't actually require request tracking—like incident reporting or simple change requests that needed immediate creation. The alternative would have been building separate intake forms for every process, losing the catalog's unified user experience, variable management, and approval capabilities. ServiceNow's solution maintains catalog benefits while allowing direct record creation, though this creates the complexity of managing two different catalog item behaviors within the same interface.

End users interact with Record Producers identically to standard catalog items—they see the same variable forms, categories, and submission process. However, their experience differs in that they receive immediate record creation rather than a request item they need to track through fulfillment. Catalog administrators configure Record Producers differently because they must map variables directly to target table fields and handle business logic in the producer script rather than relying on fulfillment workflows. Developers working with Record Producers focus on the producer script field and field mapping rather than workflow design. Process owners need to understand that Record Producer submissions bypass many of the tracking and reporting mechanisms built around request items, requiring different approaches to metrics and process improvement.

Without Record Producers, organizations would face an impossible choice: either force all intake through request items (creating process overhead where it doesn't belong), or build separate intake mechanisms for each record type (losing catalog consistency and capabilities). Critical business processes like incident reporting would either carry the weight of request management overhead or exist outside the catalog ecosystem entirely. The unified catalog interface would fragment into process-specific forms, eliminating the single-pane-of-glass experience that drives user adoption and administrative efficiency.

Where It Fits in the Platform

Record Producers exist within the Service Catalog framework but operate at the data layer boundary, making them fundamentally different from other catalog items that work within the request management ecosystem. They inherit all catalog capabilities—variables, variable sets, client scripts, catalog UI policies, ACLs, and approval workflows—but execute their core function through direct database operations rather than workflow-driven fulfillment. This positioning makes them a hybrid concept that bridges user interface design patterns with direct record manipulation.

The Record Producer's relationship with ServiceNow's broader architecture creates both opportunities and constraints. They can leverage the full power of the catalog interface and variable system while connecting directly to any table in the platform, but they bypass the request management reporting and tracking infrastructure. This means Record Producers participate in catalog analytics and user experience management while remaining outside traditional ITSM process metrics that depend on request item lifecycle tracking.

Key Relationships:

• Service Catalog: Record Producers are a specialized type of catalog item that appears in the same catalog structure but executes differently. They share the catalog's user interface, approval processes, and access control mechanisms.
• Variables and Variable Sets: Record Producers use the same variable system as standard catalog items but map variable values directly to target table fields rather than storing them as request item variables.
• Request Items (RITM): Record Producers specifically avoid creating request items, making them the alternative choice when you want catalog-style intake without request management overhead.
• ITSM Tables (Incident, Problem, Change): Record Producers commonly target these operational tables, providing structured intake for core ITSM processes while maintaining the catalog user experience.
• Business Rules and Script Includes: The producer script executes server-side and can call any platform API, making Record Producers integration points for complex business logic and external system connections.
• Approval Workflows: Record Producers can use catalog approval processes, but approvals apply to record creation rather than request fulfillment, creating different approval timing and context.

How You Encounter This in Practice

The Incident Reporting Dilemma

You're a ServiceNow administrator tasked with improving incident reporting consistency across a 5,000-person organization. Users currently create incidents through phone calls, emails, and direct form submissions, resulting in missing required fields and inconsistent categorization. Management wants the structured intake and user experience benefits of the Service Catalog, but the ITSM team refuses to manage incident creation through request items because it adds unnecessary tracking overhead to operational processes. Understanding Record Producers unlocks the solution: you can provide catalog-style intake with required field validation, dynamic forms, and approval capabilities while creating incident records directly that integrate seamlessly with existing ITSM workflows. Without this knowledge, you'd likely try to force incident creation through standard catalog items, creating request management overhead that operational teams will reject, or build separate incident forms that duplicate catalog functionality and fragment the user experience.

The Custom Application Integration Challenge

You're a ServiceNow developer building intake forms for a custom employee onboarding application that needs to create records in multiple custom tables while maintaining approval workflows and variable validation. The business users expect the same polished interface they see in the Service Catalog, but your custom tables don't fit the request-to-fulfillment model that drives standard catalog items. Record Producers become essential because they let you leverage the entire catalog infrastructure—variables, approvals, ACLs, UI policies—while writing directly to your custom tables through the producer script. This understanding prevents the common mistake of trying to build custom intake forms from scratch or forcing business processes through request item fulfillment when direct record creation serves the actual need. Developers without this knowledge often spend weeks building custom forms that duplicate catalog capabilities or create overly complex workflows that transform request items into the records they actually needed to create directly.

The Catalog Analytics Gap

You're a service management analyst trying to understand why your catalog metrics don't align with operational process metrics, discovering that incident, problem, and change volumes from Record Producers don't appear in standard request fulfillment reports. Users submit hundreds of items monthly through catalog Record Producers, but these submissions bypass the sc_req_item table that drives most catalog analytics. Understanding Record Producers reveals why you need separate reporting approaches: catalog submission analytics from the sc_cat_item_producer table combined with operational metrics from target tables like incident or problem. Without this understanding, analysts often conclude that catalog adoption is lower than reality or miss significant process volumes in their operational reporting.

What People Get Wrong

This misconception leads administrators to expect Record Producers to behave identically to standard catalog items, particularly around fulfillment tracking and approval timing. Record Producers execute their core function—record creation—during the submission process rather than through post-submission fulfillment workflows. This fundamental difference affects approval timing because approvals happen before record creation, not during fulfillment. It also means Record Producers don't generate request items for tracking, eliminating the standard catalog fulfillment lifecycle that many administrators expect.

This misunderstanding exists because Record Producers share the same user interface, variable system, and configuration screens as standard catalog items, making their different execution model non-obvious until you encounter the behavioral differences. Administrators often discover this during implementation when they expect to see request items for tracking or when approval workflows don't behave as anticipated. The confusion intensifies because ServiceNow's catalog documentation often treats Record Producers as a minor variant rather than explaining their fundamentally different architectural approach.

In production, this misconception causes significant issues when administrators build reporting and process monitoring around request item tracking that Record Producers bypass entirely. Organizations lose visibility into catalog-driven process volumes and can't correlate user submissions with operational outcomes. More critically, approval processes may be configured incorrectly, with administrators expecting post-submission approvals that never occur because Record Producers execute immediately upon approval. This leads to scenarios where sensitive record creation processes lack proper approval controls or where business logic that depends on request item states fails completely.

The operational impact extends to change management and process improvement efforts that rely on request fulfillment metrics to understand catalog effectiveness. Teams lose the ability to track time-to-fulfillment, approval bottlenecks, and fulfillment success rates for Record Producer submissions because these metrics depend on the request item lifecycle. This forces organizations to build separate monitoring approaches or accept reduced visibility into catalog-driven processes.

Record Producers create records through direct database operations, which means they trigger all business rules, data policies, and validation logic associated with the target table. Unlike request items that exist in a controlled environment with predictable field structures, target tables often have complex mandatory field requirements, business rule dependencies, and integration triggers that must be satisfied for successful record creation. Administrators who simply point a Record Producer at a different table without understanding these requirements often discover that submissions fail silently or create invalid records that cause downstream process failures.

This misconception develops because ServiceNow makes changing the table reference appear simple through the Record Producer configuration form, without surfacing the complexity of target table requirements. Many administrators approach Record Producers with a catalog mindset, focusing on user experience and variable design while underestimating the database-level implications of record creation. The problem compounds when working with ITSM tables like change_request or problem that have extensive business logic, workflow dependencies, and integration points that expect specific field combinations and values.

In production environments, this misunderstanding leads to Record Producers that appear to work during testing but fail when encountering real data complexity or integration scenarios. Users experience cryptic error messages or submission failures that administrators struggle to diagnose because the failure occurs deep in business rule execution rather than at the catalog layer. More dangerously, Record Producers may successfully create records that violate business logic or data integrity requirements, causing process breakdowns that appear days or weeks later when operational teams discover incomplete or invalid records in their workflows. Integration failures are particularly problematic because Record Producers may create records that trigger external system updates with incomplete or incorrect data, requiring manual cleanup and potentially damaging external system relationships.

Admin vs Developer Perspective

For Admins

Admins control which tables Record Producers can write to through the sc_cat_item_producer table configuration and ACL permissions on target tables. They decide whether Record Producers create records directly or go through approval workflows, which affects how quickly records appear in target tables. Admins must understand that Record Producers bypass normal form submission logic for the target table, meaning any UI policies or client scripts on the target table won't run during record creation. The key maintenance decision is whether to grant the catalog user elevated permissions to create records in business tables, which can create security gaps if not properly scoped.

For Developers

Developers script Record Producers using the standard catalog script APIs, but the producer parameter in the script gives access to the actual target record being created rather than an sc_req_item. The scripting pattern involves using current to reference the request item and producer to manipulate the target record directly. Developers must handle the timing carefully because the target record creation happens after the catalog script runs, so you can't query for the target record immediately. The GlideRecord operations in Record Producer scripts run in the security context of the submitting user, which requires different error handling than typical server-side scripts.

How It Connects to Other Concepts

• Service Catalog — Record Producers appear in catalogs alongside regular Catalog Items but follow different fulfillment patterns. While Catalog Items create sc_req_item records that require separate processing, Record Producers create the final business record directly from the catalog submission.
• Business Rules — Business Rules on the target table fire when Record Producers create records, but the timing is different from normal form submissions. The record creation happens in a background process after the catalog request completes, so Business Rules run without the original user's session context.
• Workflows — Record Producers can trigger workflows in two places: on the sc_req_item for approval processes, and on the target table for business logic. The workflow on the request item controls whether the target record gets created at all, while workflows on the target table handle post-creation processing.
• Access Control Lists (ACLs) — Record Producers must navigate ACLs on both the catalog side and the target table side. The user needs read access to the catalog item and the system needs create access to the target table, often requiring elevated permissions for the catalog processing user.
• Variable Sets — Record Producers use Variable Sets to map catalog questions to target table fields, but the mapping happens through script rather than the automatic field mapping available in some other catalog item types. This gives more control but requires explicit coding to transfer variable values to the target record.
• Assignment Rules — When Record Producers create tickets in tables like incident or sc_request, assignment rules run against the created record just like normal ticket creation. However, the assignment happens asynchronously after catalog submission, so users don't see immediate assignment feedback.

Junior vs Senior Knowledge Gap

Juniors typically treat Record Producers as just another catalog item type and get confused when target table field validation fails after catalog submission appears successful. They don't realize that Record Producers create two separate records with different lifecycles, so debugging requires looking at both the sc_req_item and the target record. Junior developers often write Record Producer scripts that assume immediate target record creation, leading to race conditions when they try to query for records that don't exist yet. They also commonly grant overly broad permissions to make Record Producers work, not understanding the security implications of catalog-driven record creation.

The mental model shift happens when someone realizes that Record Producers are essentially a UI layer over programmatic record creation, not a different type of form submission. This understanding changes how you approach field mapping, validation, and error handling. Instead of thinking about form fields that map directly to table fields, you start thinking about variables that feed into scripts that create records. This shift makes it obvious why client scripts and UI policies from the target table don't affect the catalog form, and why server-side validation on the target table can cause cryptic failures.

Senior professionals know that Record Producers bypass nearly all the normal table interaction patterns, which makes them powerful but dangerous. They understand that the catalog user context for record creation can mask permission issues until you test with real users, and that target table Business Rules might fail silently if they depend on session variables. Experienced architects also recognize that Record Producers work best for simple record creation patterns and become problematic when you need complex field interdependencies or real-time validation feedback. They know to question any requirement that needs immediate target record access or complex error handling from the target table back to the catalog form.

The experienced architect asks about error handling strategies early in Record Producer design, because the asynchronous record creation makes it difficult to surface meaningful errors to users. They want to know how mandatory fields on the target table will be handled, whether the target table has complex Business Rules that might fail, and how the organization wants to handle partial failures where the request item exists but target record creation failed. These questions never come up in basic ServiceNow training but determine whether a Record Producer implementation will be maintainable long-term.

Quick Reference

• The sc_cat_item_producer table stores the target table name in the table_name field, and this cannot be changed dynamically based on catalog variables or user input.
• Record Producers create the target record using the catalog user account by default, so ACLs on target tables must account for this elevated permissions context.
• Target record creation happens after catalog workflows complete, so approved Record Producers create their target records asynchronously from a scheduled job.
• The producer script parameter contains a GlideRecord object for the target record, but calling update() on it is unnecessary because ServiceNow automatically saves it after script execution.
• Client scripts and UI policies from the target table form do not run during Record Producer submissions because the user never interacts with the target table form directly.
• Record Producer failures in target record creation don't automatically roll back the sc_req_item, leading to orphaned request items with no corresponding target records.
• The produced_record field on sc_req_item stores the sys_id of the created target record but isn't populated until after the target record is successfully created.
• Variable values from Record Producer submissions get stored in sc_item_option_mtom like other catalog items, making them available for reporting and historical reference even after target record creation.
• Record Producers cannot create multiple records in different tables from a single submission - each Record Producer maps to exactly one target table defined at configuration time.
• Business Rules on the target table receive the gs.getSession().getClientData() from the catalog session, allowing limited access to the original submission context.