Your Returns & Refund Processing Data Template

Salesforce Commerce Cloud
Your Returns & Refund Processing Data Template

Your Returns & Refund Processing Data Template

This template provides a comprehensive guide to collecting the necessary data for analyzing your returns and refund process. It outlines the essential data fields, key activities to track, and offers specific guidance on how to extract this information from your source systems. Use this template to prepare your event log for a smooth process mining project.
  • Recommended attributes to collect
  • Key activities to track
  • Extraction guidance for Salesforce Commerce Cloud
New to event logs? Learn how to create a process mining event log.

Returns & Refund Processing Attributes

These are the recommended data fields to include in your event log for comprehensive returns and refund processing analysis within Salesforce Commerce Cloud.
5 Required 7 Recommended 9 Optional
Name Description
Activity Name
ActivityName
The name of the specific business process step or event that occurred within the return process.
Description

This attribute describes the specific task or milestone that was completed at a given point in time for a return case. Examples include 'Return Request Created', 'Item Received At Warehouse', and 'Refund Processed'.

In process mining, the Activity Name is used to construct the process map, showing the sequence of steps and the flow of cases. Analyzing activities is key to identifying bottlenecks, rework loops, and deviations from the standard process.

Why it matters

It defines the steps in the process map, allowing for visualization and analysis of the return workflow.

Where to get

This attribute is typically derived from event logs, status change records, or task completion data associated with the Return Order or Case objects in Salesforce.

Examples
Return Request ApprovedItem Inspection CompletedRefund Processed
Event Time
EventTime
The timestamp indicating when the specific activity or event occurred.
Description

Event Time records the exact date and time that an activity was executed or a status change happened. This timestamp is crucial for sequencing events correctly and for performing any time-based analysis.

Process mining relies on these timestamps to order activities, calculate cycle times and waiting times between steps, and analyze process performance over different time periods. Accurate timestamps are the foundation of a reliable process analysis.

Why it matters

This timestamp establishes the chronological order of activities, which is fundamental for calculating cycle times and identifying process delays.

Where to get

This is typically the creation or modification timestamp of a record in Salesforce Commerce Cloud, such as 'CreatedDate' or 'LastModifiedDate' on objects related to the return process.

Examples
2023-04-15T10:00:00Z2023-04-16T14:30:00Z2023-04-18T09:15:22Z
Return Case ID
ReturnCaseId
The unique identifier for a single customer return case, linking all related activities from initiation to closure.
Description

The Return Case ID serves as the primary identifier, linking all activities associated with a specific customer return or refund request. This ensures that the entire lifecycle of a return, from its initiation to its final closure, can be tracked and analyzed comprehensively.

In process mining, this attribute is fundamental for case reconstruction. Each event with the same Return Case ID is part of the same process instance. This allows for the visualization of process maps, calculation of case-level KPIs like cycle time, and analysis of process variants related to returns.

Why it matters

This is the primary key that connects all steps of a return process into a single, traceable case, which is essential for end-to-end process analysis.

Where to get

This identifier is typically generated by the Return Merchandise Authorization (RMA) process within Salesforce Commerce Cloud. It is often found on the Return Order or Case object.

Examples
RT-0012345RT-0012346RT-0012347
Last Data Update
LastDataUpdate
The timestamp indicating when the data was last extracted or refreshed from the source system.
Description

This attribute records the date and time of the most recent data pull from Salesforce Commerce Cloud. It provides transparency into the freshness of the data being analyzed.

This information is vital for users to understand how current the process analysis is. It helps in managing expectations about the data's timeliness and is important for validating the completeness of the dataset.

Why it matters

It informs users about the timeliness of the data, ensuring they understand if the analysis reflects the most current process state.

Where to get

This timestamp is generated by the data extraction tool or script at the time of the data refresh. It is not a field within Salesforce.

Examples
2023-05-20T02:00:00Z2023-05-21T02:00:00Z
Source System
SourceSystem
The system from which the event data originates.
Description

This attribute identifies the source system where the data was generated. For this process, it will consistently be 'Salesforce Commerce Cloud'.

In a broader analysis context, this field is useful when combining data from multiple systems to understand how processes flow across different platforms. It ensures data lineage is clear and helps in diagnosing data quality issues specific to a source.

Why it matters

It provides context about the data's origin, which is crucial for data governance and when integrating data from multiple enterprise systems.

Where to get

This is a static value added during data extraction and transformation. It is not a field within Salesforce itself but is defined as part of the data model.

Examples
Salesforce Commerce Cloud
Actual Refund Amount
ActualRefundAmount
The final monetary value that was actually refunded to the customer.
Description

This attribute represents the final amount credited back to the customer after all assessments, deductions, and calculations are complete. This could differ from the requested amount due to factors like restocking fees, promotions, or the condition of the returned item.

Analyzing this attribute is essential for financial reconciliation and for the 'Refund Amount Discrepancy Analysis' dashboard. It helps quantify the financial impact of return policies and identifies systemic issues in the refund calculation and approval workflow.

Why it matters

This is the final financial outcome of the return. Comparing it to the requested amount reveals the financial impact of return policies and adjustments.

Where to get

This value is typically stored on a Refund or Payment Transaction object related to the Return Order in Salesforce Commerce Cloud.

Examples
49.99115.000.00
Processing Agent
ProcessingAgent
The user or agent responsible for handling the return or a specific activity within the return process.
Description

This attribute identifies the employee or system user who performed an action on the return case, such as approving the request, inspecting the item, or processing the refund. It can be a specific user ID or name.

Analyzing the Processing Agent helps in understanding performance variations between individuals or teams. It is key for the 'Agent Performance and Consistency' dashboard to identify training needs, balance workloads, and standardize procedures across the organization.

Why it matters

It enables analysis of performance and consistency across different users, helping to identify best practices and areas for training.

Where to get

Typically found in fields like 'OwnerId' or 'LastModifiedById' on the Case or Return Order objects in Salesforce. May also be stored in related task or history objects.

Examples
Alice SmithBob JohnsonSystem Automation
Product SKU
ProductSku
The Stock Keeping Unit (SKU) of the item being returned.
Description

This attribute is the unique identifier for the specific product being returned. It allows for detailed analysis at the individual product level.

Analyzing returns by Product SKU helps identify products with high return rates, which may indicate quality control problems, poor product descriptions, or manufacturing defects. This information is vital for the 'Warehouse Receipt to Inspection Time' dashboard, as it can reveal if certain types of products take longer to inspect.

Why it matters

It allows for analysis of return patterns by specific products, helping to pinpoint items with quality or description issues.

Where to get

This information is located on the Return Order Line Item or a related object that links the return case to the specific product from the original order.

Examples
SHIRT-BL-M-001PANTS-BK-32-004SHOE-RD-10-012
Requested Refund Amount
RequestedRefundAmount
The monetary value of the refund requested by the customer at the time of return initiation.
Description

This attribute captures the initial refund amount expected by the customer, which is typically the price of the returned item. This value serves as a baseline for the refund calculation process.

This amount is compared against the 'Actual Refund Amount' in the 'Refund Amount Discrepancy Analysis' dashboard. Significant or frequent differences can point to issues with return policies, restocking fees, or system calculation errors, which can lead to customer dissatisfaction.

Why it matters

It serves as a baseline to compare against the final refund amount, helping to identify discrepancies and analyze the financial impact of adjustments.

Where to get

This value is usually stored on the Return Order or Return Order Line Item object, derived from the original sales order.

Examples
49.99125.0089.50
Return Channel
ReturnChannel
The channel through which the return was initiated, such as online, in-store, or via customer service.
Description

This attribute specifies the method used by the customer to start the return process. Common channels include an online self-service portal, bringing the item to a physical store, or contacting a customer service representative.

Understanding the return channel is important for the 'Return Volume and Throughput Trends' dashboard. It helps in allocating resources effectively and analyzing if certain channels are associated with longer cycle times, different return reasons, or higher processing costs.

Why it matters

It helps segment return data to understand process differences and resource needs across different channels like online or in-store.

Where to get

This may be a field on the Return Order or Case object, or it could be inferred from the user or system that created the return record.

Examples
Online PortalIn-StoreCustomer Service Call
Return Cycle Time
ReturnCycleTime
The total time elapsed from the creation of the return request to the final closure of the case.
Description

This metric measures the end-to-end duration of the return process for a single case. It is calculated by taking the difference between the timestamp of the first event ('Return Request Created') and the last event ('Return Case Closed').

As a primary KPI for the 'Return Processing Cycle Time Analysis' dashboard, it provides a high-level view of process efficiency. Analyzing its distribution helps identify outliers and understand the overall performance of the returns operation.

Why it matters

This is a key performance indicator for overall process efficiency. Reducing it directly improves the customer experience and lowers operational costs.

Where to get

This is a calculated metric, generated during data transformation by subtracting the start time of the first activity from the end time of the last activity for each case.

Examples
10 days 4 hours21 days 8 hours5 days 2 hours
Return Reason
ReturnReason
The reason provided by the customer for returning the item.
Description

The Return Reason captures why a customer initiated a return. This is often selected from a predefined list, such as 'Incorrect Size', 'Damaged Item', or 'No Longer Needed'.

This attribute is crucial for root cause analysis. By analyzing return reasons, businesses can identify trends related to product quality, sizing issues, or description inaccuracies. This insight can drive improvements in product development, marketing, and supply chain, ultimately reducing the overall volume of returns.

Why it matters

Understanding why items are returned is key to identifying root causes, such as product defects or sizing issues, which can help reduce future return volumes.

Where to get

This is typically a picklist field on the Return Order or Case object in Salesforce, often populated by the customer during the return initiation process.

Examples
Incorrect SizeItem Damaged on ArrivalWrong Item Shipped
Customer ID
CustomerId
A unique identifier for the customer who initiated the return.
Description

This attribute is the unique ID associated with the customer's account. It allows for the aggregation of return data at the customer level.

Analyzing returns by Customer ID can help identify customers with unusually high return rates, which may indicate fraudulent behavior or chronic dissatisfaction. It also enables analysis based on customer segments, helping to understand if certain customer groups have different return patterns or behaviors.

Why it matters

It enables customer-level analysis to identify frequent returners and understand return behavior across different customer segments.

Where to get

This is a standard field on the Order and Case objects in Salesforce, linking back to the Customer or Account object.

Examples
CUST-98765CUST-12345CUST-55555
Is SLA Compliant
IsSlaCompliant
A boolean flag indicating whether the refund was processed within the defined SLA target date.
Description

This flag is set to 'true' if the 'Refund Processed' activity occurred on or before the 'Refund SLA Target Date', and 'false' otherwise. It provides a clear, binary outcome for SLA performance on a case-by-case basis.

This attribute is the foundation for the 'Refund SLA Compliance Dashboard' and the 'Refund SLA Adherence Rate' KPI. It simplifies the analysis of compliance rates and allows for drilling down into the reasons for non-compliance by slicing the data with other attributes like 'Processing Agent' or 'Return Channel'.

Why it matters

It simplifies SLA performance analysis, allowing for easy calculation of compliance rates and identification of factors contributing to delays.

Where to get

This is a calculated attribute. The logic is: IF (Timestamp of 'Refund Processed' <= RefundSlaTargetDate) THEN true ELSE false.

Examples
truefalse
Item Condition
ItemCondition
The assessed condition of the returned item upon inspection at the warehouse.
Description

After a returned item is received, it is typically inspected to determine its condition. This attribute records the outcome, such as 'New', 'Used - Resalable', or 'Damaged'.

This assessment directly impacts the final refund amount and is a key input for the 'Return Policy Adherence Overview' dashboard. Tracking this data helps in understanding the quality of returned goods and managing inventory for resale, refurbishment, or disposal.

Why it matters

This assessment often determines the final refund amount and is critical for inventory management of returned goods.

Where to get

This is typically a custom field updated during the 'Item Inspection' activity, located on the Return Order Line Item object.

Examples
New/UnopenedUsed - Like NewDamaged/Unsalable
Receipt To Inspection Time
ReceiptToInspectionTime
The duration between the item being received at the warehouse and the completion of its inspection.
Description

This calculated metric measures the time taken for a key internal step in the warehouse. It is the difference between the timestamps of the 'Item Received At Warehouse' and 'Item Inspection Completed' activities.

This duration is the focus of the 'Warehouse Receipt to Inspection Time' dashboard and the 'Avg Item Receipt-Inspection Time' KPI. Analyzing this metric helps identify bottlenecks in warehouse operations, which can be a significant contributor to overall process delays.

Why it matters

It helps pinpoint internal warehouse bottlenecks that delay the entire return process, impacting refund times and inventory availability.

Where to get

This is calculated during data transformation by subtracting the timestamp of 'Item Received At Warehouse' from the timestamp of 'Item Inspection Completed'.

Examples
1 day 2 hours3 days 0 hours8 hours
Refund SLA Target Date
RefundSlaTargetDate
The target date by which the refund for the return case should be fully processed.
Description

This attribute defines the service level agreement (SLA) deadline for completing the refund. It is typically calculated based on business rules, such as a set number of days after the return request is approved or the item is received.

This date is the benchmark against which actual performance is measured in the 'Refund SLA Compliance Dashboard'. Monitoring compliance helps ensure a consistent and positive customer experience and allows managers to identify teams or process steps that are putting SLAs at risk.

Why it matters

It defines the performance target for refund processing, enabling the measurement of SLA compliance and its impact on customer satisfaction.

Where to get

This is often a calculated field on the Case or Return Order object, derived from the creation or approval date plus a predefined time interval (e.g., CreatedDate + 14 days).

Examples
2023-04-29T23:59:59Z2023-05-10T23:59:59Z2023-05-15T23:59:59Z
Rejection Reason
RejectionReason
The specific reason why a return request or refund was denied.
Description

When a return is not approved or a refund is denied, this attribute captures the justification. Examples include 'Outside Return Window', 'Item Damaged by Customer', or 'Non-returnable Item'.

This information is critical for the 'Rejected and Escalated Returns' dashboard. Analyzing rejection reasons helps the business understand points of friction in the return policy and process. This can lead to clearer communication with customers, policy adjustments, or improved initial vetting of return requests.

Why it matters

It provides crucial insights into why returns fail, helping to improve return policies, customer communication, and agent training.

Where to get

This is often a custom field on the Return Order or Case object, which is populated when the status is changed to 'Rejected' or 'Closed - Denied'.

Examples
Return period expiredItem not in original conditionFinal sale item
Return Policy Adherence
ReturnPolicyAdherence
An indicator of whether the return complies with established business policies.
Description

This attribute flags or categorizes returns based on their adherence to company policies, such as the return window, item condition, or proof of purchase. It can be a boolean flag (Compliant/Non-compliant) or a more detailed status.

This attribute is central to the 'Return Policy Adherence Overview' dashboard and the 'Policy Non-Compliance Rate' KPI. It allows the business to monitor how consistently policies are being applied and to analyze the impact of non-compliant returns on the process and financials.

Why it matters

It enables monitoring of policy enforcement, which is crucial for managing costs, preventing fraud, and ensuring fair and consistent customer treatment.

Where to get

This is often a derived attribute based on a set of business rules applied to other data points, such as the return date, item condition, and product type.

Examples
CompliantNon-compliant - Late ReturnNon-compliant - Damaged Item
Return Status
ReturnStatus
The current status of the return case in its lifecycle.
Description

This attribute indicates the current state of the return, such as 'Pending Approval', 'Item Received', 'Refunded', or 'Closed'. This is a dynamic attribute that changes as the case progresses through the workflow.

While process mining derives the flow from activities, having the current status provides valuable context for filtering and analyzing open versus closed cases. It helps in operational monitoring to understand the current backlog and workload at different stages of the process.

Why it matters

It provides a snapshot of where a return case is in the process, which is useful for operational monitoring and filtering for active cases.

Where to get

This is a standard 'Status' field on the Return Order or Case object in Salesforce Commerce Cloud.

Examples
Pending ApprovalApprovedItems ReceivedClosed
Warehouse Location
WarehouseLocation
The identifier of the warehouse or facility where the returned item was received.
Description

This attribute specifies which physical location processed the returned item. This is particularly relevant for businesses with multiple distribution centers.

Analyzing by Warehouse Location can reveal performance differences between facilities. For example, it can show if certain warehouses have longer inspection times or higher rates of items being marked as damaged. This helps in standardizing operations and addressing facility-specific issues.

Why it matters

It allows for performance comparison between different warehouses, highlighting variations in processing times or quality assessment.

Where to get

This information might be stored on the Return Order or a related shipping object. It may also be inferred from the user who performed the receiving activity.

Examples
WH-EAST-01WH-WEST-03WH-CENTRAL-02
Required Recommended Optional

Returns & Refund Processing Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and optimization.
6 Recommended 7 Optional
Activity Description
Item Inspection Completed
This activity marks the completion of the item's inspection, where its condition is assessed and documented. It is captured by a status change on the return item, triggering the next step like refund calculation.
Why it matters

This is a key decision point in the process that determines whether a refund is warranted. The duration from receipt to inspection completion is a major KPI for warehouse operations.

Where to get

Inferred from a status update on the ReturnOrderItem object to 'Inspected' or when the 'reasonForReturn' is confirmed by an agent.

Capture

Detect change in ReturnOrderItem.status field to 'Inspected'.

Event type inferred
Item Received At Warehouse
This activity marks the physical receipt of the returned item at the designated warehouse or processing center. It is captured when a warehouse operator scans the item, which updates the status of the associated ReturnOrderItem.
Why it matters

This is a critical milestone that transitions the process from customer action to internal processing. It is the starting point for measuring warehouse efficiency KPIs, like receipt-to-inspection time.

Where to get

Inferred from a status change on the ReturnOrder or ReturnOrderItem object to a 'Received' state, or when the 'quantityReceived' field is populated.

Capture

Detect update to ReturnOrderItem.quantityReceived or status change to 'Received'.

Event type inferred
Refund Processed
This activity confirms that the refund has been successfully processed by the payment gateway and funds have been sent to the customer. This event is usually triggered by a confirmation callback from the payment provider.
Why it matters

This is a critical milestone for measuring Refund SLA Adherence. It confirms the successful completion of the financial portion of the return process.

Where to get

Captured from a callback event from the payment gateway that updates the status of the associated Payment or Refund object in Salesforce to 'Processed' or 'Completed'.

Capture

Track confirmation event from payment provider updating Payment object status.

Event type explicit
Return Case Closed
This activity represents the final closure of the return case in the system, after a refund, exchange, or rejection is finalized. It is inferred from the ReturnOrder status changing to 'Closed' or 'Completed'.
Why it matters

As the primary end point of the process, this activity is essential for calculating overall cycle times and measuring the throughput of the returns processing operation.

Where to get

Inferred from the timestamp when the status field of the ReturnOrder object is updated to its final state, such as 'Closed' or 'Completed'.

Capture

Detect change in ReturnOrder.status field to 'Closed'.

Event type inferred
Return Request Approved
This event signifies that a return request has been reviewed and authorized by a service agent or an automated rule. It is typically inferred from a status change on the ReturnOrder object, for example, from 'New' to 'Approved'.
Why it matters

Tracking this milestone helps analyze the approval stage's efficiency and identify bottlenecks. The time between creation and approval is a critical KPI for agent performance.

Where to get

Inferred from the timestamp when the status field of the ReturnOrder object is updated to a value representing approval, such as 'Approved' or 'Authorized'.

Capture

Detect change in ReturnOrder.status field to 'Approved'.

Event type inferred
Return Request Created
This activity marks the creation of a return authorization case in the system. It is captured when a new ReturnOrder record is created in Salesforce Commerce Cloud, either by a customer via the storefront or by a service agent.
Why it matters

As the starting point of the return process, this activity is essential for measuring the end-to-end cycle time and analyzing the volume of incoming return requests over time.

Where to get

This event is captured from the creation timestamp of the ReturnOrder object in Salesforce Commerce Cloud OMS.

Capture

Track the creation of a new ReturnOrder record.

Event type explicit
Exchange Order Created
For returns resulting in an exchange, this event marks the creation of a new sales order for the replacement item. This is an alternative path to a monetary refund.
Why it matters

Tracking this path separately from refunds is important for understanding exchange rates and the efficiency of the exchange fulfillment process.

Where to get

Captured from the creation of a new SalesOrder object that is linked to the original ReturnOrder.

Capture

Track creation of new SalesOrder linked to the ReturnOrder ID.

Event type explicit
Item Inspection Started
This event signifies the beginning of the quality and condition assessment of the returned item. It is typically inferred when the status of the return item changes to 'Inspecting' or a similar state.
Why it matters

Tracking the start of inspection helps isolate the pure inspection duration from the overall warehouse waiting time, providing a more granular view of potential bottlenecks.

Where to get

Inferred from a status update on the ReturnOrderItem object to a value like 'Inspecting' or 'Under Inspection'.

Capture

Detect change in ReturnOrderItem.status field to 'Inspecting'.

Event type inferred
Refund Amount Calculated
This represents the step where the final refund amount is determined, accounting for factors like item condition, restocking fees, or promotions. This is often an automated system step that populates refund amount fields.
Why it matters

Analyzing this step is crucial for the 'Refund Amount Discrepancy Analysis' dashboard, highlighting cases where the final amount differs from what the customer requested.

Where to get

This event can be inferred from the population or update of refund amount fields on the ReturnOrder or an associated refund payment object.

Capture

Detect timestamp of when refund amount fields are populated.

Event type inferred
Refund Approved
This activity signifies that the calculated refund amount has been approved and is ready to be processed. This may be an automatic step or require manual approval for high-value returns.
Why it matters

This approval step can be a bottleneck, especially if it requires manual intervention. It's a key milestone before the financial transaction is initiated.

Where to get

Inferred from a status change on the ReturnOrder or a related payment summary object to a state like 'Refund Approved' or 'Ready for Refund'.

Capture

Detect status change on ReturnOrder or related payment object.

Event type inferred
Refund Initiated
This event marks the point where Salesforce Commerce Cloud sends the refund request to an external payment gateway. It represents the start of the financial transaction.
Why it matters

Distinguishing between initiation and processing is key to SLA compliance analysis. Delays after this point are typically related to the payment provider, not internal processing.

Where to get

Captured from an explicit event log or API call record when the system communicates with the payment gateway. It can also be inferred from a status change on a Payment object.

Capture

Track API call event to payment gateway or a status change to 'Refund Pending'.

Event type explicit
Return Label Generated
This activity represents the point when a shipping label is created for the customer to use for returning the item. This may be captured explicitly if an integration with a shipping provider logs this event against the return case.
Why it matters

This step is a key part of the customer experience and can be a source of delay if the generation process is not smooth. It marks the handoff to the customer to ship the item.

Where to get

Potentially logged in a custom field or related object on the ReturnOrder object by a shipping integration like Salesforce Shipping.

Capture

Track event from shipping integration or custom object creation.

Event type explicit
Return Request Rejected
This event indicates that a return request has been denied and will not be processed further. This is captured when the ReturnOrder status is updated to 'Rejected' or 'Canceled' prior to goods being received.
Why it matters

Analyzing rejected returns helps identify common reasons for denial, such as policy violations, which can improve customer communication and frontend validation rules.

Where to get

Inferred from the timestamp when the status field of the ReturnOrder object is updated to a value representing rejection, like 'Rejected' or 'Denied'.

Capture

Detect change in ReturnOrder.status field to 'Rejected'.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from Salesforce Commerce Cloud