---
sourceDocument: Australia Employee Service Management
sourceDocumentLink: https://www.servicenow.com/docs/r/employee-service-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Employee Service Management

ft:clusterId :

    - emplsm

bundleId :

    - emplsm

workflow :

    - Employee


---

# Universal Request data model

# Universal Request data model {#ariaid-title1}

* Release version: Australia
* 
* Updated March 12, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 4 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Universal Request data model

The Universal Request (UR) data model in ServiceNow Australia release supports cross-departmental collaboration and a unified employee experience by serving as a parent record for various departmental tickets such as IT incidents and HR cases.
It enables organizations to measure cross-departmental SLAs and OLAs effectively.
A UR is a task type that can be created by employees, agents, or system-generated processes and provides a consistent ticket view for requesters.
Show full answer Show less  

## Creation and Sources of Universal Requests

* **Requester-created:** Employees submit requests via Service Portal, Employee Center, mobile devices, or virtual agent chat.
* **Agent-created:** Service desk agents can create a UR from phone calls or live chats and assign it to appropriate Tier 1 groups.
* **System-generated:** URs can be automatically created from Record Producers configured for cross-departmental request transfer.

## Data Model and Key Fields

The UR data model extends the base **Task \[task\]** table with additional fields to support its functionality:

* **Universal Request field:** Links child tickets to their parent UR record, allowing any task extension to be a child of UR.
* **Effective Number field:** Stores either the UR number or the department-specific ticket number for proper identification.
* **Transfer Reason field:** Indicates why a ticket was transferred, with options for transfers with or without resolution.

The Universal Request table itself includes:

* State reasons for various customer-facing states (e.g., New, In Progress, Awaiting Response, Closed, Cancelled).
* Primary ticket details referencing the active department-specific ticket.
* A restricted field to mark sensitive requests, ensuring only authorized agents can view or resolve them.

## Functionality and User Access

Universal Request incorporates user roles and ACLs that allow organizations to control access for both internal and external users, enhancing security and compliance for sensitive tickets.

## Primary Ticket Field and Ticket Lifecycle

The **Primary Ticket** field in the UR table plays a central role in determining the UR state and the requester's ticket experience. Key points include:

* Each UR can have only one primary ticket at a time, typically a departmental ticket like an IT incident or HR case.
* When a UR is first created, it has no primary ticket; once a child ticket is created from the UR, it becomes the primary ticket.
* Transferring the primary ticket back to UR or to another department clears the primary ticket field, allowing new child tickets to be assigned as primary.
* Record Producers configured to auto-create URs establish the UR as the parent, with subsequent departmental tickets becoming the primary child tickets.  
Universal Request is a task type that supports cross-departmental
collaboration and unified employee experience. Universal Request becomes the
parent record for departmental primary tickets, such as IT incidents and HR cases, and enables
your organization to measure cross-departmental SLAs and OLAs.  
The Universal Request (UR) is a task that can be created from any of the following sources.

* Requester-created: An employee uses any of following options to submit a request.
  * Clicks Request Help on the Service Portal or Employee Center.
  * Taps Needs Help on a mobile device.
  * Uses the virtual agent chat on the portals.
  {#UR-datamodel__ul_o2h_zyd_14b}
* Agent created: An IT service desk agent receives a phone call or live chat from an employee, starts a new call record or an Interaction Record, and in some cases, can create a Universal Request instead of a department ticket. The agent can then assign that UR to an appropriate Tier 1 assignment group.
* System generated: Based on configuration, a universal request is created when an employee submits a Record Producer. The Record Producer is configured to automatically create a Universal Request to enable cross-departmental request transfer and a consistent ticket view for the requester.
{#UR-datamodel__ul_y1d_n5g_gmb}

The following diagram shows a high-level overview of the Universal Request data model.

The Universal Request data model uses a combination of tables to store data:

* ServiceNow AI Platform tables
* Tables included with Universal Request

{#UR-datamodel__ul_pky_k3m_3nb}For information, see the list of [Universal Request plugins](https://www.servicenow.com/docs/EG6dnaGA7V3POUZYAuUWww "Request and activate the following plugins to use Universal Request in your application.").  
The Task \[task\] table is modified to include the following fields:

* A Universal Request (UR) field points to the parent UR record. This model allows any table extending the Task table to be a child of the UR.
* Effective Number field (identifying number) stores the UR number, if the request has a UR associated with it. If it is not associated with a UR, then the Effective Number stores the current department-specific request number.
* Transfer Reason field stores the reason for the transfer of the request. The possible options are:

  With resolution
  :   Indicates that the request is completed and is transferred back to Universal Request, the specific department or service.

  Without resolution
  :   Indicates that the request is not completed and is transferred back to Universal Request, the specific department or service.
{#UR-datamodel__ul_xzm_4sg_llb}  
The Universal Request table includes:

* State reasons for the customer-facing states
* Primary ticket details of the department-specific requests
* Restricted field to indicate if the request created is sensitive or not
{#UR-datamodel__ul_xq3_3lm_3nb}

Universal Request also includes user roles and ACLs that customers can use to
provide access to different tables. This includes both internal and external user roles.  
The Universal Request is a new task type that is extended from the base Task \[task\] table and is uniquely identified by a number prefixed with UR.{#UR-datamodel__simpletable_bpc_mtg_llb__entry__2}

| Field | Description |
|-|-|
| Primary ticket | References the request that is currently active under the Universal Request. For example, INC1022201. |
| Opened for | The requester for whom the Universal Request is created. |
| State | Current state of the Universal Request. A UR can be in any of the following states: * New * In Progress * Awaiting Response from user * Closed * Cancelled {#UR-datamodel__ul_ghn_bnt_3mb} For more information on the UR states, see [Universal Request states and reasons](https://www.servicenow.com/docs/rUu~NYrRvvdQLeFpZp9Yng "The Universal Request (UR) state is determined by the state of the primary ticket. The primary ticket for a UR is a child department ticket, such as an IT incident or a HR case. A Universal Request can have only one primary ticket at a time."). |
| State reason | The agent-facing reason for some requester-facing states. The state reason values are as follows: Triaging: :   A possible state reason when a Universal Request state is In Progress, and indicates that the Universal Request is being triaged. Primary ticket: In Progress :   A possible state reason when a Universal Request state is In Progress, and indicates that the work for an active primary ticket is in progress. Confirm response: :   A possible state reason when a Universal Request state is In Progress, but the state reason changes to Confirm Response notifying the tier 1 agents to either accept or reject the response before closing the ticket for the requester. This happens when the Needs Review flag of the Universal Request is set to true. Accept Resolution: :   A possible state reason when a Universal Request is in Awaiting Response state indicating that there is a pending requester's action to accept the resolution provided. Action required: :   A possible state reason when a Universal Request is in Awaiting Response state that there is an additional action to be performed by the requester. |
| Restricted | Option for restricting access to a ticket that has sensitive data. If a ticket is marked as Restricted, then only the agents with the sensitive request access can view and resolve the ticket. |
[Table 1. Universal Request table]

{#UR-datamodel__simpletable_bpc_mtg_llb}

## Primary Ticket field of the Universal Request table {#UR-datamodel__section_mmr_nv2_hmb}

The Primary Ticket field in the Universal Request determines the UR state and the requester's ticket view experience. Use the Standard Ticket page configuration of the primary ticket to determine the content that must be displayed in various sections of a standard ticket page. The primary ticket for an UR is a departmental ticket such as an IT incident or an HR case.  
Note:  
A Universal Request can have only one primary ticket at a time.

For a Universal Request that is created for the first time, no primary tickets exist. If a
child department ticket, such as an IT incident or an HR case is created from the UR, then
the child ticket becomes the primary ticket. If the primary ticket is transferred back to UR
or to another department, then the primary ticket field becomes empty. This sequence
continues as new primary tickets are added and transferred back to UR or to another
department.

When a record producer is configured to automatically create a Universal Request, then the
UR becomes the parent record. And, when a department ticket is created, then that record
becomes the primary ticket and remains until it is transferred back to the UR, to another
department, or service.