ua_task Table — ServiceNow Reference

Table Reference/ua_task

The ua_task table stores HR Service Delivery (HRSD) case records and extends the task table with HR-specific fields. Owned by the HRSD module, it's the primary table for employee HR requests, issues, and services. The key thing to know: it inherits all task behaviors but adds HR-specific workflows and field validations that can affect your scripts.

What This Table Is

The ua_task table is the backbone of ServiceNow's HR Service Delivery (HRSD) module, storing all HR case records that employees create for HR-related requests, issues, and services. This includes everything from benefits inquiries and time-off requests to payroll questions and workplace accommodation requests. Each record represents a single HR interaction that needs tracking, assignment, and resolution through the HR department.

The table extends task, inheriting all standard task fields and behaviors while adding HR-specific fields like hr_service, employee, and hr_profile. The HRSD module owns this table and uses it to support the complete HR case lifecycle from initial employee request through HR agent assignment, investigation, and resolution. Unlike standard task records, HR cases often trigger complex workflows involving multiple HR systems and require specialized security controls for sensitive employee data.

Several tables extend ua_task for specific HR service types, including time-off requests (ua_time_off_request), benefits enrollments, and document requests. This creates a hierarchy where general HR cases use ua_task directly, while specialized requests use child tables with additional fields. The table integrations heavily with hr_profile and sys_user to maintain employee context throughout the case lifecycle.

Large enterprises typically see 50,000-200,000+ HR cases annually, making query performance critical. The table includes specialized indexes for employee and hr_service fields, but queries combining multiple reference fields can still be expensive. Record retention policies vary widely - some organizations purge closed cases after 7 years for compliance, while others maintain indefinite history for trend analysis and regulatory requirements.

When You'll Script Against This Table

You'll most commonly script against ua_task in Business Rules that automate HR case workflows - auto-assigning cases based on HR service type, sending notifications to managers for certain request types, or integrating with external HR systems when cases reach specific states. Transform Maps also frequently target this table when importing case data from legacy HR systems or external portals. Script Includes commonly query this table for HR dashboard data, SLA calculations, and custom HR reporting that spans multiple case types.

Access to ua_task is controlled by the sn_hr_core.hr_admin and sn_hr_core.hr_agent roles for full access, with employee self-service limited to their own records through record-level ACLs. Scripts running in the global scope have full table access, but scoped applications need explicit role grants or elevated privileges to read/write HR case data due to the sensitive nature of employee information.

Common scripting patterns:

Auto-assigning cases to HR teams based on hr_service category and employee location
Calculating SLA targets based on case urgency and HR service level agreements
Synchronizing case data with external HRIS systems when cases transition to specific states
Generating custom notifications to employee managers for approval-required requests
Building HR metrics dashboards that aggregate case volumes by service type and resolution time
Creating audit trails for sensitive HR cases that require compliance documentation
Implementing escalation rules for overdue cases based on employee hierarchy and case priority

Table Gotchas

⚠️

The employee field is NOT the same as opened_by. Employee represents who the case is about, while opened_by is who created the case. HR agents often create cases on behalf of employees, making this distinction critical for proper case routing and permissions.

⚠️

State field behavior differs from standard task states. HR cases use custom state values like 'Pending Employee', 'Pending Approval', and 'Information Needed' that don't map to standard task workflow states. Always check the choice list values rather than assuming standard task states apply.

The hr_profile reference can be null for terminated employees, causing reference field queries to miss historical cases unless you account for this
Queries filtering by employee.department are expensive - use hr_profile.department instead as it's indexed specifically for HR queries

⚠️

Record-level security is aggressive on this table. Even with table read rights, you may only see cases where you're the employee, opener, or assigned agent. Test your queries with different user contexts to ensure they return expected results.

The hr_service field uses a complex reference qualifier that filters based on employee location and department - direct assignment may fail validation
Business Rules on task will fire for HR cases too - use table conditions carefully to avoid unintended side effects on HR workflows

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The parent task table provides all the foundational workflow fields like state, assigned_to, and assignment_group, along with the complete task SLA and approval frameworks. The hr_profile table is the most critical relationship, containing comprehensive employee data including department, location, manager hierarchy, and employment status. Most HR case business logic queries both tables together to access complete employee context for routing and approval decisions.

The hr_service_catalog table defines available HR services and their configuration, while sys_user provides basic user information for both employees and HR agents. The sys_user_group table is frequently joined for assignment group routing, especially when cases need to route to location-specific HR teams. The task_sla table tracks HR case SLA performance, which is critical for HR service level reporting and escalation workflows.

Child tables like ua_time_off_request extend ua_task for specialized HR request types, requiring developers to understand the table hierarchy when building comprehensive HR reports. The sys_attachment table is also commonly referenced since many HR cases require document uploads for processing requests like benefits enrollment or policy exception requests.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
number	string	Number	Auto-generated unique case identifier with HR prefix (e.g., HRC0001234). Uses a separate number series from other task types.
employee	reference	Employee	References sys_user - the employee the case is about (not necessarily who opened it). Can differ from opened_by when HR agents create cases.
hr_profile	reference	HR Profile	References hr_profile table for comprehensive employee data. Can be null for terminated employees, breaking reference field queries.
hr_service	reference	HR Service	References hr_service_catalog. Has complex reference qualifiers based on employee location/department that can cause direct assignment failures.
state	integer	State	Uses custom HR-specific state values like 'Pending Employee' and 'Pending Approval' that don't map to standard task states.
priority	integer	Priority	Inherits from task but HR cases use different priority calculation logic based on service type and employee level.
urgency	integer	Urgency	Drives SLA calculations specific to HR service levels. Auto-calculated based on employee VIP status and request type.
impact	integer	Impact	Determined by employee role and department for HR-specific impact assessment, not standard IT impact rules.
assigned_to	reference	Assigned to	References sys_user for the assigned HR agent. Auto-assignment rules consider HR service type and employee location.
assignment_group	reference	Assignment group	References sys_user_group for HR teams. Often location-specific groups like 'HR - New York' or service-specific like 'HR - Benefits'.
opened_by	reference	Opened by	References sys_user - who created the case. Can be the employee themselves or an HR agent acting on their behalf.
short_description	string	Short description	Brief case summary. Often auto-populated based on hr_service selection through catalog item templates.
description	string	Description	Detailed case description. May contain sensitive employee information subject to field-level encryption in some implementations.
work_notes	journal_input	Work notes	Internal HR agent notes not visible to employees. Critical for case documentation and handoffs between HR teams.
comments	journal_input	Additional comments	Customer-visible communication log. Employees can see these comments when checking case status through ESS portal.
due_date	glide_date_time	Due date	Target resolution date calculated from HR SLA definitions. Critical for HR service level compliance reporting.
resolved_at	glide_date_time	Resolved	Timestamp when case reached resolved state. Used for HR SLA compliance calculations and resolution time metrics.
closed_at	glide_date_time	Closed	Final case closure timestamp. HR cases often have a waiting period between resolved and closed for employee confirmation.
business_service	reference	Business service	References cmdb_ci_service for HR service mapping. Used for service catalog integration and HR service portfolio management.
contact_type	string	Contact type	How the employee contacted HR (phone, email, walk-in, portal). Important for channel analytics and resource planning.

Common Queries

Get all active HR cases

// Most basic query - active cases only
var gr = new GlideRecord('ua_task');
gr.addQuery('active', true);
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    gs.print(gr.number + ': ' + gr.short_description);
    // Process active HR cases
    // Note: 'active' field inherited from task table
}

Find cases by state and assignment group

// Cases pending in specific HR team
var gr = new GlideRecord('ua_task');
gr.addQuery('state', '2'); // Assuming '2' is 'In Progress'
gr.addQuery('assignment_group.name', 'HR - Benefits');
gr.addNotNullQuery('employee'); // Ensure employee reference exists
gr.query();

while (gr.next()) {
    // Get employee details for notification
    gs.print('Case: ' + gr.number + ' for ' + gr.employee.name);
}

Get cases for specific employee with HR profile data

// Real-world scenario: find all cases for employee including terminated
var gr = new GlideRecord('ua_task');
gr.addQuery('employee.user_name', 'john.doe');
gr.addQuery('sys_created_on', '>=', 'javascript:gs.daysAgoStart(90)');
gr.orderByDesc('sys_created_on');
gr.query();

while (gr.next()) {
    // Handle cases where hr_profile might be null
    var dept = gr.hr_profile.isValidRecord() ? gr.hr_profile.department : 'Unknown';
    gs.print(gr.number + ' - Dept: ' + dept + ' State: ' + gr.state.getDisplayValue());
}

Count cases by HR service type using GlideAggregate

// HR metrics - case volume by service type
var ga = new GlideAggregate('ua_task');
ga.addQuery('sys_created_on', '>=', 'javascript:gs.monthsAgoStart(1)');
ga.addNotNullQuery('hr_service');
ga.groupBy('hr_service');
ga.addAggregate('COUNT');
ga.query();

while (ga.next()) {
    var service = ga.getValue('hr_service');
    var count = ga.getAggregate('COUNT');
    gs.print('Service: ' + ga.hr_service.getDisplayValue() + ' - Count: ' + count);
}

Gotcha query - wrong way vs right way for department filtering

// WRONG: Expensive query through employee reference
// var gr = new GlideRecord('ua_task');
// gr.addQuery('employee.department', 'IT'); // Slow, not indexed

// RIGHT: Use hr_profile reference instead
var gr = new GlideRecord('ua_task');
gr.addQuery('hr_profile.department.name', 'Information Technology');
gr.addQuery('active', true);
gr.query();
// This uses HR-optimized indexes and handles null hr_profile gracefully

while (gr.next()) {
    gs.print('Efficient query: ' + gr.number);
}

Related Tables

task sys_user sys_user_group task_sla

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue