You are here:
Context Definitions for Unified Catalog
Unified Catalog uses context definitions to manage specific use cases. These use cases are scenarios where you collect and route data to Salesforce objects other than the primary objects—Case, Service Request, or Incident. This approach makes sure that detailed data required for complex fulfillment or subsequent reporting routes accurately and persists on the correct external record.
Role in Process Types and Attributes
Context definitions include a set of predefined attributes into the service process through the selected process type—Case, Incident, or Service Request.
These attributes represent the fields that appear on the intake form. The attributes make sure that you capture specific data points. This data is necessary for fulfillment or for updating related records outside the primary process type.
Context definitions drive the fulfillment tasks by dictating the initial intake attributes necessary to capture the request.
See Context Definitions.
Service Process Flow: Access Request
This example illustrates how context definition ensures proper data handling and separation during a service request. The example highlights the distinct roles of the primary service request for tracking status and the secondary custom object for processing the actual, detailed fulfillment action.
Unified Catalog uses a context definition (Folder_Access_CD) to create a record in a non-anchor object, such as the custom object Project_Access__c. This context definition applies when an employee requests access to a secure folder. The context definition makes sure that specific attributes, such as Folder_Name, Required_Duration, and Justification_Text, are collected through the intake form. These collected attributes are then accurately routed to populate the new Project_Access__c record for auditing, which is separate from the primary Service Request (SR) work item.
The context definition acts as the data blueprint that makes sure that specific intake information routes to a secondary record for audit and fulfillment. Here’s the Service Process flow:
| Step | Action | Role of Context Definition | Outcome |
|---|---|---|---|
| 1. Intake | Employee submits the Secure Folder Access request. | Context definition dictates the exact fields on the intake form (for example Folder Name, Duration). | The primary Service Request (SR) object is created. |
| 2. Creation | The routing process finishes. | The context definition makes sure that the data is used to populate a new, non-anchor record. | The Project_Access__c (Audit or Fulfillment Record) context definition is created and populated with the exact access details. |
| 3. Fulfillment | IT team completes the work. | The fulfillment step references the detailed Project_Access__c record. | The SR is closed, and the audit data is permanently stored on the correct secondary object. |
The Service Process uses the detailed data on the Project_Access__c record (which the context definition created and populated) to fulfill the request. The process uses the main Service Request record specifically to track the request's overall status and lifecycle.
- Associate Context Definitions with Unified Catalog
Enlist your context definitions in Unified Catalog to make them available for building service processes. After creating a context definition, you must make it available within Unified Catalog. This step allows its predefined attributes to be selected and included in the process type—Case, Incident, or Service Request.
