Salesforce Case-to-Work-Order Testing
Salesforce case-to-work-order testing validates the handoff from a service agent to the field. It proves that when a case needs an on-site visit, the work order is created with the right work type, line items, asset, location, entitlement and required skills, lands in the correct service territory, and produces a service appointment that is genuinely ready to schedule and dispatch.
Part of SyntraFlow's Salesforce business process testing practice. Field Service journeys are on the active roadmap and available for proof-of-concept engagements.
The handoff between service and field
Many support cases can be resolved remotely. The ones that cannot become work orders: a boiler that needs a technician, a network device that must be replaced, an installation that has to be booked. In Salesforce Field Service, that transition usually happens through a quick action, a guided Flow or automation on the case, and it creates a WorkOrder linked back to the case, copying the account, contact, asset and address. The work type chosen at this moment determines estimated duration, required skills and whether a service appointment is created automatically.
If this handoff is wrong, everything downstream is wrong too. A missing skill requirement lets the scheduler send an unqualified technician; a wrong address puts the job in another territory; missing products required means the technician arrives without parts. This page owns the conversion from case to dispatch-ready work. Choosing the slot and technician is covered on appointment scheduling testing, and the case lifecycle before the handoff is covered on case-to-resolution testing.
Records created or inherited at conversion
A case-to-work-order test asserts a small graph of records, not a single field.
| Record | Source | What must be right |
|---|---|---|
| WorkOrder | Created from the case | Case link, account, contact, asset, priority, subject and status. |
| Work type | Selected by agent or derived by automation | Duration, duration type and auto-create appointment setting. |
| Skill requirements | Inherited from the work type or added | Skills and minimum skill levels the job demands. |
| WorkOrderLineItem | Added per task or asset | Each line's work type, asset and status for multi-task visits. |
| Products required | Inherited from the work type or added | Parts and quantities the technician must carry. |
| Location and address | From the asset, account or case | Geocoded address inside the intended service territory. |
| Entitlement and service contract | From the asset or account | The SLA and coverage that apply to the field visit. |
| ServiceAppointment | Auto-created or created by action | Earliest start, due date, duration and parent record. |
The happy path from case to dispatch-ready
SyntraFlow can be configured to drive the handoff as the service agent and then inspect the result as the dispatcher would see it.
Start from a qualified case
A case exists for an account with an installed asset, a valid entitlement and a service address, and remote troubleshooting has been recorded.
Create the work order from the case
The agent uses the configured quick action or Flow; the test confirms the work order links to the case and copies account, contact, asset and address.
Apply the work type
The correct work type is selected or derived from the asset and problem code, and duration, skill requirements and products required populate from it.
Add line items for multi-task visits
Where the job has several tasks, work order line items are created with their own work types and assets, and totals roll up as designed.
Resolve territory and entitlement
The address geocodes into the expected service territory, and the entitlement from the asset or contract attaches with its milestones.
Generate the service appointment
An appointment is created with the right parent, earliest start and due date, in a status the dispatcher can schedule.
Reflect status back on the case
The case shows the linked work order and updates its status or sub-status so the agent and customer know a visit is pending.
Failure modes worth a scenario each
These breaks do not stop the work order from saving, which is why they reach technicians before anyone notices.
Work type without skills
A work type edited or cloned without its skill requirements lets the scheduler offer any technician in the territory.
Address outside every territory
A new postcode or an ungeocoded address leaves the work order with no territory, so it never appears on a dispatcher's board.
Duplicate appointments
Auto-create on the work type plus a Flow that also creates an appointment produces two appointments for one visit.
Asset from the wrong account
A lookup filter gap lets an agent attach an asset belonging to another customer, carrying the wrong entitlement.
Expired coverage not flagged
A visit for an asset past its warranty should follow the billable path, not silently inherit an expired entitlement.
Case and work order out of sync
Cancelling the work order leaves the case in a pending-visit status indefinitely.
Roles on each side of the handoff
Three personas touch this process with different access. The contact-center agent needs create access to work orders and read access to assets, work types and entitlements, but usually not to scheduling policies or resource data. The dispatcher needs to see the resulting work orders and appointments for their territories only, which is typically enforced through territory-based sharing. The field technician eventually sees the job on the mobile app with the line items and products required. A handoff that works for an administrator can fail for an agent lacking a Field Service permission set license, or produce work a dispatcher in the correct territory cannot see.
Running the conversion as the agent and then reading the result as the territory's dispatcher and a dispatcher from a different territory is the simplest way to catch both problems. Where contractors or partners dispatch their own crews, the sharing boundary deserves explicit negative checks drawing on sharing rule testing.
Test data the handoff depends on
Case-to-work-order tests fail for data reasons more often than configuration reasons, so these prerequisites should be declared and seeded:
- Accounts with installed assets whose product, serial number and install date are set.
- Assets both in and out of warranty, with service contracts and entitlements attached accordingly.
- Work types for each common job, with skill requirements and products required defined.
- Service territories with polygon or address coverage that includes each test address.
- Addresses with geolocation populated, plus one deliberately outside all territories.
- Problem codes or case reasons that drive work type selection in automation.
- Price book entries for billable parts where the visit is not covered.
Suggested case-to-work-order scenarios
A focused pack that proves the work order is complete and dispatchable before any scheduling happens.
| Scenario | What it proves |
|---|---|
| Covered repair from case | Work order, entitlement, skills and appointment are correct for an in-warranty asset. |
| Billable visit out of warranty | Expired coverage is detected and the billable path applies. |
| Multi-task visit | Line items carry their own work types and roll up duration and products. |
| Address outside territories | The gap is flagged rather than creating an unroutable work order. |
| Work type drives auto-create | Exactly one service appointment is created with the right dates. |
| Cancelled work order | The case status reverts or updates so it is not stuck pending. |
| Dispatcher visibility by territory | Only the owning territory's dispatcher sees the new work. |
Evidence and the wider field journey
Evidence from a run should show the originating case, the created work order and line items, the work type and inherited skills and products, the resolved territory and entitlement, and the service appointment with its dates and status. SyntraFlow is designed to capture that graph per scenario, which lets a Field Service lead confirm dispatch readiness without opening each record.
Case-to-work-order is the first leg of a longer journey that runs through scheduling, on-site completion and often into billing or an ERP for parts and invoicing. Testing each leg separately keeps failures easy to locate, while chaining them into one end-to-end scenario proves the customer's visit actually happens. The broader surface is covered on Field Service testing.
Related pages
Business process testing
The hub for outcome-led Salesforce process testing this page belongs to.
Appointment scheduling testing
The next leg: booking the service appointment this handoff creates.
Service completion testing
On-site completion, parts and labor capture after the visit is dispatched.
Case-to-resolution testing
The support lifecycle that precedes and follows the field visit.
Entitlement testing
The coverage and SLA model a work order inherits from assets and contracts.
Field Service testing
The wider Field Service surface behind work types, territories and mobile.
Case-to-Work-Order testing FAQs
What is Salesforce case-to-work-order testing?
It is validation of the handoff from a Service Cloud case to a Field Service work order. Tests confirm the work order is created with the correct links, work type, line items, skills, products required, territory and entitlement, and that a schedulable service appointment results.
Why test the handoff separately from scheduling?
Because scheduling can only be as correct as its inputs. If skills, duration or territory are wrong on the work order, the scheduler will make a valid-looking but wrong decision. Testing the handoff first isolates data and configuration defects from scheduling logic defects.
What role does the work type play?
The work type sets estimated duration, required skills, products required and whether a service appointment is created automatically. A work type edited without its skill requirements or with a changed duration affects every future work order that uses it, so it deserves direct assertions.
How are warranty and entitlement checked?
Scenarios use assets both inside and outside their coverage period. The in-warranty case should attach the right entitlement and milestones, while the expired case should follow the billable path. Entitlement configuration itself is covered in more depth on the entitlement testing page.
Which users should run these tests?
The service agent who creates the work order, the dispatcher for the owning territory, and a dispatcher from a different territory as a negative check. This confirms both that agents have the permissions they need and that territory sharing keeps work visible only where it belongs.
Is case-to-work-order testing available today?
SyntraFlow is Oracle-native and expanding into Salesforce. Field Service journeys, including case-to-work-order, are on the active roadmap and available for proof-of-concept engagements, with scope confirmed per org.
Send the right technician with the right parts
See how SyntraFlow is designed to prove every case-to-work-order handoff is complete and ready to dispatch.