Skip to tutorial content
Rate module Not yet rated

Incident Architecture: Tables and Key Fields

4 min read
On this page

In this lesson, you will learn:

  • How the incident table is built
  • What it gets from the Task table
  • The key fields SNWR will configure
  • Which fields feed routing, SLAs and reports

🔁 Quick look back: Last time: How Employees Ask for Help: Channels. You learned the channels employees use to ask for help, and which record each channel creates.

1 “Which field do we change?”

In the first build sprint, Daniel asks for three things.

  • “Show which office is affected.”
  • “Make urgent things jump the queue.”
  • “Tell us which service broke.”

🎯 The problem: If you don’t know which fields already exist, you might build new ones you don’t need.

👉 The fix: learn the incident table first. Most of what Daniel wants is already there.

2 Incident extends Task

Key term: Incident table

The table incident. Each record is one incident, like INC0010101.

Key term: Task table

The parent table task. Incident, Problem, Change and Request all extend it.

Because Incident extends Task, it gets the Task fields for free: number, state, assignment group, assigned to, work notes, comments and SLAs.

💡 Good to know: Need a refresher? See Fundamentals › Task Management › The Task Table.

3 The key fields

Key incident fields in a table. Caller: who has the issue, for example Sam Lee. Category and Subcategory: what kind of issue, for example Network and VPN, used for routing and reports. Configuration item: which thing is broken, for example snwr-vpn-gw-01. Service and Service offering: which service is affected, for example SNWR Network - VPN. Impact and Urgency: how big and how fast, which set Priority. Assignment group and Assigned to: who works it, from Task. State: where it is in the lifecycle, from Task. Contact type: which channel it came from.
Figure 1. The fields SNWR will configure, and what each one is for.

4 Which fields drive what

Fields Drive
Category, subcategory, CI Routing to the right team
Impact, urgency, priority SLAs and the order of work
Service, service offering Reports on which services break most
State, assignment group Queues and dashboards

💡 Good to know: Before you add a new field, check the form’s field list. Incident already has many fields that aren’t on the form yet.

⭐ Remember: Incident extends Task. Learn the existing fields before you add new ones.

5 Quick recap

  • Each incident is a record in the incident table
  • Incident extends Task, so it gets state, assignment and SLAs
  • Key fields: caller, category, CI, service, impact, urgency, priority
  • Category and CI drive routing; priority drives SLAs
  • Check existing fields before adding new ones

6 Check yourself

Think of your answer first. Then tap to check.

1 Which table does Incident extend? Show answer

Task.

2 Which two fields set the priority? Show answer

Impact and urgency.

3 Daniel wants to know which service broke. Which fields help? Show answer

Service and Service offering.

4 Where do Assignment group and State come from? Show answer

From the Task table.

Nice work! You know how the incident table is built. 🎉
Next up: The Incident Lifecycle and On Hold Reasons

Was this lesson helpful?

Have a question or doubt?

Ask here and get help from instructors and fellow learners.

0 / 300

Only logged-in learners can post.