Retail case types
Summarize
Summary of Retail case types
Retail case types in ServiceNow represent the specific processes, data, and automation required to resolve different retail-related issues. They enable your retail organization to create and configure distinct categories of cases, each tailored to address unique retail challenges efficiently. Using case types helps avoid technical debt by isolating optimizations and ensuring that improvements in one type do not adversely affect others.
Show less
Key Features
- Distinct Process and Automation: Each retail case type supports unique workflows, forms, fulfillers, categorization, and access controls, reflecting the diversity of retail scenarios.
- Support for Common Retail Use Cases: Examples include store-to-store transfer questions, customer complaints about store cleanliness, product recalls managed across multiple locations, point-of-sale support issues requiring IT or facilities involvement, and alert-driven workflows for actionable retail agent responses.
- Extensibility: The Retail Case (snretailcase) table is abstract as of the Zurich Q3 '25 release, requiring case type extensions for case creation and management. This ensures a scalable framework that supports both prebuilt and custom retail case types.
- Integration with Customer Service Management: Retail cases extend the Customer Service Management case table, retaining all its fields and functionalities.
Practical Considerations for ServiceNow Customers
- Start with at least one retail case type, even if you currently have a single retail process. This practice simplifies adopting additional case types later.
- Use case types to maintain clear separation between different retail processes, preventing conflicts and reducing complexity in your retail support workflows.
- Refer to the Best Practices to Implement Case Types document for guidance on identifying, structuring, and defining case types and their processes. Note that login is required to access this document.
- For implementation and customization, explore resources on extending the Retail base case to tailor case types to your specific retail needs.
A case type represents the processes, data, and automation needed to resolve a specific type of retail issue. Use case types to create and configure the types of cases your retail organization handles.
For general guidelines on implementing case types, read Best Practices to Implement Case Types, which covers:
- How to identify potential case type candidates
- How to structure leaf and base-level case types to support scalability
- How to use service definitions to define processes within case types
You must log in to download the best practices document.
Common use cases in Retail include:
- A store associate may need to ask headquarters a question about a store-to-store transfer policy.
- A customer may complain about cleanliness at a store.
- A food safety manager at HQ may need to drive a product recall across hundreds of locations at once.
- A point-of-sale break/fix or other retail support issue may need support from groups or departments whose processes don't match traditional out-of-the-box process flows.
- A point-of-sale break/fix or other retail support issue may require other records to be created in different tables—such as an Incident or Request assigned to dedicated HQ IT teams, or a Work Order for facilities or field maintenance.
- A monitoring system may create alerts that only require action under specific conditions, requiring dedicated workflows separate from normal resolution patterns to surface actionable alerts to retail agents.
If the above retail use cases were built into the same table, it would create significant technical debt because each optimization to support one process also impacts the other processes running within that case type.
Each of the example use cases requires distinct process and automation needs, distinct fulfillers and form requirements, distinct categorization, and distinct access requirements—making each a candidate for its own case type. Optimizations made within one case type remain within that scope, and the impact on other processes running within Retail is negated.
sn_retail_case) table is abstract and can no longer store records directly, so a case type extension is required.For more information on extending retail case types, see Extending the Retail base case.