How Service Processes Differ for Incidents and Service Requests in Salesforce IT Service

Two catalog items can sit side by side in an employee’s IT service catalog and look almost identical.

Request VPN Access asks a few questions and creates a ticket.

Report VPN Issue does the same.

But what happens after the employee hits Submit is completely different.

One is a planned service request that may need approval and fulfillment. The other is an incident that may need prioritization, investigation, escalation, or even problem and change management.

In Salesforce IT Service, that difference starts with the service process behind the catalog item and, more specifically, the target data model or anchor entity assigned to it.

That one configuration decides whether Salesforce creates a Service Request, Case, or Incident and influences which automation, routing, approvals, SLAs, and downstream ITSM processes follow.

Let’s break down how it works.

How Service Processes Work in Salesforce IT Service

A Service Process is the configuration layer behind an IT service catalog item. It defines how Salesforce should handle the request after submission, including the target data model, the information collected at intake, and the workflow that follows.

The key decision is the Target Data Model, also called the anchor entity.

Service Request or Case typically handles standard tasks such as hardware or access, while Incident handles reported service interruptions or degradation.

Quick takeaway: The Target Data Model does more than decide which object gets created. It changes what the form needs to ask, how the ticket is handled, and what “done” looks like.

How the Target Data Model Changes a Salesforce IT Service Process?

When the target changes, the fields, routing, approvals, priority logic, SLAs, and related records can change with it. That is why two catalog items can look similar to the employee but behave very differently for the IT team.

How an Incident Service Process Works in Salesforce IT Service?

An Incident-targeted Service Process is built for something that has already gone wrong. A VPN outage, login failure, or degraded application is not a request for a new capability. It is a disruption that IT needs to understand and restore.

That changes the process immediately.

1. Incident Service Process Attributes, Priority, and SLAs

The intake needs to help the service team diagnose and prioritize the issue. Useful attributes can include:

• What is affected
• When the issue started
• How many users are affected
• Business impact
• Urgency
• Affected service or configuration item

Urgency and Impact can drive Priority, which can then influence SLA milestones and escalation behavior. A high-impact, high-urgency issue can move through a very different response path from a low-impact issue affecting one employee.

In other words: the Service Process is built around triage, prioritization, restoration, and escalation, not approval and planned fulfillment.

2. Incident Management Connections: Problem, Change, and Major Incidents

Once the process targets Incident, the record can also participate in the broader Incident Management lifecycle.

• Problem can support root-cause investigation when the disruption points to a deeper issue.
• Change Request can document and control the technical change used to resolve it.
• Major Incident can be used when the disruption becomes widespread or business-critical.
• Related Incidents can connect reports using relationships such as “Similar” or “Caused By” instead of treating every ticket as an isolated problem.

How a Service Request Process Works in Salesforce IT Service?

A Service Request-targeted process starts from a different place. Nothing is necessarily broken. The employee is asking IT to deliver something through a known, repeatable process.

Think VPN access, approved software, new hardware, or a standard configuration request.

1. Service Request Process Attributes and Approval Configuration

The intake should give approvers and fulfillment teams the context they need to make and complete the request. That can include:

• What is being requested
• Why it is required
• The required option or configuration
• Who needs to approve it
• Where it needs to be delivered

Approval can become a load-bearing step. The request may route to a manager, asset owner, or another responsible approver before fulfillment starts. For more complex workflows, Flow Orchestration can coordinate approval and fulfillment stages across different teams.

A CMDB or Discovery integration can also bring in asset or configuration context automatically, so the employee is not asked to provide information Salesforce already knows.

2. Service Request Fulfillment Flows and Task Assignment

After approval, the workflow shifts into fulfillment. The Service Process can:

• Create fulfillment tasks
• Assign work to the right IT team
• Route work through assignment logic or Omni-Channel
• Call external systems
• Send status updates
• Close the request when fulfillment is complete

The practical difference is simple: an Incident process asks, “How do we restore this?” A Service Request process asks, “How do we deliver this?”

Incident vs Service Request Service Process: Key Configuration Differences

This is the part that matters most: the target data model changes the whole operating path, not just the record name.

Incident vs Service Request Examples in Salesforce IT Service

The easiest way to see the difference is to use the same service — VPN — for both processes.

1. Incident Service Process Example: Report VPN Issue

An employee loses their VPN connection mid-meeting and opens “Report VPN Issue.” The Service Process targets Incident.

• At intake: Salesforce captures diagnostic details such as Urgency, Impact, affected service, and symptoms.
• After submission: the Incident enters the triage and restoration workflow.
• If more employees report the same issue: the service desk can connect the related records instead of investigating each one independently.
• If the issue is broader: it can move into Major Incident handling, Problem Management, or a controlled Change Request for the fix.

The process is built to restore service.

2. Service Request Process Example: Request VPN Access

A new hire opens “Request VPN Access” on their first day. The Service Process targets Service Request.

• At intake: Salesforce collects the information needed to approve and provision access.
• After submission: the request can route to the employee’s manager for approval.
• After approval: assignment logic sends the fulfillment task to IT.
• At completion: IT provisions access, completes the task, and the process updates or closes the request.

No Incident priority. No Major Incident path. No root-cause investigation. The process is built to fulfill the request.

How to Configure Incident and Service Request Processes in Salesforce IT Service?

Building either process correctly starts with confirming your org actually has access to Service Process. It sits under Salesforce IT Service, which isn’t automatically on in every plain Developer Edition signup. It needs the Agentforce-and-Data-Cloud-enabled Developer org (available free from Salesforce’s developer site) or a Service Cloud Enterprise+ org with Agentforce provisioned.

Incident Management (the Incident, Problem, and Change Request objects) is a separate, standard Service Cloud feature and works in any dev org, so it’s worth checking which piece you actually have before you start.‍

1. Turn on Customer Service Incident Management. In Setup, search “Customer Service Incident Management” and toggle it on. This activates the Incident, Problem, and Change Request objects in Object Manager.

2. Grant object access via a permission set. Create a permission set with Read/Create/Edit/Delete on Incident, plus whatever level you need on Problem and Change Request for root-cause tracking, and assign it to your test user.

3. Add the relevant tabs to your app. In App Manager, add the Incident (and Problem/Change Request, if used) tabs so agents can open records directly from the app menu.

4. Open Service Process and create a new Service Process Definition. This is where the catalog-item-to-object mapping gets built.

5. Set the target data model. Choose Incident for a diagnostic, escalation-driven process, or Service Request/Case for an approval-driven fulfillment process. This single setting decides which object every catalog item built on this process will generate.

6. Configure data attributes to match the target. For Incident, prioritize base attributes mapped to Urgency, Impact, and affected system. For Service Request, prioritize attributes that capture what’s requested and who approves it.

7. Attach the process to a Service Catalog item and publish it. Give the item a name that reflects its intent — “Report” for Incident-targeted items, “Request” for Service Request-targeted items — so employees self-route correctly at intake.

8. Test end to end. Submit a test request as your test user and confirm it creates the correct record type with the right fields populated.

Conclusion

Incident and Service Request processes work differently because they are built for different outcomes.

An Incident Service Process helps IT respond to an issue, understand what went wrong, and restore service. A Service Request Process moves a standard request through approval, assignment, and fulfillment.

The key is making sure the Service Process matches the type of work behind the catalog item.

When that setup is right, requests are easier to route, manage, and complete for both IT teams and employees.

At MIDCAI, we help businesses design Salesforce IT Service implementation around how their teams actually work.

Need help structuring Service Processes in Salesforce IT Service? Let’s talk.