A service-order checklist is the structured inspection record of the job: what was checked, what was found, in what condition. Checklists are template-driven — an administrator authors a checklist template once, and Perform Populate Checklist on any service order instantiates that template's lines against the order as checklist line records for the technician to complete. The same template mechanism serves goods receipts, deliveries, shipments and inspections; the template's type decides which document family it fires on.
Prerequisites
- At least one checklist template whose Type is exactly Service Order, with template lines. Populating an order does nothing without one.
- The Service Order value present in the template Type picklist. The server matches the type text literally — one fixed value per document family: Goods Receipt, Delivery, Shipment, Service Order and Inspection. The shipped picklist offers Inspection, Health Check, Claim, Merchandising Audit and Product Demo, and tenants commonly reshape it (the demo tenant's reads Claim, Training, Generic, Delivery and Training Repository) — neither set includes Service Order, so an administrator has to add that value through the entity's picklist values before a template can be authored for service orders.
- Authoring templates needs the Checklist Template entity, which the shipped configuration places in the Field Sales Setup app (your administrator may surface it in other apps); completing checklists needs only the service order and its checklist lines.
Procedure
Start in the Checklist Templates list (Field Sales Setup app → Checklist Templates, or /ChecklistTemplate). The register shows each template's name, type, partner account, item, effective dates and active flag. Filter by Type before editing so a generic, training or delivery template is not mistaken for the Service Order template you intend to populate. Open a row from the Name column to inspect its saved lines; presence in the list does not prove the template contains usable checks.
- 1
Name and Code identify the template for administrators; no integration contract is implied by this form alone.
- 2
Is Active records administrative state, but the current Populate selector does not filter on it.
- 3
Type selects the document family, such as Service Order, whose populate action instantiates the template.
- 4
Frequency documents intended cadence; it does not prevent repeated Populate runs from creating duplicates.
- 5
Save creates the template header only; add the template lines on the saved record's Related tab, then switch Is Active on once the structure is complete.
The template header identifies the template (Name, Code), its target document Type, Frequency, Parent Checklist, Item and Is Active. In the current server implementation, Populate selects template lines by Type only: it does not check the active flag, the from/to dates or the frequency, and it does not deduplicate a previous run. Treat those header fields as administrative metadata unless your tenant adds a business rule around them, and run Populate once per intended checklist instance.
Step 1 — Author the template (administrator, once)
Create the checklist template with Type Service Order and add one template line per check. Each line defines:
| Setting | What it does |
|---|---|
| Label and name | The check as the technician reads it |
| Data type | The answer the line takes: Text, Numeric, Decimal, Boolean, Date, Time, DateTime, Currency, Picklist, RAG, URL, Email, Phone or Take Picture |
| Is mandatory | Marks the check as required for users and reporting; the server does not block an unanswered line, and the shipped web checklist widget only marks it with an asterisk |
| Picklist values | Fixed answer choices, where the check offers them |
| Default value, length | A pre-filled answer and a maximum length for text answers |
| Dependent answer, parent template line | Chains a line to a parent line's answer |
| Group by | Groups related checks so they render together |
| Sequence number | The order lines are presented in |
| Colour code, reading, value | The RAG scale definition for condition checks (Red, Amber, Green) |
| Target entity name, target entity field, target group key | Advanced: a line that spawns a named related record instead of a plain answer line |
The saved template's Related tab is the line inventory: every row names a concrete check and its Data Type, and New introduces another line. Review this list before running Populate on an order — the header selects the document family, but these child rows are the checks the action instantiates. A mixture of Boolean and Picklist lines, as in the demo template (a Generic-type claim checklist), shows how each data type becomes a different technician input.
- 1
Type is the only header field Populate reads; it must be exactly Service Order for a template to fire on service orders.
- 2
From Date and To Date document the intended validity window; nothing in the populate path filters on them today.
- 3
Frequency (Once here) is descriptive — it does not stop a second Populate run from creating a second set of lines.
- 4
Is Active records administrative state; an inactive template of the matching Type is still instantiated.
- 5
Other Details scope the template to a partner account, account or account group for field-sales use; service-order population ignores this scoping.
Use Details to verify the saved header once the lines are right. Basic Details — Name, Item, Type, From Date, To Date, Frequency and Is Active — describe the template's administrative envelope; Other Details scope it to a partner account, account or account group (used by field-sales visit checklists, ignored by service-order population); System Information carries the audit trail. Remember that population keys on Type alone — the envelope shown here is governance evidence, not a runtime filter.
Step 2 — Populate the checklist on the order
On the service order, run Perform Populate Checklist. One checklist line is created per ordinary template line, attached to this order, carrying the template line's identity, label, data type and group key. Lines with a target entity are grouped by target entity and group key and create one related record per group against the order instead of a plain checklist line; a target that cannot be resolved is skipped silently. Population does not look for an earlier instance, so a second run creates a second full set.
Step 3 — Complete the checks
The populated lines are Checklist Line records linked to the order. Work through them, filling the answer field that matches each line's data type — text, numeric or decimal values, booleans, dates and times, currency amounts, or the RAG value for condition checks (Red, Amber, Green). The shipped service-order layout does not embed a checklist answering widget (the platform's widget is wired on goods-receipt and delivery layouts), so complete the lines through the Checklist Line records — their list, a related list on the order, or a layout your administrator adds — or through the mobile app's checklist form. Treat lines marked mandatory as an operating requirement and verify them before completing the job; the server does not enforce the flag as a save-time gate.
Step 4 — Let the findings drive follow-up work
RAG and threshold answers are not just a record: service recommendation rules watch checklist results. A rule names a checklist template line and the RAG value or numeric bounds that trigger it, plus the item, quantity and recommendation type to recommend (the quantity is copied onto the recommendation, and a later re-sync of the checklist leaves a quantity someone has edited alone); when a checklist line is saved or updated, matching rules raise service recommendations against the order's asset, with the trail back to the checklist line that caused them. A red suspension check can therefore surface a recommended replacement part on this order or the next visit. On update, recommendations whose rule no longer matches are removed again unless they have already been utilised.
A rule matches in exactly one of five shapes, so author it in one shape only: a RAG value with no numeric bounds matches an equal RAG answer; a greater-than bound alone matches a numeric answer above it; a less-than bound alone matches a numeric answer below it; both bounds together match an answer strictly between them; and a rule with no RAG value and no bounds matches any Text line that has an answer. A rule mixing a RAG value with numeric bounds never matches.
Expected result
The service order carries the expected checklist lines in the correct data types, and the team has reviewed every mandatory answer before completing the job. RAG, numeric or text answers that meet a recommendation rule create linked follow-up recommendations. Because Populate is intentionally not idempotent, verify that it was run once for this inspection before interpreting duplicate findings or recommendations.
Common problems
Populate did nothing. No checklist template line belongs to a template whose Type is exactly Service Order. The action instantiates matching lines — it cannot invent checks. If the Type picklist does not offer Service Order, add the value first; a template typed Generic, Training or Health Check is never selected for a service order.
The same checks appear twice. Populate was run more than once — each run instantiates the template's lines again. Populate once per order; remove the duplicates if a second run happened.
An expected follow-up recommendation never appeared. Recommendation rules are separate records from the template — check a rule exists for that template line, that it is authored in one shape, and that the answer actually crossed the rule's RAG value or numeric bounds.
Common questions
Can one template serve several document types?
A template carries one Type, and the Type decides which documents it fires on — a Service Order template populates service orders; separate templates serve goods receipts, deliveries, shipments and inspections. Author one template per document family, even when the checks look similar.
Can I have more than one Service Order template?
Populate instantiates the lines of every template matching the document's Type, so the practical pattern is one well-structured Service Order template, using groups to organise its sections. Parallel templates of the same Type populate together, and the current selector does not exclude an inactive one — retype or remove obsolete templates, or add a business rule, before the next population run.
What is a RAG check?
A condition check answered on a Red–Amber–Green scale, defined on the template line with its colour codes and reading bounds. RAG answers are the usual trigger for service recommendation rules, which is what turns an inspection finding into proposed work.