Ctrl+K
Open Ops

TATER Ops — ITIL Process Profiles

Process Profiles let each task in TATER Ops follow an industry-standard shape — ITIL 4 Incident, ITIL Service Request, ITIL Problem, NIST SP 800-61 IR, or a custom workflow you author. A profile controls which fields appear on the task form, which status transitions are allowed, and what SLA targets apply.

Where to find them

Profiles live at Ops → Settings → Process Profiles (OrgAdmin+). When creating a new task, the Profile dropdown at the top of the form picks which profile applies.

What are Process Profiles?

A Process Profile is a reusable template that defines three things about a task:

  • Field rules — which fields are visible, which are required, what their default values are, and (for enum fields) a restricted choice list.
  • Status flow — the allowed lifecycle states and the legal transitions between them. The server rejects status changes that don't match the flow.
  • SLA defaults — first-response and resolution targets per priority. These auto-populate responseDueAt / resolutionDueAt on the task when no explicit SLA is attached.

Profiles are distinct from Templates (recurring scheduled tasks) and Workflows (parent + sequenced child tasks). A Profile is the shape; a Template is the schedule; a Workflow is the orchestration.

Why use them?

  • Cleaner forms. The Basic profile hides every ITIL ceremony field. The ITIL Incident profile turns on impact, urgency, business service, configuration items, and resolution code.
  • Enforced workflow. Closed tasks can't jump back to Open without an explicit unblock state. Incidents can't skip from New to Resolved without passing through Assigned + In Progress.
  • Automatic SLA targets. A Critical ITIL Incident automatically gets a 15-minute response target and a 4-hour resolution target. A Low Problem ticket gets 5 days / 60 days.
  • Standard alignment. Each profile carries a standardSource tag (ITIL 4, NIST SP 800-61, ISO 20000, custom). Auditors see which industry standard the workflow follows.

The 5 seeded profiles

Basic

Standard: Basic · For: quick to-dos with no ITIL ceremony.

Visible fieldsRequired
title, description, category, priority, assignedToEmail, dueDatetitle, category, priority

Status flow: Open → In Progress → Closed (or Cancelled). Closed can re-open back to Open if needed.

SLA defaults: High 8h/2d · Medium 1d/5d · Low 2d/10d.

ITIL Incident

Standard: ITIL 4 · For: service-disrupting events that need full incident-management ceremony.

Visible fieldsRequired
title, description, category, priority, impact, urgency, severity, source, assignedToEmail, assignmentGroup, requesterEmail, contactEmail, businessService, configurationItems, majorIncident, linkedTaterEntityType, linkedTaterEntityId, linkedProblemId, resolutionCode, resolutionNotes, rootCauseCode, rootCauseAnalysis, dueDate, responseDueAt, resolutionDueAt, slaId, slaName, visibility, externalRefs title, description, category, priority, impact, urgency, source, assignedToEmail

Status flow: New → Assigned → In Progress → (On Hold / Pending) → Resolved → Closed. Cancelled available from most states. Assigned stamps slaRespondedAt; Resolved stamps slaResolvedAt; Closed stamps closedAt.

SLA defaults: Critical 15m/4h · High 1h/8h · Medium 4h/1d · Low 1d/5d.

ITIL Service Request

Standard: ITIL 4 · For: predefined service requests (access provisioning, software install, password reset). Lighter than Incident — no severity / major-incident; emphasizes approval and fulfillment.

Visible fieldsRequired
title, description, category, priority, impact, urgency, source, assignedToEmail, assignmentGroup, requesterEmail, businessService, configurationItems, linkedTaterEntityType, linkedTaterEntityId, resolutionCode, resolutionNotes, dueDate, responseDueAt, resolutionDueAt, visibility title, category, priority, requesterEmail

Status flow: New → (Approval Pending → Rejected/Assigned) → In Progress → (On Hold) → Fulfilled → Closed. Defaults visibility to CustomerVisible.

SLA defaults: High 4h/1d · Medium 1d/3d · Low 2d/7d.

ITIL Problem

Standard: ITIL 4 · For: root-cause investigations linked to recurring or major incidents.

Visible fieldsRequired
title, description, category, priority, severity, source, assignedToEmail, assignmentGroup, businessService, configurationItems, linkedTaterEntityType, linkedTaterEntityId, rootCauseCode, rootCauseAnalysis, resolutionNotes, dueDate, visibility title, description, category, priority

Status flow: New → Assigned → Investigating → (Known Error) → Resolved → Closed. Long-lived workflow (no aggressive SLA).

SLA defaults: High 1d/14d · Medium 2d/30d · Low 5d/60d.

NIST SP 800-61 IR

Standard: NIST SP 800-61 Rev 2 · For: security incident response — preparation, detection, containment, eradication, recovery, post-incident review.

Visible fieldsRequired
title, description, category, priority, severity, source, visibility, assignedToEmail, assignmentGroup, configurationItems, majorIncident, linkedTaterEntityType, linkedTaterEntityId, rootCauseCode, rootCauseAnalysis, resolutionCode, resolutionNotes, dueDate, responseDueAt, resolutionDueAt, slaName title, description, category, priority, severity, source, visibility, assignedToEmail

Status flow: Detected → Triage → (False Positive) / Contained → Eradicating → Recovering → Resolved → Post-Incident Review → Closed.

SLA defaults: Critical 15m/8h · High 1h/1d · Medium 4h/3d · Low 1d/7d.

Seeding the defaults

Go to Settings → Process Profiles and click + Seed Defaults. The endpoint is idempotent and per-organization — running it again will skip any profile that already exists (with the org-scoped id profile-itil-incident-<orgId>, etc.), so your customizations to a previously seeded profile are not overwritten.

If you want a fresh copy of a seeded profile after you've heavily customized one, rename your customized version first and then re-run Seed Defaults.

Customizing a profile

From Settings → Process Profiles, click View / Edit on any profile. The current UI is a raw JSON editor. The structure mirrors the TaskerProfile type:

{
  "name": "ITIL Incident (Tier 1 Helpdesk)",
  "description": "Restricted to Tier 1 helpdesk — severity hidden, no root cause required.",
  "standardSource": "ITIL 4",
  "fieldRules": {
    "severity":          { "visible": false, "required": false },
    "rootCauseCode":     { "visible": false, "required": false },
    "rootCauseAnalysis": { "visible": false, "required": false },
    "priority":          { "visible": true,  "required": true, "default": "Medium" }
  },
  "statusFlow": [
    { "status": "New",         "allowedTransitions": ["Assigned", "Cancelled"], "isInitial": true },
    { "status": "Assigned",    "allowedTransitions": ["In Progress", "Cancelled"], "setSlaResponded": true },
    { "status": "In Progress", "allowedTransitions": ["Resolved", "On Hold"] },
    { "status": "On Hold",     "allowedTransitions": ["In Progress"] },
    { "status": "Resolved",    "allowedTransitions": ["Closed", "In Progress"], "setSlaResolved": true },
    { "status": "Closed",      "allowedTransitions": [], "isTerminal": true, "setClosedAt": true },
    { "status": "Cancelled",   "allowedTransitions": [], "isTerminal": true, "setClosedAt": true }
  ],
  "slaDefaults": [
    { "priority": "High",   "responseMinutes": 60,   "resolutionMinutes": 480 },
    { "priority": "Medium", "responseMinutes": 240,  "resolutionMinutes": 1440 },
    { "priority": "Low",    "responseMinutes": 1440, "resolutionMinutes": 7200 }
  ]
}

A visual builder is on the near-term roadmap. Until then, the JSON editor is fully supported — the server validates every save and rejects malformed profiles (must have exactly one isInitial state, all transitions must point at known statuses, etc.).

System-seeded profiles (with isSystem: true) can be edited but not deleted. To retire one, rename it to (unused) Foo and remove it from your task form by leaving the Profile dropdown blank.

Creating a custom profile

Click + Custom Profile in Settings → Process Profiles. Common reasons to create one:

  • HIPAA Breach Response — required PHI-scope field, 60-day notification clock, OCR report state.
  • FedRAMP Incident Reporting — US-CERT notification state, FedRAMP PMO field, severity required, 1-hour reporting SLA on Critical.
  • Internal company workflow — e.g. a Procurement Request with custom fields for cost center, budget code, and PO number, plus a 3-state approval chain (Submitted → Approved → Ordered).

Start by copying the closest seeded profile's JSON, modify name + standardSource + the rules, and save.

API reference

MethodEndpointRolePurpose
GET/api/tasker/profilesViewer+List all profiles for the org
GET/api/tasker/profiles/{id}Viewer+Single profile detail
POST/api/tasker/profilesAdminCreate or update by id
DELETE/api/tasker/profiles/{id}AdminSoft delete (refuses if isSystem)
POST/api/tasker/profiles/seed-defaultsAdminIdempotent seed of the 5 starter profiles

Tasks reference a profile via the profileId field. The server uses two helpers each time a task is written: validateStatusTransition() (rejects illegal status moves) and computeSlaTargets() (auto-fills response/resolution due dates when no explicit SLA is attached).

MCP integration

Process Profiles are available to AI agents via the same MCP tools used elsewhere in TATER Ops — list_tasker_tasks, create_tasker_task, and update_tasker_task all honor the profileId field. When an agent creates a task under a profile, the server enforces the same field-rule and status-flow validations it does for the UI. Field-visibility and SLA-default behavior happens automatically; the agent doesn't need to know the profile's internal shape.

This means a Claude or Copilot session walking a user through an incident response will get the same enforced workflow as a help-desk technician using the UI — including the requirement to pass through Triage and Containment states before reaching Resolved.

Cross-app roadmap

The TaskerProfile pattern (field rules + status flow + SLA defaults + standard source) generalizes cleanly to other TATER entities. On the near-term roadmap:

  • RiskProfile — NIST 800-37 vs ISO 27005 vs CIS RAM workflows for the Risk Register.
  • AuditProfile — SOC 2 Type 2 vs ISO 27001 vs FedRAMP audit checklists.
  • ChangeProfile — ITIL Change Enablement (Standard / Normal / Emergency) with the appropriate CAB approval flows.
  • VendorProfile — SIG vs VSA-Lite vs SOC 2 Bridge Letter due-diligence forms.

Each will surface the same Settings → Profiles management UI and the same JSON-editor experience. Customizations made to one entity's profiles will not affect any other.