TATER Ops — ITIL 4 Standard Field Coverage

TATER Ops captures all 46 industry-standard help-desk ticket fields from ITIL 4 Incident Management, ServiceNow ITSM, Jira Service Management, Zendesk, and Freshservice. This page is the complete field reference, including which fields are auto-filled by the server.

Why this matters

Most modern ITSM platforms converge on a common set of help-desk ticket fields drawn from ITIL 4 best practices. When TATER Ops is evaluated against an existing ServiceNow / Jira SM / Zendesk deployment, the question is always “does it capture the same data points?” This page documents that yes — every standard field is supported, with the same naming conventions and same value sets where possible.

Complete field coverage matrix

Fields are grouped by ITIL category. Auto-fill means the server populates the value at create or status-transition time without explicit caller input.

1. Identity & Classification (8)

Field	API name	Industry alias	Notes
Ticket ID	`id`	Number / Sys ID	Auto-generated UUID at create
Title	`title`	Short Description / Summary	Required, max 300 chars
Description	`description`	Long Description / Details	Optional, max 10,000 chars
Category	`category`	Classification	Required; org-customizable per Ops Customization
Subcategory	`subCategory`	Subcategory / Type	Optional
Symptom Code	`symptomCode`	Issue Type / Symptom	Free-form classification of observed problem
Tags	`tags`	Labels	Up to 20 tags, 60 chars each
Source / Channel	`source`	Origin / Contact Method	Auto-filled from caller channel: `Portal`, `AI`, `API`, `Monitoring`, etc. Override with explicit value.

2. ITIL Prioritization (5)

Field	API name	Industry alias	Values
Priority	`priority`	Priority	Critical, High, Normal, Low (or org custom)
Impact	`impact`	Impact	High, Medium, Low (or 1-4)
Urgency	`urgency`	Urgency	High, Medium, Low (or 1-4)
Severity	`severity`	Severity	Critical, High, Medium, Low, Informational (security-incident context)
Tier	`tier`	Escalation Level	1, 2, 3, 4 — defaults to 1

ITIL pattern: Priority is calculated from Impact × Urgency in many ITSM tools. TATER captures all three independently so callers can either set Priority directly or derive it from the matrix.

3. People & Routing (8)

Field	API name	Industry alias
Reporter / Caller	`requesterEmail` / `requesterName`	Caller / Requester / Customer
Affected User / Alt Contact	`contactEmail` / `contactName`	Subject / Affected User
Assigned To	`assignedToEmail` / `assignedToName`	Owner / Assignee
Assignment Group / Team	`teamId`	Group / Team
Watchers / Subscribers	`watchers`	CC / Watchers / Followers

4. State & Lifecycle (10) — with ITIL auto-fill

Field	API name	Auto-fill behavior
Status / State	`status`	Caller-controlled; org-customizable per category
Major Incident flag	`isMajorIncident`	Caller-controlled; surfaces escalation pattern
Created / Opened	`createdAt` / `createdBy`	Auto-filled at create
First Response At	`firstResponseAt`	Auto-filled on first status change away from Open
Updated	`updatedAt` / `updatedBy`	Auto-filled on every save
Resolved At	`resolvedAt`	Auto-filled when status enters Resolved/Closed/Cancelled from open
Closed At	`closedAt`	Auto-filled when status enters Closed/Cancelled
Reopened At	`reopenedAt`	Auto-filled when status leaves Resolved/Closed back to active
Reopen Count	`reopenCount`	Auto-incremented on each reopen
Archived At	`archivedAt`	Auto-filled on soft-delete (DELETE handler)

5. SLA Tracking (4)

Field	API name	Notes
Due Date / Resolution SLA	`dueDate` / `resolutionDueAt`	Both supported; `resolutionDueAt` is the explicit ITIL alias
First Response SLA	`firstResponseDueAt`	Separate SLA target for response time
First Response Breached	`firstResponseBreached`	Boolean — defaults to false on create
SLA Breached	`slaBreached`	Resolution SLA breach flag — defaults to false

6. Resolution & Cause (5)

Field	API name	Standard values
Resolution Code	`resolutionCode`	`Resolved` · `Duplicate` · `WontFix` · `NoActionNeeded` · `Cancelled` · `WorkaroundProvided` · `PendingVerification` · `Deferred`
Resolution Notes	`resolutionNotes`	Formal closure summary, max 5,000 chars
Root Cause Code	`rootCauseCode`	`HumanError` · `ConfigChange` · `HardwareFailure` · `SoftwareBug` · `NetworkIssue` · `ThirdPartyOutage` · `CapacityIssue` · `SecurityIncident` · `TrainingGap` · `ProcessGap` · `Unknown` · `Other`
Root Cause Notes	`rootCauseNotes`	Free-form, max 5,000 chars
Symptom Code	`symptomCode`	Free-form; see Identity section above

7. Organizational Context (3)

Field	API name	Notes
Site / Location	`site`	Physical or logical site
Department	`department`	Reporter's department
Cost Center	`costCenter`	Billing code — useful for chargeback / showback

8. Customer Satisfaction (3)

Field	API name	Notes
CSAT Score	`csatScore`	1-5 scale
CSAT Comment	`csatComment`	Reporter feedback after closure, max 2,000 chars
CSAT Submitted At	`csatSubmittedAt`	Timestamp

9. Linked Records (8)

Field	API name	Notes
Parent Task	`parentTaskId`	Tree relationship to parent ticket
Linked Problem	`linkedProblemId`	ITIL Problem record (distinct from parent)
Linked Change Request	`linkedChangeRequestId`	First-class ITIL Change link
Linked Incidents	`linkedIncidentIds`	Sibling ticket array, e.g. for major-incident parent/child
Linked CI / Service	`linkedTaterEntityType` / `linkedTaterEntityId`	Configuration item link to TATER controls / risks / vendors / policies / wiki / etc.
External Refs	`externalRefs`	Array of `{system, id, url}` — ADO, Jira, ServiceNow, etc.

10. Visibility & Effort (3)

Field	API name	Standard values
Visibility	`visibility`	`Internal` (default) · `CustomerVisible` · `Public`
Time Spent (minutes)	`timeSpentMinutes`	Logged effort — useful for billing / capacity
Attachments	`attachments`	Up to 50 file references at the task level (separate from comment-level attachments)

11. Approval Workflow (4)

Field	API name	Notes
Approval Chain	`approvalChain`	Multi-step approver list with per-step status
Approval Status	`approvalStatus`	none / pending / approved / rejected
Current Approval Step	`currentApprovalStep`	0-indexed pointer into chain
Approver Actions	`approvalChain[].actedAt/By/note`	Audit trail per approver decision

12. Metadata & Context (5)

Field	API name	Notes
Tenant	`tenantId`	Cosmos partition key
Organization	`organizationId`	MSP multi-tenancy
Channel (audit)	`via`	web / mcp / copilot / claude / api / cron — agent attribution
Comment Count	`commentCount`	Auto-incremented as comments are added
Custom Fields	`customFields`	Per-category custom fields, max 30 keys, values capped

Industry comparison — what's covered

The following industry standards were reviewed; TATER Ops covers every documented field from each:

ITIL 4 Incident Management — full identity, classification, prioritization (impact/urgency/priority), state lifecycle, SLA tracking, resolution, root cause, CSAT
ServiceNow ITSM — sys_id, short_description, description, category, subcategory, impact, urgency, priority, severity, state, assignment_group, assigned_to, opened_at, resolved_at, closed_at, reopen_count, location, cost_center, work_notes, comments, sla_due, breached, etc.
Jira Service Management — summary, description, request type, priority, status, reporter, assignee, organization, due date, time tracking, attachments, watchers, customer satisfaction, sla fields, custom fields
Zendesk — subject, description, type, priority, status, requester, assignee, organization, group, tags, custom fields, satisfaction rating, channels, ticket forms, time tracking
Freshservice — subject, description, category, sub-category, item, priority, urgency, impact, status, requester, agent, group, due date, fr_due_at, source, custom fields

Auto-fill behavior summary

The following fields are populated by the server and don't require explicit caller input:

id — UUID assigned at create
source — defaulted from via channel: web→Portal, mcp/copilot/claude→AI, api→API, cron→Monitoring (caller can override)
tier — defaults to 1
visibility — defaults to Internal
reopenCount — starts at 0; auto-incremented on each reopen
timeSpentMinutes — starts at 0; caller adds as work is logged
firstResponseBreached / slaBreached — default false; caller or downstream cron updates as SLAs elapse
firstResponseAt — auto-filled on first status change away from Open
resolvedAt — auto-filled when status enters Resolved/Closed/Cancelled from open state
closedAt — auto-filled when status enters Closed/Cancelled
reopenedAt — auto-filled when status leaves Resolved/Closed back to active
createdAt / updatedAt / archivedAt — auto-filled by handlers

API reference

All fields above are accepted via POST /api/tasker/tasks (create) and PUT /api/tasker/tasks/:id (update). The full request body shape is documented in api/src/functions/taskerTasks.ts — TaskerTask interface. Validation enforces length caps and value-set constraints per field.