Salesforce Service Completion Testing
Salesforce service completion testing validates what happens when a technician finishes a job in Field Service — the service appointment and work order moving to completed, parts consumed and inventory decremented, labor and time captured, a signed service report produced, and the close-out feeding billing, asset history and reporting. It proves that finished work is recorded accurately enough to invoice, restock and measure.
Field Service journeys, including service completion, are on the active roadmap and available for proof-of-concept engagements.
What service completion covers
Service completion is the last mile of a Field Service journey. By this point, a case has become a work order through case-to-work-order testing, and a service appointment has been scheduled and dispatched through appointment scheduling testing. Completion is what the technician does on site and immediately after: updating the ServiceAppointment status through the allowed transitions, recording ProductConsumed against the van stock ProductItem, logging time on TimeSheetEntry records, completing any mobile flows or checklists, capturing a customer signature, and generating a ServiceReport.
Behind those actions sit status transition rules, record-triggered Flows, lifecycle management of the WorkOrder and WorkOrderLineItem, inventory transactions, and often integrations that send completed work to an ERP or billing system. Most of this is performed in the Field Service mobile app, frequently offline, which means completion data may reach Salesforce minutes or hours after the technician taps Complete.
Testing service completion as a process confirms that all of these records are consistent with each other and with what actually happened on site.
Why close-out defects are expensive
A completion defect rarely stops the technician. It surfaces later, as unbilled work, phantom inventory or a customer disputing a report.
Unbilled work
The appointment completes but the work order status never updates, so the integration that sends completed work to billing never fires.
Inventory drift
Parts are consumed from the wrong location or quantity-on-hand is not decremented, and van stock replenishment goes wrong.
Offline sync conflicts
A technician completes work offline while a dispatcher edits the same appointment, and one set of changes is lost on sync.
Invalid status transitions
A technician can move straight from Dispatched to Completed, skipping travel and on-site timestamps that SLA and utilization reporting depend on.
Incomplete service reports
The report template omits consumed parts or the signature, so the customer receives a document that does not match the invoice.
Stale asset history
The asset's last service date and maintenance plan are not updated, so the next preventive visit is generated on the wrong date.
The completion happy path
SyntraFlow is designed to run completion as the technician and then verify the resulting records as the dispatcher, service manager and billing user would see them.
Start from a dispatched appointment
Seed a work order with line items, a scheduled and dispatched service appointment, an assigned resource and van stock at a known quantity.
Travel and on-site statuses
Move the appointment through the configured transitions such as In Progress, asserting actual start time and that disallowed transitions are blocked.
Record parts and labor
Add ProductConsumed records against the technician's location and log time entries, asserting quantity-on-hand and ProductItemTransaction records update.
Complete checklists and capture signature
Complete required mobile flows or checklist steps, capture the customer signature, and generate the service report.
Complete the appointment and work order
Set the appointment to Completed and confirm actual end time, work order line item and work order statuses roll up as configured.
Verify downstream close-out
Confirm the related case closes or updates, asset and maintenance plan dates change, and completed work is marked ready for billing or sent to the ERP.
Records to reconcile at close-out
A completed job should leave a consistent set of records. These are the checks that prove they agree.
| Record | What completion should change | Consistency check |
|---|---|---|
| ServiceAppointment | Status Completed with actual start and end times | Actual times fall within the scheduled window or are flagged |
| WorkOrder and WorkOrderLineItem | Line items and parent completed or closed per rules | No open line items remain on a completed work order unless designed |
| ProductConsumed | One record per part used with quantity and source location | Consumed quantity equals the reduction in ProductItem quantity-on-hand |
| TimeSheet and TimeSheetEntry | Labor recorded against the work order | Total labor aligns with appointment duration within tolerance |
| ServiceReport | Report generated with signature attached | Parts, labor and notes match the underlying records |
| Asset and MaintenancePlan | Last service date and next suggested maintenance date updated | Next preventive work order is generated for the right date |
| Case or billing record | Case resolved; work marked billable or sent downstream | Every billable line has a corresponding billing entry |
Exception paths worth exercising
Field work rarely ends cleanly. These branches are where completion data most often goes wrong.
- Cannot Complete: the technician marks the appointment incomplete, confirming a follow-up appointment or work order is created and no billing is triggered.
- Consuming a part not held in the technician's van stock, confirming the configured behavior — block, warn or allow negative stock.
- Returning an unused part after consumption was recorded, confirming inventory and billing are both corrected.
- Completing entirely offline and syncing later, including a conflicting dispatcher edit made in the meantime.
- A customer declining to sign, confirming the report and status still follow the business rule for unsigned work.
- A multi-day job with several appointments on one work order, confirming the work order completes only when all appointments are done.
- A warranty or entitlement-covered job, confirming the work is marked non-billable, consistent with entitlement testing.
Roles, mobile context and test data
Completion involves several roles with different access. The field technician works in the mobile app with a Field Service Mobile permission set and limited record access; the dispatcher monitors the Dispatcher Console; the service manager reviews completed work; and a billing or finance user picks up billable work. Running the same completion under each role confirms, for instance, that a technician cannot edit consumed parts after the report is signed while a manager can correct them.
Because most completion happens on mobile devices, tests should cover both the online path and the offline sync path, and should consider the mobile app's briefcase and priming settings that determine which records are available offline. Test data must include service territories, service resources with inventory locations, product items with known quantities, work types, maintenance plans and assets. Seeding and resetting those records between runs is part of service cloud test data.
Suggested test scenarios
A representative set covering the clean close-out and its most common variations.
| Scenario | What it proves |
|---|---|
| Standard break-fix completion | Statuses, parts, labor and report agree and work reaches billing |
| Cannot complete with follow-up | Incomplete work creates a follow-up and is not billed |
| Offline completion and sync | Completion data survives offline capture and conflict handling |
| Part return after consumption | Inventory and billing are both corrected |
| Preventive maintenance visit | Asset history and next maintenance date update correctly |
| Warranty-covered job | Entitled work is completed as non-billable |
| Multi-appointment work order | Work order completes only when all appointments finish |
Evidence and the handoff beyond Salesforce
A complete run is designed to capture each status transition with timestamps, the parts and labor records, inventory quantities before and after, the generated service report, and the downstream case, asset and billing state. Service operations and finance can use that evidence to confirm that completed work is fully accounted for.
Where completed work flows into an ERP for invoicing, parts costing or inventory replenishment, the same scenario can continue across that boundary, following the pattern in Salesforce to ERP order testing. Broader coverage of dispatch, scheduling optimization and the mobile app is on the Field Service testing page.
Related pages
Business Processes
The full library of Salesforce business process tests service completion belongs to.
Case-to-Work-Order Testing
How the work order that is completed here is created from a case.
Appointment Scheduling Testing
Scheduling and dispatch of the appointment before the technician arrives.
Field Service Testing
Broader coverage of Field Service configuration, dispatch and mobile.
Service Cloud Test Data
Seeding territories, resources, inventory and assets for service tests.
Case-to-Resolution Testing
The service case journey that completed field work often closes.
Service Completion testing FAQs
What is Salesforce service completion testing?
It is testing the Field Service close-out process: moving service appointments and work orders to completed, recording parts consumed and labor, capturing signatures and service reports, and updating cases, assets and billing. Tests confirm that all of these records agree and reflect the work actually done.
How is this different from appointment scheduling testing?
Appointment scheduling testing covers finding a slot, assigning a resource and dispatching the appointment. Service completion testing begins once the technician is working the job and ends when the work is recorded, reported and handed to billing. The two chain together in a full Field Service journey.
Why test offline completion separately?
Technicians often work without connectivity, and the mobile app syncs changes later. Sync can surface conflicts with dispatcher edits, validation errors that were not visible offline, or records missing from the offline data set. Testing the offline path confirms completion data is not lost or rejected on sync.
How is inventory accuracy verified?
By recording the product item quantity-on-hand before the job, consuming known quantities during completion, and asserting both the product consumed records and the resulting quantity and transaction records. Return scenarios confirm the reverse movement is handled correctly.
Can service completion tests continue into billing or an ERP?
Yes, where completed work is sent downstream. The same scenario can be extended to read the billing or ERP record and reconcile billable lines against the parts and labor captured in Salesforce, following the cross-system pattern used for order handoffs.
Is service completion testing available in SyntraFlow today?
Field Service journeys, including service completion, are on the active roadmap and available for proof-of-concept engagements. The completion flows, mobile scenarios and downstream systems in scope are confirmed per engagement.
Make every finished job billable and accurate
Map your Field Service close-out, from technician completion to billing, to a repeatable end-to-end test.