Data Template: Order to Cash - Sales Order Processing
Your Order to Cash - Sales Order Processing Data Template
- Recommended attributes to collect
- Key activities to track
- Extraction guidance for Salesforce Sales Cloud
Order to Cash - Sales Order Processing Attributes
| Name | Description | ||
|---|---|---|---|
Activity Name ActivityName | The name of the specific business event or task that occurred within the sales order lifecycle. | ||
Description The Activity Name describes a step in the sales order process, such as 'Order Created', 'Credit Check Performed', or 'Invoice Sent'. These activities are the building blocks of the process map and are derived from system events, status changes, or task completions. Analyzing these activities allows for the visualization of the process flow, identification of common pathways (variants), and measurement of the frequency and duration of each step. It is fundamental to understanding what is happening in the process. Why it matters This attribute defines the steps in the process map. Without it, you cannot visualize the process flow or analyze how sales orders are actually being handled. Where to get Typically derived from status changes in the 'Order.Status' field, creation of related records (e.g., Invoice), or completed 'Task' or 'Event' records related to the Order. Examples Order CreatedOrder ApprovedGoods ShippedPayment Received | |||
Event Time EventTime | The exact date and time when the activity occurred. | ||
Description Event Time, or timestamp, records the precise moment an activity took place. This data is critical for sequencing events correctly and calculating durations between activities, which is the foundation of all time-based process mining analysis. This attribute is used to order the activities for each case, calculate cycle times, identify waiting times, and analyze process performance over different time periods. Inaccurate or missing timestamps can severely limit the usefulness of the analysis. Why it matters Timestamps are essential for ordering events chronologically and calculating all performance metrics, such as cycle times and bottlenecks. Where to get Corresponds to fields like 'CreatedDate' or 'LastModifiedDate' on the 'Order' object or related records. For specific events, it might come from the completion date of a 'Task' record. Examples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z | |||
Sales Order SalesOrderId | The unique identifier for each sales order, serving as the primary case for tracking the entire order-to-cash process. | ||
Description The Sales Order ID is the cornerstone of the process analysis, uniquely identifying each customer order as it moves through its lifecycle. It links all associated activities, from creation and approval to fulfillment and payment. In process mining, every event related to a specific order is tied back to this ID. This allows for the end-to-end reconstruction of the order's journey, enabling detailed analysis of cycle times, process variations, and bottlenecks for individual orders. Why it matters This attribute is essential for grouping all related events into a single case, making it possible to visualize and analyze the end-to-end process flow for each sales order. Where to get This is the 'Id' field on the standard Salesforce 'Order' object. Examples 8018d000000XwPBAA08018d000000Y1qCAAS8018d000000Z3kDAB1 | |||
Last Data Update LastDataUpdate | The timestamp indicating when the data was last extracted or refreshed. | ||
Description This attribute records the date and time of the most recent data pull from the source system. It provides crucial context about the freshness of the data being analyzed. Analysts use this information to understand if they are viewing the most current process data and to assess the relevance of their findings. It is a key piece of metadata for any process mining project. Why it matters Informs users about the timeliness of the data, ensuring they understand how current the analysis is. Where to get This is a timestamp generated and added during the data extraction, transformation, and loading (ETL) process. Examples 2023-11-01T05:00:00Z | |||
Source System SourceSystem | Identifies the system from which the data was extracted. | ||
Description This attribute specifies the origin of the process data. For this analysis, it will consistently be 'Salesforce Sales Cloud'. In environments with multiple systems, this field is critical for data lineage and troubleshooting. Even in a single-system context, it provides important metadata about the data's origin. Why it matters Provides essential context about the data's origin, which is important for data governance and when integrating data from multiple source systems. Where to get This is typically a static value added during the data extraction process to label the dataset. Examples Salesforce Sales Cloud | |||
Account Name AccountName | The name of the customer or company that placed the sales order. | ||
Description The Account Name identifies the customer associated with the sales order. This allows for process analysis from a customer-centric view. By using this attribute, analysts can filter the process for specific customers, compare process performance across different customer segments, or identify if certain customers consistently experience process issues. It's key to linking process performance directly to customer experience. Why it matters Links process performance to specific customers, enabling customer-specific analysis and segmentation to identify patterns or issues. Where to get The 'Order' object has a lookup field 'AccountId'. This ID must be joined with the 'Account' object to retrieve the 'Account.Name' field. Examples Global Tech Inc.Innovate Solutions LLCVenture Dynamics | |||
Order Status OrderStatus | The status of the sales order at the time of the event. | ||
Description This attribute captures the state of the sales order, such as 'Draft', 'Activated', 'Shipped', or 'Closed'. Status changes are often the source for generating the activities in the process log. Analyzing the order status provides context to each event and is crucial for tracking the progress of an order. It helps in understanding the outcome of cases, for example, identifying orders that were 'Cancelled' versus those that were successfully 'Closed'. Why it matters Provides critical context for each event and is often the basis for defining activities. It is also key to analyzing case outcomes like cancellations. Where to get This is the 'Status' picklist field on the standard Salesforce 'Order' object. Examples DraftActivatedShippedClosedCancelled | |||
Requested Delivery Date RequestedDeliveryDate | The delivery date for the order as requested by the customer. | ||
Description This attribute stores the date when the customer expects to receive their goods. It serves as a critical benchmark for measuring delivery performance and customer satisfaction. This date is used directly in the 'Delivery Date Adherence Tracking' dashboard and the 'On-Time Delivery Rate' KPI. It is compared against the actual delivery date ('Goods Delivered' timestamp) to determine if the order was delivered on time, early, or late. Why it matters This is the primary benchmark for measuring on-time delivery performance, a key indicator of customer satisfaction and operational effectiveness. Where to get This is often a custom date field on the 'Order' object. Its exact name may vary. Consult Salesforce Sales Cloud documentation or schema. Examples 2023-11-152023-12-012024-01-10 | |||
Total Cycle Time CycleTime | The total time elapsed from the creation of the sales order to its final closure. | ||
Description Total Cycle Time is a key performance indicator that measures the end-to-end duration of the sales order process. It is calculated as the time difference between the first event (e.g., 'Order Created') and the last event (e.g., 'Order Closed'). This metric is the primary focus of the 'Sales Order End-to-End Cycle Time' dashboard. Analyzing cycle time helps identify overall process inefficiency and measure the impact of improvement initiatives. Variations in cycle time can be investigated by slicing the data with other attributes like country or product family. Why it matters This is a fundamental KPI for measuring overall process efficiency and identifying long-running orders that may indicate systemic problems. Where to get Calculated during data transformation by subtracting the timestamp of the first event from the timestamp of the last event for each 'SalesOrderId'. Examples 10 days 4 hours25 days 11 hours5 days 2 hours | |||
Total Order Amount TotalOrderAmount | The total monetary value of the sales order. | ||
Description This attribute represents the total financial amount of the customer's order. It is a key metric for understanding the business impact of process efficiencies or inefficiencies. In analysis, the total order amount can be used to segment cases, for instance, to see if high-value orders are processed differently or experience more delays than low-value orders. It is also fundamental for calculating financial KPIs and understanding the value flowing through the process. Why it matters Enables financial analysis of the process, allowing for segmentation of orders by value and quantifying the monetary impact of delays or rework. Where to get This is the 'TotalAmount' field on the standard Salesforce 'Order' object. Examples 5400.50125000.00950.75 | |||
User Performing Action UserPerformingAction | The name of the user or system agent who executed the activity. | ||
Description This attribute identifies the individual responsible for completing a process step. It could be a sales representative, a credit analyst, or an automated system user. Analysis based on this user is vital for understanding workload distribution, individual performance, and automation levels. It helps answer questions like 'Which users handle the most rework?' or 'Are certain teams faster at approvals?'. This is also used in social network analysis to see how work is handed off between individuals. Why it matters Allows for performance analysis by user, team, or role, and helps identify automation opportunities or training needs. Where to get Can be found in fields like 'LastModifiedById' on the 'Order' object or 'OwnerId' on 'Task' records. These IDs would need to be joined with the 'User' object to get the user's name. Examples Alice SmithBob JohnsonSystem AutomationCredit Team | |||
Credit Check Status CreditCheckStatus | The outcome of the credit check process for the order. | ||
Description This attribute indicates the result of the customer's credit evaluation, which is often a critical gate in the order process. Common values include 'Approved', 'Rejected', or 'Pending'. This is essential for the 'Credit Check Bottleneck Analysis' dashboard. By tracking when an order enters and leaves the credit check phase, and its final status, organizations can measure the duration and outcome of this step, identifying it as a potential source of delay. Why it matters Directly supports the analysis of the credit check step, helping to measure its duration, success rate, and impact on overall cycle time. Where to get This is likely a custom field on the 'Order' or 'Account' object. Consult Salesforce Sales Cloud documentation or schema. Examples ApprovedRejectedPending ReviewNot Required | |||
Event End Time EventEndTime | The exact date and time when the activity was completed. | ||
Description The Event End Time marks the completion of an activity. While many process mining tools infer this from the start time of the next activity, explicitly capturing it can provide more accurate activity durations, especially for long-running tasks. This attribute is used to calculate the precise processing time of an activity. It is particularly valuable for analyzing tasks with significant duration, such as 'Credit Check Performed' or 'Inventory Allocated', helping to separate active processing time from idle waiting time. Why it matters It enables the precise calculation of individual activity processing times, which is crucial for identifying bottlenecks and resource-intensive steps. Where to get Can be derived from the 'StartTime' of the subsequent event in the sequence for a given case. For some activities, it might be a specific field like 'Task.CompletedDateTime'. Examples 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Invoice ID InvoiceId | The unique identifier for the invoice associated with the sales order. | ||
Description The Invoice ID links a sales order to its corresponding financial invoice. The creation and sending of this invoice are key milestones in the latter half of the order-to-cash process. This attribute is crucial for tracking the process from order fulfillment to payment. It allows for the precise measurement of the 'Invoice Created' and 'Invoice Sent to Customer' activities, which are needed for calculating the 'Payment Collection Duration'. Why it matters Links the sales order to the invoicing sub-process, enabling accurate tracking of financial activities and payment cycle times. Where to get This is often a custom lookup field on the 'Order' object pointing to a standard or custom 'Invoice' object. The exact implementation varies. Examples INV-001234INV-001235INV-001236 | |||
Is Automated IsAutomated | A flag indicating whether the activity was performed by a system process or a human user. | ||
Description This boolean attribute distinguishes between events triggered by system automation, such as an automated status update, and those performed manually by a user. This is key for understanding the level of automation in the process. Analyzing this attribute helps in quantifying the impact of automation on efficiency and consistency. It allows for a comparison of automated versus manual paths and can highlight opportunities for further automation to reduce manual effort and potential for error. Why it matters Helps distinguish between system and user actions, which is crucial for automation analysis and identifying opportunities to reduce manual work. Where to get Derived during data transformation by checking if the 'UserPerformingAction' is a designated system user or by rules based on the activity type. Examples truefalse | |||
Is On-Time Delivery IsOnTimeDelivery | A flag that indicates whether the goods were delivered on or before the customer's requested delivery date. | ||
Description This boolean attribute is a direct measure of delivery performance against customer expectations. It is calculated by comparing the timestamp of the 'Goods Delivered' activity with the 'RequestedDeliveryDate'. It is the core calculation for the 'On-Time Delivery Rate' KPI. Analyzing this flag helps organizations understand their reliability and adherence to commitments, which is a major driver of customer satisfaction. When combined with other attributes, it can reveal if certain shipping methods or regions have lower on-time rates. Why it matters Provides a clear, binary measure of performance against customer commitments, directly supporting the On-Time Delivery Rate KPI. Where to get Calculated during data transformation. The logic is: IF ('Goods Delivered' EventTime <= 'RequestedDeliveryDate') THEN true ELSE false. Examples truefalse | |||
Is Rework IsRework | A flag indicating if the sales order has undergone rework, such as a repeated activity or a loop in the process. | ||
Description This calculated attribute identifies cases that deviate from a linear, forward progression. Rework occurs when an activity is repeated or when the process loops back to an earlier stage, often due to errors, missing information, or rejected approvals. This flag is used to calculate the 'Sales Order Rework Rate' KPI and power the 'Sales Order Rework and Error Rate' dashboard. It helps quantify the frequency and impact of inefficiencies, pointing to areas that require better quality controls or process clarification. Why it matters Quantifies process inefficiency by flagging orders that require extra, unplanned work, which directly impacts cost and cycle time. Where to get Calculated by process mining software or during data transformation by detecting repeated activity names or backward process flows for a given case. Examples truefalse | |||
Order Owner OrderOwner | The primary user responsible for managing the sales order. | ||
Description The Order Owner is the sales representative or account manager who has primary responsibility for the order. This differs from the user who performs a specific action, as the owner is responsible for the overall progression of the case. Analyzing by owner can help in evaluating team or individual workloads and performance in managing their portfolio of orders. It can highlight which owners have orders that frequently get stuck or require rework, indicating potential coaching opportunities. Why it matters Identifies the person accountable for the order's success, allowing for analysis of workload and performance at the owner level. Where to get This is the 'OwnerId' field on the 'Order' object. This ID can be joined with the 'User' object to get the owner's name. Examples Jane DoeJohn SmithSales Team East | |||
Payment Collection Duration PaymentCollectionDuration | The time elapsed between sending the invoice to the customer and receiving the payment. | ||
Description This calculated metric measures the efficiency of the final, crucial stage of the order-to-cash cycle: getting paid. It is the duration between the 'Invoice Sent to Customer' activity and the 'Payment Received' activity. This attribute directly supports the 'Payment Collection Duration' dashboard and the 'Payment Realization Time' KPI. Analyzing this duration helps the finance department identify bottlenecks in collections, assess the effectiveness of payment terms, and find opportunities to accelerate cash flow. Why it matters Measures the efficiency of the accounts receivable process, directly impacting the company's cash flow. Where to get Calculated during data transformation by subtracting the timestamp of the 'Invoice Sent to Customer' event from the 'Payment Received' event for each case. Examples 30 days15 days 8 hours45 days | |||
Processing Time ProcessingTime | The duration of an individual activity, representing the active work time. | ||
Description Processing time is the time spent actively working on a task, calculated as the difference between an activity's end time and start time. This is distinct from waiting time, which is the idle time between activities. This metric is fundamental for bottleneck analysis, such as for the 'Credit Check Performed' activity. By isolating the active processing time, analysts can determine if delays are caused by inefficient work on the task itself or by long queues before the task begins. Why it matters Isolates the active work time for a specific task, helping to distinguish between inefficient activities and long waiting times. Where to get Calculated during data transformation by subtracting the 'EventTime' (StartTime) from the 'EventEndTime'. Examples 5 minutes2 hours 15 minutes45 seconds | |||
Product Family ProductFamily | The category or family to which the products on the order belong. | ||
Description The Product Family provides a high-level classification of the items included in the sales order. This allows for process analysis based on the type of product being sold. This attribute can be used to segment the process and determine if certain product families have different process paths, longer cycle times, or higher rework rates. For example, complex, configurable products might follow a more elaborate approval and fulfillment process than standard, off-the-shelf items. Why it matters Enables process analysis segmented by product category, revealing if different types of products lead to variations in process efficiency. Where to get Retrieved from the 'Product2' object, which is linked to the 'Order' via the 'OrderItem' junction object. This requires joining Order -> OrderItem -> PricebookEntry -> Product2. Examples HardwareSoftware LicensesProfessional ServicesSupport Contracts | |||
Sales Channel SalesChannel | The channel through which the sales order was placed, such as 'Web', 'Direct Sales', or 'Partner'. | ||
Description The Sales Channel attribute categorizes orders based on their point of origin. This allows for comparative analysis of process performance across different channels. This is essential for the 'Sales Channel Performance Comparison' dashboard. By filtering or comparing by channel, businesses can identify which channels are most efficient, which ones experience the most rework, and where standardization efforts may be needed to align performance. Why it matters Enables performance comparison across different business channels, helping to identify best practices and areas for process harmonization. Where to get This is typically a custom picklist field on the 'Order' or 'Opportunity' object. Consult Salesforce Sales Cloud documentation or schema. Examples Direct SalesWeb PortalPartner NetworkInside Sales | |||
Shipping Country ShippingCountry | The destination country for the sales order shipment. | ||
Description This attribute specifies the country where the order is being shipped. It is a key dimension for geographical analysis of the order-to-cash process. Analyzing by shipping country can reveal regional differences in process performance, such as longer delivery times for international orders or variations in payment collection cycles. It allows for segmentation of the process to understand and address region-specific challenges. Why it matters Enables geographical segmentation of the process, which can highlight regional performance differences, compliance issues, or logistical challenges. Where to get This is the 'ShippingCountry' field on the standard Salesforce 'Order' object. Examples USAGermanyJapanBrazil | |||
Shipping Method ShippingMethod | The method selected for shipping the goods, such as 'Standard Ground', 'Express', or 'International'. | ||
Description This attribute indicates the logistics service level chosen for the order's delivery. It directly impacts delivery timelines and costs. In the 'Shipping Method Efficiency Analysis', this attribute is used to compare the performance of different shipping options. It helps to determine if express shipments are meeting their time commitments and how different methods impact the overall 'Goods Shipped' to 'Goods Delivered' duration. Why it matters Allows for analysis of logistics performance, helping to evaluate the cost and efficiency of different shipping options. Where to get This is likely a custom field on the 'Order' object or on a related custom 'Shipment' object. Consult Salesforce Sales Cloud documentation or schema. Examples Standard Ground2-Day ExpressOvernight AirInternational Priority | |||
Order to Cash - Sales Order Processing Activities
| Activity | Description | ||
|---|---|---|---|
Goods Delivered | Indicates that the shipment has successfully reached the customer. This information is sourced from a shipping carrier's system and updated back into Salesforce. | ||
Why it matters This event is essential for calculating the 'On-Time Delivery Rate' KPI and measuring actual customer-facing cycle times. It confirms the fulfillment process is complete. Where to get Inferred from the population of a 'Delivery Date' field on the 'Order' or custom 'Shipment' object. This data is typically provided via an integration with a shipping logistics provider. Capture Use the timestamp when a delivery date field is populated. Event type inferred | |||
Goods Shipped | Represents the moment the order has been physically dispatched from the warehouse to the customer. This event is almost always captured by an update from an external shipping or ERP system into Salesforce. | ||
Why it matters This is a critical milestone for measuring the 'On-Time Shipping Rate' and overall fulfillment efficiency. It marks the start of the delivery phase of the customer journey. Where to get Inferred from the population of a 'Shipped Date' field or a 'Tracking Number' field on the 'Order' object or a related custom 'Shipment' object. The data originates from a fulfillment system. Capture Use the timestamp when a shipping date or tracking number field is first populated. Event type inferred | |||
Invoice Created | Represents the generation of a financial invoice for the sales order. This can be captured by the creation of a related 'Invoice' object, either natively via Salesforce Billing or through an integration. | ||
Why it matters This milestone marks the beginning of the financial collection part of the process. The time between delivery and invoicing can reveal administrative bottlenecks affecting cash flow. Where to get Inferred from the creation date of an 'Invoice' object (standard or custom) that is linked to the 'Order' object. Capture Use the 'CreatedDate' of the related Invoice record. Event type inferred | |||
Order Activated | A standard Salesforce event signifying the order is finalized and can proceed to fulfillment and invoicing. Activation locks the order from most changes and is captured by a specific status change. | ||
Why it matters Activation is a critical, non-reversible milestone confirming the order's validity. It's the official handoff from sales to operations and is a core component of tracking sales cycle times. Where to get Inferred from the standard 'Status' field on the 'Order' object changing to 'Activated'. The timestamp is recorded in the 'Order' field history tracking. Capture Monitor the 'Order' object's field history for a status change to 'Activated'. Event type inferred | |||
Order Closed | Represents the successful completion and final closure of the sales order in the system. This is inferred from a final status update on the order, indicating no further action is needed. | ||
Why it matters This is the primary 'happy path' end event for the process. Measuring the total time to this activity provides the 'Average Order to Close Time' KPI. Where to get Inferred from a change in the 'Order' object's 'Status' field to a final value like 'Closed', 'Completed', or 'Fulfilled'. The timestamp is available via field history tracking. Capture Monitor the 'Order' object's field history for a change to a final, completed status. Event type inferred | |||
Order Created | Marks the initial creation of a sales order record in the system. This event is captured explicitly when a new 'Order' object instance is saved in Salesforce for the first time. | ||
Why it matters This is the primary start event for the Order to Cash process. Analyzing the time from this point to subsequent activities is crucial for understanding overall cycle times. Where to get The creation event of the 'Order' object. The timestamp is the value in the standard 'CreatedDate' field on the Order record. Capture Directly from the 'Order' object's 'CreatedDate' timestamp. Event type explicit | |||
Payment Received | Marks the confirmation that the customer's payment has been received and reconciled. This information is updated from a financial system into Salesforce, typically as a status change. | ||
Why it matters This event is the final step in realizing cash from the sale. Analyzing the time from 'Invoice Sent' to this point is critical for managing cash flow and days sales outstanding (DSO). Where to get Inferred from a status change on the 'Invoice' object to 'Paid' or 'Closed'. The update is driven by an integration with an accounting or payment processing system. Capture Track status changes on the 'Invoice' object from an external finance system integration. Event type inferred | |||
Credit Check Performed | Represents the completion of a creditworthiness check for the customer associated with the order. This is often an inferred event, captured when a custom field, such as 'Credit Check Status', is updated to 'Passed' or 'Completed'. | ||
Why it matters This activity is often a source of significant delays. Measuring its duration and waiting time is key to addressing the 'Credit Check Bottleneck Analysis' dashboard and improving cash flow. Where to get Inferred from a timestamp or status change in a custom field on the 'Order' or related 'Account' object, for example, 'Credit_Check_Date__c' or 'Credit_Status__c'. Capture Track updates to custom fields that signify the completion of the credit check. Event type inferred | |||
Inventory Allocated | Indicates that the products on the order have been reserved in the inventory system. This event typically originates in an external ERP or inventory system and updates Salesforce, captured via a field change. | ||
Why it matters This activity is crucial for analyzing the 'Inventory Allocation Lead Time' KPI. Delays here directly impact the ability to ship orders on time. Where to get Requires system analysis. Often inferred from a status update on the 'Order' or 'OrderItem' objects, or the population of a custom 'Allocation_Date__c' field, driven by an integration. Capture Track status or date field changes on Order or OrderItem objects from an ERP integration. Event type inferred | |||
Invoice Sent to Customer | Indicates that the invoice has been dispatched to the customer for payment. This is typically captured as a status change on the invoice record. | ||
Why it matters This is the trigger event for the 'Payment Realization Time' KPI. Any delay between invoice creation and sending directly postpones the start of the payment term. Where to get Inferred from a status change on the 'Invoice' object to 'Sent' or a similar value. An activity log entry for the sent email could also be used. Capture Monitor the 'Status' field on the related 'Invoice' object or look for email log activities. Event type inferred | |||
Order Approved | Indicates that the sales order has been formally approved by all required parties and can proceed to the next stage. This is captured by observing the final approval step in a workflow or a corresponding status update. | ||
Why it matters This is a key milestone that unlocks the fulfillment process. Delays in approval can significantly impact the overall order-to-cash cycle time. Where to get Inferred from a status field change on the 'Order' object to a value like 'Approved'. This can also be derived from the completion date of the associated 'ProcessInstance' record. Capture Monitor the 'Status' field on the 'Order' object or the completion of the approval process history. Event type inferred | |||
Order Cancelled | Indicates that the order was cancelled before fulfillment was completed. This is captured by a terminal status change on the order record. | ||
Why it matters This is a critical exception and end event. Analyzing why and when orders are cancelled can reveal issues in the sales process, product availability, or customer credit. Where to get Inferred from a change in the 'Order' object's 'Status' field to 'Cancelled'. The timestamp can be found in the field history for the 'Status' field. Capture Monitor the 'Order' object's field history for a change to a 'Cancelled' status. Event type inferred | |||
Order Sent to Fulfillment | Marks the handoff of the activated order to a warehouse or fulfillment system for picking and packing. This is usually captured by a status change on the order, triggered by an integration. | ||
Why it matters This event separates the commercial and logistical parts of the process. Tracking time from activation to this point helps isolate administrative delays from warehouse processing delays. Where to get Inferred from a change in the 'Order' status to a value like 'Sent to Fulfillment' or 'Awaiting Shipment'. This status change is often triggered by an integration with an ERP/WMS. Capture Monitor the 'Status' field on the 'Order' object for specific values indicating a fulfillment handoff. Event type inferred | |||
Order Submitted for Approval | Represents the point where a draft order is submitted into a formal approval workflow. This is typically inferred from a status change on the order or the creation of a record in Salesforce's approval process history. | ||
Why it matters Tracking submissions helps measure the time orders spend waiting for approval and the efficiency of the review process itself. It highlights pre-approval bottlenecks. Where to get Inferred from a status change on the 'Order' object (e.g., from 'Draft' to 'Submitted for Approval') or by tracking the submission date in the 'ProcessInstance' object related to the order. Capture Track status field changes or query the 'ProcessInstance' object. Event type inferred | |||
Extraction Guides
Steps
- Prerequisite: Configure Field History Tracking: Before creating reports, a Salesforce Administrator must ensure that Field History Tracking is enabled for the
Orderobject. Specifically, track theStatusfield and any custom fields used to signify events, such asCredit_Check_Status__corFulfillment_Status__c. This is done inSetup > Object Manager > Order > Fields & Relationships > Set History Tracking. - Create a Custom Report Type: To access field change data alongside order details, create a custom report type. Navigate to
Setup > Report Types. Create a new report type withOrdersas the Primary Object. Then, relateOrder Historyas a secondary object. Ensure the relationship is set to "'A' records may or may not have related 'B' records." This allows you to report on all orders, even those with no history yet. Save this report type as "Orders with History". - Create the Main 'Events' Report: Navigate to the
Reportstab and clickNew Report. Select your "Orders with History" report type. This report will capture all activities that are based on field changes. - Configure the Events Report Columns: Add the following columns:
Order: Order Number(for SalesOrderId),Edit Date(for EventTime),User(for UserPerformingAction),Field/Event(the field that was changed),Original Value, andNew Value. Add other columns from the parent Order object likeOrder: Total Amount,Account: Account Name, andOrder: Company Authorized By Date(as a proxy for RequestedDeliveryDate if applicable). - Filter the Events Report: Set the
Show Mefilter toAll ordersand theDate FieldtoCreated Datewith your desired range (e.g., Last 3 Months). Add a filter to theField/Eventcolumn to only include the specific field changes that correspond to your activities (e.g.,Status,Credit_Check_Status__c). - Create the 'Order Created' Report: Create a second, simpler report using the standard
Ordersreport type. The goal of this report is to capture only the creation event. Add columns forOrder Number,Created Date,Created By,Status,Total Amount, andAccount Name. Filter byCreated Datefor your desired time range. - Export Both Reports: Run both reports and use the
Exportoption. Choose the formatDetails OnlyandComma Delimited .csv. - Combine and Transform Data: Open the exported CSV files in a spreadsheet program like Microsoft Excel or use a scripting language like Python.
- For the 'Events' report, create a new
ActivityNamecolumn. Use formulas or a script to map the field change data to the desired activity names. For example, ifField/Eventis 'Status' andNew Valueis 'Activated', setActivityNameto 'Order Activated'. - For the 'Order Created' report, add a new column named
ActivityNameand set its value to 'Order Created' for all rows. Rename the columns to match the event log schema (e.g.,Order Number->SalesOrderId,Created Date->EventTime).
- For the 'Events' report, create a new
- Merge into a Single Event Log: Append the rows from the transformed 'Order Created' data to the transformed 'Events' data. This creates a single, unified list of all activities.
- Finalize for Upload: Add the remaining required columns:
SourceSystem(with a static value of 'Salesforce Sales Cloud') andLastDataUpdate(with the current timestamp). Review all column headers and data formats before saving the final file as a CSV, ready for upload.
Configuration
- Report Types: A custom report type joining
OrdersandOrder Historyis essential for capturing status changes and other field updates as distinct events. - Field History Tracking: This entire method depends on enabling field history tracking for the
Orderobject before data extraction begins. Key fields likeStatusand any custom fields representing process steps must be tracked. - Date Range Filters: Use the
Created Dateon theOrderobject as the primary filter to ensure you are analyzing a consistent cohort of orders. A range of 3-6 months is recommended for initial analysis. - Data Export Service: As an alternative for high-volume environments, the Data Export Service can be scheduled (weekly or monthly) to export all data for specified objects (
Order,OrderHistory,Account). This provides raw data that requires more significant external processing and joining but avoids the timeouts and row limits of the interactive Report Builder. - Permissions: Users running the extraction need permissions to
Run Reports,Export Reports, andView All Datafor theOrderandAccountobjects. Configuring the Data Export Service requiresSystem Administratorprivileges. - Report Structure: Reports should be set to
Tabular Formatfor the easiest export and processing. Avoid summary or matrix formats.
a Sample Query config
/*
Salesforce Reports are configured through the user interface. This section describes the configuration of the necessary reports and the logic for post-processing. It is not an executable script.
*/
// ======== REPORT 1: Order Creation Events ========
{
"ReportName": "O2C - Order Created",
"ReportType": "Orders",
"Format": "Tabular",
"Filters": [
{
"Field": "Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
}
],
"Columns": [
{"SourceField": "Order Number", "OutputAs": "SalesOrderId"},
{"StaticValue": "Order Created", "OutputAs": "ActivityName"},
{"SourceField": 'Created Date', "OutputAs": "EventTime"},
{"SourceField": "Last Modified By: Full Name", "OutputAs": "UserPerformingAction"},
{"SourceField": "Status", "OutputAs": "OrderStatus"},
{"SourceField": "Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"},
{"SourceField": "[Your Requested Delivery Date Field]", "OutputAs": "RequestedDeliveryDate"}
]
}
// ======== REPORT 2: Order Field Change Events ========
{
"ReportName": "O2C - Order History Events",
"ReportType": "Orders with History (Custom)",
"Format": "Tabular",
"Filters": [
{
"Field": "Order: Created Date",
"Operator": "equals",
"Value": "[Specify Date Range, e.g., LAST 90 DAYS]"
},
{
"Field": "Field/Event",
"Operator": "in",
"Value": ["Status", "[Credit Check Status Field]", "[Inventory Status Field]", "[Fulfillment Status Field]", "[Shipping Status Field]", "[Delivery Status Field]", "[Invoice Status Field]", "[Payment Status Field]"]
}
],
"Columns": [
{"SourceField": "Order: Order Number", "OutputAs": "SalesOrderId"},
{"SourceField": "Edit Date", "OutputAs": "EventTime"},
{"SourceField": "User", "OutputAs": "UserPerformingAction"},
{"SourceField": "Field/Event", "OutputAs": "SourceFieldForActivity"},
{"SourceField": "New Value", "OutputAs": "SourceValueForActivity"},
{"SourceField": "Order: Total Amount", "OutputAs": "TotalOrderAmount"},
{"SourceField": "Account: Account Name", "OutputAs": "AccountName"}
]
}
// ======== EXTERNAL TRANSFORMATION LOGIC (to be applied after export) ========
/*
- Combine the two exported files.
- For the 'Order History Events' data, create the 'ActivityName' and 'OrderStatus' columns based on the following mapping logic:
CASE
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Submitted' THEN 'Order Submitted for Approval'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Approved' THEN 'Order Approved'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Activated' THEN 'Order Activated'
WHEN SourceFieldForActivity = '[Fulfillment Status Field]' AND SourceValueForActivity = 'Sent to Fulfillment' THEN 'Order Sent to Fulfillment'
WHEN SourceFieldForActivity = '[Shipping Status Field]' AND SourceValueForActivity = 'Shipped' THEN 'Goods Shipped'
WHEN SourceFieldForActivity = '[Delivery Status Field]' AND SourceValueForActivity = 'Delivered' THEN 'Goods Delivered'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Closed' THEN 'Order Closed'
WHEN SourceFieldForActivity = 'Status' AND SourceValueForActivity = 'Cancelled' THEN 'Order Cancelled'
WHEN SourceFieldForActivity = '[Credit Check Status Field]' AND SourceValueForActivity = 'Passed' THEN 'Credit Check Performed'
WHEN SourceFieldForActivity = '[Inventory Status Field]' AND SourceValueForActivity = 'Allocated' THEN 'Inventory Allocated'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Created' THEN 'Invoice Created'
WHEN SourceFieldForActivity = '[Invoice Status Field]' AND SourceValueForActivity = 'Sent' THEN 'Invoice Sent to Customer'
WHEN SourceFieldForActivity = '[Payment Status Field]' AND SourceValueForActivity = 'Received' THEN 'Payment Received'
ELSE 'Unknown'
END AS ActivityName
- The OrderStatus attribute should be populated with the 'New Value' when the changed field was 'Status'. For other events, you may need to look up the order's status at that point in time, which is a limitation of this method.
- Add 'SourceSystem' and 'LastDataUpdate' columns to the final combined dataset.
*/