ITSM (IT Service Management) is the way an organization designs, delivers, supports and improves the IT services it offers to its users. ServiceNow ITSM is built on ITIL practices and brings them onto one platform with a shared CMDB, so every record can be linked to the services and CIs it affects.

The core processes asked about in interviews are:

1. Incident Management: restore normal service as quickly as possible after an unplanned interruption.

2. Problem Management: find and remove the root cause of one or more incidents so they do not come back.

3. Change Management: control the risk of changes to services and infrastructure, from request to review.

4. Request Fulfilment: handle standard service requests through the Service Catalog.

5. Knowledge Management: capture and share know-how so issues are solved faster and users can help themselves.

These are supported by the CMDB, SLAs, the Service Portal and reporting. A good answer shows how they connect, for example an incident leading to a problem, the problem to a change, and the fix to a knowledge article.

Ask what the user or team actually needs:

Incident: something that worked has stopped working or got worse, and service must be restored. Example: email is down for the sales team.

Service Request: a standard, pre-approved ask that nothing is broken for, usually ordered from the Service Catalog. Example: a new laptop, access to a shared folder, a password reset.

Problem: the unknown cause behind one major incident or several similar ones. Example: email has gone down three Mondays in a row, so someone must find out why.

Change: adding, modifying or removing something that could affect services, so it needs risk assessment and approval. Example: upgrading the mail server to fix that root cause.

The grey areas interviewers like:
- A password reset is a request, not an incident, even though the user "can't log in".
- A user asking "how do I..." is a request (or a knowledge article), not an incident.
- Fixing a problem in production is still a change. Problem finds the fix, Change deploys it.
- One incident can be enough for a problem if it was a major incident.

The next question covers the line between a change and a request in more detail, and the Request Management questions go deeper into requests.

1. Incident: the service desk raises a P1 incident (often a major incident) and focuses on restoring service. If the change is the likely cause, the fastest fix is usually its backout plan.

2. Link the records: link the incident to the change that caused it, so the change shows its impact and nobody has to guess later.

3. Change: the change is closed as Unsuccessful (or reopened for the backout), and a Post Implementation Review captures what went wrong: testing gaps, a missed dependency, a wrong risk rating.

4. Problem: a problem record finds the real root cause, because rolling back restores service but doesn't explain why the change broke it.

5. Knowledge: if there is a workaround, it is documented as a known error or knowledge article so the service desk can handle similar calls quickly.

6. Permanent fix: a new change, raised from the problem, deploys the corrected version, this time with the lessons from the review.

7. Communication: stakeholders and affected users are kept updated throughout, from the major incident through to the fix.

Note: Interviewers want to hear that you restore service first and investigate second, and that every record is linked so the change success rate and repeat incidents can be reported.

What you get:
- Shared fields on every record: number, state, short description, assignment group, assigned to, priority, work notes and comments, approvals, active.
- Shared features: assignment rules, SLAs, approvals, inactivity monitors and the activity stream work the same way across all of them.
- One place for reporting: a report on task can show all open work for a group, whatever the record type, and sys_class_name tells you which type each record is.

What to be careful about:
- A Business Rule, ACL, UI Policy or dictionary change on the task table runs for every child table: incident, problem, change, requested items, HR and more. Put the logic on the child table, or add a condition on sys_class_name.
- Need a field that lives on task to behave differently on one table (for example, make it mandatory, read-only, give it a different default value or reference qualifier only on incident)? Create a Dictionary Override for that table instead of changing the task dictionary entry. Changing the base entry affects every table that inherits the field. The override changes it only for incident and leaves problem, change and the rest untouched. (Choice lists are handled the same way, by adding choices for the incident table rather than for task.)
- A field added to task appears on every child form and list, so add fields to the child table unless they truly belong to all work.
- Querying task directly returns every type, so filter on sys_class_name when you only want one.

The CMDB is what lets the processes understand what is affected:

Incident: the CI on an incident can route it to the right support group and show which business service is impacted, which drives priority.

Change: CIs on a change drive risk assessment, approvals from the CI owners, conflict detection between changes on the same or related CIs, and impact analysis before the change goes in.

Problem: grouping incidents by CI shows which components keep failing, which is how proactive problems are found.

Knowledge: articles can be linked to CIs, so agents see the right fix for the component they are working on.

Note: All of this depends on CMDB quality. Missing relationships mean missed conflicts and wrong impact, so CMDB health is an ITSM concern, not just a CMDB team concern.

Incident: mean time to resolve, first-time fix rate, the share of incidents resolved within SLA, and repeat incidents.

Problem: problems resolved with a permanent fix, average time to find the root cause, and the number of known errors with a documented workaround.

Change: change success rate, the share of emergency changes, and incidents caused by changes.

Knowledge: how often articles are used to resolve incidents, and self-service deflection on the portal.

How they connect: the strongest answer shows the links. Fewer repeat incidents shows Problem Management is working, fewer incidents caused by changes shows Change Management is working, and more incidents solved from knowledge shows Knowledge Management is working.

Note: Pick a few KPIs that drive decisions, and show trends over time rather than one-off numbers.