3.1 Task Management & Process Apps
Key Takeaways
- The Task [task] table is the parent table; Incident, Problem, and Change extend it and inherit fields like number, state, priority, and assignment_group.
- Priority is derived automatically from Impact and Urgency through a Data Lookup definition, not typed directly by users.
- Work notes are internal and visible only to fulfillers; the Additional comments (customer-visible) field is what requesters see in the portal and notifications.
- Service Level Agreements (SLAs) are timed commitments attached to task records and are tracked through Task SLA records with stages such as In Progress, Breached, and Completed.
- Assignment can be manual, driven by Assignment Rules, or automated through flows; the Assigned to user must usually belong to the Assignment group.
Why Task Management Matters for the CSA Exam
The Configuring Applications for Collaboration domain is 20% of the ServiceNow Certified System Administrator (CSA) exam, and task-based applications are the foundation of almost everything an administrator configures. Incident, Problem, and Change Management are the canonical examples the exam draws from, so you must understand how they share structure and how records move from creation to closure.
The Task Table and Table Extension
ServiceNow uses an object-oriented data model. The Task [task] table is a base table that defines common fields every piece of work needs: number, short_description, state, priority, assignment_group, assigned_to, opened_by, and the audited journal fields work_notes and comments.
Application tables extend Task. An extended table inherits every parent field and adds its own. This is why an Incident record and a Change record both have a number and an assigned_to, even though they serve different processes.
| Table | Extends | Adds (examples) | Process |
|---|---|---|---|
| Incident [incident] | task | caller_id, subcategory, problem_id | Restore service fast |
| Problem [problem] | task | root_cause, workaround, known_error | Find and remove root cause |
| Change Request [change_request] | task | risk, type (Normal/Standard/Emergency), cab_required | Control change safely |
| Catalog Task [sc_task] | task | request_item | Fulfill a catalog item |
Because of extension, an Access Control List (ACL) or business rule written on task applies to every child table unless overridden — a frequently tested concept.
Priority, Impact, and Urgency
The exam expects you to know that Priority is calculated, not chosen. ServiceNow ships a Data Lookup definition that maps a combination of Impact (effect on the business) and Urgency (how soon it must be resolved) to a resulting Priority.
| Impact \ Urgency | High | Medium | Low |
|---|---|---|---|
| High | 1 - Critical | 2 - High | 3 - Moderate |
| Medium | 2 - High | 3 - Moderate | 4 - Low |
| Low | 3 - Moderate | 4 - Low | 5 - Planning |
An administrator changes this behavior by editing the Priority Lookup Rules, not by adding a client script to the Priority field.
State Flow
Each process table has a state choice field that drives its lifecycle. A typical Incident progresses New → In Progress → On Hold → Resolved → Closed. Change Requests follow an authorization path that may include Assess and Authorize states and a Change Advisory Board (CAB) review for Normal changes. States can be enforced with UI Policies (client-side) and Business Rules (server-side), both covered later in the guide.
Work Notes vs. Additional Comments
This distinction is one of the most reliably tested points in the collaboration domain.
| Field | Audience | Typical Use | Notification Behavior |
|---|---|---|---|
| Work notes | Internal fulfillers only | Technical investigation, private context | Notifies assignment group / watch list, not the caller by default |
| Additional comments (Customer visible) | Requester and fulfillers | Status updates the customer should see | Drives customer-facing email notifications and portal activity stream |
Both are journal fields: every entry is timestamped, attributed, and appended to the Activity stream — entries cannot be edited or deleted after posting, which preserves an audit trail.
Assignment
Work reaches the right person through three mechanisms:
- Manual — a fulfiller sets
assignment_groupthenassigned_to. - Assignment Rules — condition-based records that auto-populate the group/user when criteria match (for example, all Hardware-category incidents go to the Hardware group).
- Flow Designer / workflow automation — assigns work as part of a broader process.
A common configuration rule: the Assigned to field is usually filtered to users who are members of the selected Assignment group, which keeps accountability clear.
SLAs Overview
A Service Level Agreement (SLA) is a measurable commitment, such as "Priority 1 incidents resolved within 4 hours." An administrator defines an SLA Definition (table, start/stop/pause conditions, duration, and schedule). When a matching record is created, the platform attaches a Task SLA record that tracks elapsed time, percentage, and a stage such as In Progress, Breached, or Completed. SLA timers can pause during specific states (for example, On Hold) when the definition uses a pause condition.
Why do Incident, Problem, and Change Request records all contain a 'number' and 'assignment_group' field?
A technician adds a comment that the requester must NOT see while troubleshooting an incident. Which field should be used?
How is the Priority value on a standard ServiceNow Incident normally determined?
Which statements about Service Level Agreements (SLAs) in ServiceNow are correct? Select all that apply.
Select all that apply