---
sourceDocument: Brazil Retail Industry
sourceDocumentLink: https://www.servicenow.com/docs/r/retail-industry

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil Retail Industry

ft:clusterId :

    - rahi

bundleId :

    - rahi

workflow :

    - Customer and Industry


---

# Extending the Retail base case

# Extending the Retail base case {#ariaid-title1}

Release version: Brazil  
Updated June 28, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 1 minute to read  
Extend the Retail Case (`sn_retail_case`) base case to create custom case types that take advantage of prebuilt roles, business rules, workflows, and the Retail data model rather than creating them manually.

For general guidelines on implementing case types, see [Best Practices to Implement Case Types](https://mynow.servicenow.com/now/best-practices/assets/best-practices-to-implement-case-types).

All prebuilt Retail case types---except for Retail Customer Complaint, which extends the base CSM case (`sn_customerservice_case`)---extend from the Retail Case (`sn_retail_case`) base case, which in turn extends the CSM case. Use the Retail base case as the starting point when adding a case type.

## Criteria for creating a case type {#rahi-retail-extending-retail-base-case__section_when_new_case_type}

Use the following questions to determine whether your organization needs a new case type or whether an existing service definition is sufficient. More "yes" answers indicate a stronger need for a new case type:

* Is a service definition not enough to support the process due to field attribute or automation requirements? If an existing case type's attributes already fit, define the new work as a service definition rather than a new case type.
* Is the process fundamentally different from every prebuilt and existing custom retail case type?
* Are there different processes or integrations required based on work type, business unit, or the products and services being supported?
* Does the new process have a different state model than your existing ones?
* Are there meaningfully different attributes that need to be collected on the case during intake for this use case?
* Are there meaningfully different attributes for agents to capture on the case as they fulfill for this process?
* Does the fulfilling group interact with a different set of back-end systems to resolve the case?
* Do access and visibility requirements differ? For example, do the records generated for this use case have distinct view restrictions?
* Do fulfillers need a different workspace experience and guidance for this case type?
* Are there future scalability needs, or change-management considerations where shared intake forms and workflows would increase complexity across teams?
**Related concepts**   

* [Service definitions in Retail](https://www.servicenow.com/docs/wQ2C2df1ZyX2rlEilxoxgw "A service definition describes a service that a retail organization offers to support its stores or customers. Service definitions build on case types to encapsulate different types of request and fulfillment processes within a single case type, without creating a new table for every variation.")