Create a table for a case type |
The first step in creating a case type is to create a table for the case type that
extends the Case table (sn_customerservice_case). This table should be created in a scope
other than global. You can create a table for the case type using one of these methods:
- Guided Application Creator
- Platform table creation feature
The extended table for the case type inherits most of the functionality of the Case
table. |
Set up view rules |
View rules determine the form views that are available to users. Create view rules that
determine the conditions for when the system displays the Case Type table in a specified
view. |
Set up states for state flows |
State flows enable you to customize transitions from one state to another in tables
derived from the Task [task] table, including the Case [sn_customerservice_case] table and
tables extended from Case. You can configure the system to perform work during transitions to
specific states. Create choice records for each of the states to be used in state flows
for the case type. When creating your desired states, set the Table
field to the table for the case type and the Element field to State.
|
Set up UI policies |
UI policies dynamically change the behavior of information on a form, such as setting a
field to read-only or making a field mandatory. The case type inherits the following UI
policies from the Case table:
- Show or hide major case information section
- Make Partner Contact Read only If Partner is empty
You can configure additional UI policies for the Case Type form. |
Set up client scripts |
Client scripts allow the system to run JavaScript on the client when client-based
events occur, such as when a form loads or when a field changes value. The case type inherits
the following client scripts from the Case table:
- Empty Partner Contact on Partner Change
- Empty Case Form on Account Change
- Hide Request Related List
- Hide SM section and list if no plugin
- Hide Related Records Section
You can configure additional client scripts for the case type. |
Set up business rules |
A business rule is a server-side script that runs when a record is displayed, inserted,
updated, or deleted, or when a table is queried. Use business rules to accomplish tasks like
automatically changing values in form fields when certain conditions are met, or to create
events for email notifications and script actions. You can set up the desired business
rules for the Case Type table. |
Set up case type UI actions |
UI actions include the buttons, links, and context menu items that appear on lists and
forms. A case type inherits the UI actions from the Case table. You have the following
options when setting up UI actions for a case type:
- Create new UI actions for the case type. If you create a new UI action, select the Case
Type table in the Table field on the UI Action form.
- Use any of the inherited case UI actions.
- Use a combination of the two.
You can also block any inherited case UI actions that you do not want. |
Create a case type definition record |
Register a newly created case type by creating a case type definition record. This
record is stored in the Case Type table (sn_case_type) and includes the following
information:
- The name of the case type
- The table created for the case type
- An optional category
- A short description
- A field for setting the case type to active
The Case Type table extends the Application File table (sys_metadata). This table
includes a Domain column that customers can use to add their own
logic. To create a case type definition record, navigate to and click New. |
Set up case type processes |
After creating and saving the case type definition record, you can configure the
following process information for the case type using the related lists on the Case Type
form:
- State flows
- Special handling notes
- SLAs
- Email templates
- Quick messages
- Reports
Note: These related lists only display information for the new case type. They do not
include information for the base case. |
Set up notifications |
Notifications keep users informed about different activities and events. You can
determine the conditions when a notification appears by creating a record in the Notification
table. |
Set up roles |
Create one or more roles to control access to the case type features and capabilities.
Then grant these roles access to the desired applications and modules. For agents to work on
a case type, configure the case type role to contain the sn_customerservice_agent role. |
Set up ACLs |
Use Access Control List rules (ACLs) to restrict access to data. These rules require
users to pass a set of requirements before they can interact with data. For external
customers to see a case type, add ACLs that provide read or create access for external
users. |
Set up case type selection conditions |
When creating a case of a specific type, an agent clicks Create
Case and then selects from a list of available case types. The system presents
the case types that have been configured for the agent's role. To set up case type
selection conditions, use Flow Designer to configure the Get Case
Types flow and modify the conditions that determine visibility for a case
type. There are two different implementations of the Create
Case UI action:
- The Customer Service plugin provides a Create Case UI action that
agents can use as follows:
- To create a base case.
- To create a case for one specific case type. For example, if your organization always
creates the same type of case and you have created only one extension of the Case table,
you can modify this UI action to create a case of that specific case type.
- The Customer Service Case Types plugin also provides a Create
Case UI action that agents can use to create a case based on a selected case
type. After clicking this UI action to create a case, the agent selects the desired case
type from a list of multiple available case types.
Note: It is recommended that you configure one of the Create Case
UI actions but not both to avoid confusion. |
Set up record producers |
A record producer is a specific type of catalog item that enables users to create
task-based records, such as case records, from the service catalog. Create a record producer
that exposes the new case type on the Customer Service Portal. |
Set up the case digest feature for case types |
The case digest feature enables agents to proactively communicate with customers and
internal stakeholders about cases. While a case is in progress, agents can send periodic case
summaries that describe actions taken, next steps, and other case-related information. When
the work on a case has been completed, agents can create a post case review that includes
information such as the root cause, mitigation plan, and preventive actions. Note: Using case
types with the case digest feature requires the Customer Service Case Types plugin
(com.snc.csm_case_types) and the Case Digests plugin (com.sn_csm_case_digest).
Cases that are created from a selected case type can use Case Action Summaries and
Post Case Reviews. To create the mapping that identifies the case type fields that are
copied to Post Case Review and Case Action Summary records:
- Create a configuration for the desired case type. Navigate to and click New.
- Create new records in the CSM Table Map table (csm_table_map) to map the
Send Case Action Summary and Create Post Case
Review UI actions.
The Case Digests related list on the Case Type form shows the case action
summaries and post case review configurations for a case type. |
Set up contextual search for case types |
Navigate to and create a table configuration record to add contextual search to the case
type. In this record, configure the Table field as the case type and
the Search Context field as Case Knowledge Base Search. |