Creating a Case Type

As illustrated here, Cases are a record of a request for some type of service or support from an account, customer, or employee. Each line in the illustration is one event in the record. This record allows you to track interactions with the service requester. Cases also record details like how much time has passed since the Case was created, what actions were taken to resolve the issue, priority, associated products, or warranties, and much more. Cases are sometimes referred to as service requests.​

The administrator can create types to model any type of service workflow based on the organization’s business processes. ​The administrator can add phases, steps, approvals, and automated flows to each Case Type. ​

Phases and steps will guide the agents visually through processing the Case.​ Considering that the solution offers some benefits and limitations, it is up to the administrator to identify if one or multiple Case Types are required for the organization.

Existing Cases can be changed, but only by executing the action "Create New Version" from the existing Case Type that has to be modified. For example, if after creating a new Case Type, the Administrator realizes that the Service Catalog is missing, they will have to execute the action Create New Version from the existing Case Type, then enter the service catalog and activate the new version.

The simplest scenario is to have one Case Type for the entire organization. This means that all customer requests will be handled with the same Case Type and the same internal workflow. As soon as the assumption that one internal workflow is not enough for addressing all types of customer requests fails, then the administrator will have to determine an additional type of Case for the organization.

Case Designer Step Type

The design of phases and steps, allows the Administrator to tailor each Case Type to the specific business needs. There are currently six types of steps which can be customized and added to each phase:​

• To-Do.
• Autoflow.
• Approval.
• Mashup.
• Feedback.
• Input.
• Assignment.

For example: In the above illustration, Phase 1 Standard Processing contains the elements Use Knowledge Base and Master Data which are To-Do Type steps, as are all of the steps across the two phases. Examples of steps of the Autoflow type could be event notifications to integrated solutions or in-app notifications to users. Approvals are typically routed to a reporting line manager. Finally, examples of steps of the type Mashup would be integration with a Knowledge base, or with SAP S/4HANA Cloud, or jumping to another system. The Assignment step will be used to assign employees to a case based on conditions. Field Input Steps are used to display directly relevant information within a case.

The Best Practice that Service Agents should follow when working on Cases includes the following steps:

1. Follow the suggested steps of each phase.
2. Set the status to In process, execute and mark as done all steps of each phase.
3. Set the status to Complete after completing all steps of each phase.

Service Agents working on Cases can follow the suggested steps for each phase supported by the UI with a specific color coding:

1. Dark Blue represents the active phase.
2. Light Blue represents a completed phase.
3. Grey represents the next phase to be executed.

Then, during the information gathering phase, Service Agents can use the Related Entities facet of a Case for adding the following:

• Registered Products.
• Installed Bases.
• Installation Points.

Using the ellipses button you have access to ‘More Actions’. Service Agents can also:

1. Escalate the Case.
2. Mark the Case an ‘Unread’.
3. Create a Summary of the Case.
4. Mark the Case as Irrelevant.