A service recommendation is a standing advisory against an asset: work that should be done, discovered on one visit, that follows the asset until it is either done or declined. Each recommendation carries the asset, its Condition on a Red–Amber–Green scale, a Recommendation Type (Health, Past, Complaint, IOT), the recommended Item and Quantity, the measured evidence behind it (a Value Type with the matching Text Value or Numeric Value), the Recommendation Remarks, and the source it came from — the checklist line, or the complaint line on a service order or opportunity. Because it hangs on the asset — not on the document that raised it — a finding from today's inspection can become billable work on next month's order.
Four flags carry its lifecycle: Is Accepted, Is Rejected, Is Utilized and Is Consumed. The first three are set by the service-order actions described below (and, for mandatory complaint items, by the complaint engine itself); Is Consumed is not written by any service-order process (it is used by the field-visit insights screens) and should not be read as service state. A fifth flag, Is Mandatory, marks a recommendation the customer was never free to decline — it is set only on the complaint path.
Read the screen
- 1
Asset is the anchor: sort or filter here to read one asset's history of advice rather than treating repeats as unrelated work.
- 2
Item is the proposed work; it becomes the service-order line when the recommendation is accepted.
- 3
Recommendation Type: Health from checklist rules, Complaint from complaint items, IOT from connected-asset alerts, Past for deferred work.
- 4
Is Utilized is set by invoicing; a utilised row can no longer be deleted.
- 5
Condition keeps the Red/Amber/Green verdict copied from the checklist line that raised it.
- 6
New creates a manual recommendation against an asset; decisions are still taken from the service order or opportunity.
The Service Recommendations list is the triage register for outstanding advice. Name and Asset identify the finding, Item and Recommendation Type describe the proposed action and why it matters, Condition preserves its RAG state, and the audit columns show when and by whom it was raised. Search by asset or item before opening a row so repeated recommendations can be compared as a history rather than treated as unrelated work.
- 1
Name is required and is what advisors see in the recommendations list.
- 2
Item is the proposed work and Asset the unit it follows; Get Service Recommendation lists open rows by the order's asset.
- 3
Condition holds the Red/Amber/Green finding; Text Value and Numeric Value hold the reading behind it.
- 4
Value Type (Numeric, Boolean, RAG), Recommendation Type (Health, Past, Complaint, IOT) and Checklist Line classify and trace the finding.
- 5
Quantity and Recommendation Remarks are what the advisor sees; Accept Label, Reject Label and Recommendation are stored but not read by the Get and Post actions.
This is a service-recommendation record, not the separate recommendation-rule editor. Item and Asset identify the proposed work and covered unit; Condition (Red, Amber, Green), Value Type (Numeric, Boolean, RAG) and the text or numeric values retain the observation; Recommendation Type (Health, Past, Complaint, IOT) classifies it; Checklist Line preserves the inspection source; Quantity and Recommendation Remarks describe the proposed work. The form also offers Recommendation, Accept Label and Reject Label fields: they are stored with the record, but the shipped Get and Post actions read none of them — the advisor sees the item, quantity and remarks. Record enough evidence that another person can understand the finding and proposed work without seeing the original inspection.
At reception, open recommendations should be reviewed against the current asset condition, not accepted mechanically. Acceptance creates ordinary service-order work with a link back to the advisory; rejection closes the decision while preserving proof that advice was offered; leaving it undecided deliberately carries it to the next visit. Verify accepted, rejected and utilised state from the saved record's flags and the linked order line, not from which list the recommendation happens to appear in.
Where recommendations come from
- Checklist findings — service recommendation rules watch checklist answers: 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. When a checklist line is saved or updated, matching rules raise the recommendation against the order's asset, with the trail back to the checklist line; the Value Type is the line's data type and the text or numeric value is the answer. A rule matches in one shape only — RAG equality, above a greater-than bound, below a less-than bound, strictly between both bounds, or (with neither) any answered Text line.
- Complaints — complaint lines recorded on service orders, opportunities and estimates raise recommendations from the complaint item catalogue: one row per item a complaint normally consumes, optionally narrowed to a single fault code, with a quantity and an Is Mandatory flag. When a complaint line is posted, every applicable catalogue row becomes a recommendation typed Complaint, carrying the item, the quantity, remarks of the form Complaint : … Fault : … Recommended Qty : … and links to the complaint line and the document. A mandatory row is accepted by the engine on the spot and its document line is raised immediately — the advisor never has to tick it — while an optional row stays a suggestion until someone accepts it. Re-pointing the complaint line to another complaint or fault code reconciles the set (suggestions that no longer apply are removed unless they have been accepted or already have a line), and deleting the complaint line removes the recommendations it generated.
- Manual entry — a recommendation can be created directly against the asset from the Service Recommendations list (New), which is also the path for advisories arriving from outside signals such as connected-asset alerts. The create form puts the observation fields first (Item, Asset, Condition, Text and Numeric Value, Value Type, Recommendation Type, Checklist Line) and the proposed work — Quantity, Recommendation Remarks and the label fields — under Recommendation Details.
How they surface on a service order
Get Service Recommendation on a service order lists the asset's open recommendations — not accepted, not rejected, not utilised, and not yet attached to a service order or quote — together with any already tied to this order. That is the advisor's view at reception: everything ever recommended for this asset that is still undecided. The service order's recommendation panel is where the shipped layout presents it. An order without an asset gets an empty list rather than an error.
Post Service Recommendation records the customer's decision per recommendation:
- Accept — the recommendation is marked accepted and a service order line is created from it: the recommended item, the quantity, the recommendation type and the link back to the recommendation. From there the line is ordinary work — estimated, allocated, done, invoiced.
- Reject — the recommendation is marked rejected and stops being offered.
Recommendations travel with estimates too: a quote line generated from a recommending order or opportunity line keeps the recommendation link, so acceptance through an estimate carries the same trail.
Utilisation — the end of the trail
When the order carrying a line created from a recommendation is invoiced (full or selective invoicing), the recommendation is marked utilised and linked to the consuming service order and line. A utilised recommendation no longer appears in the open list, and deleting it is refused with Cannot delete a utilized service recommendation. — the record is the audit trail from finding to billed work. Undecided recommendations, by contrast, keep resurfacing on every order for the asset until someone accepts or rejects them, which is the point: a deferred repair is not forgotten.
Common questions
Why does the same recommendation keep appearing?
Because it is still open — neither accepted, rejected nor utilised. That is deliberate: an advisory follows the asset until it is decided. Record a rejection if the customer has declined the work; it will stop being offered.
What happens when the customer declines recommended work?
Post the recommendation as rejected. The record stays on the asset flagged as rejected — evidence the advice was given — but it is no longer offered on future orders.
Can I delete a recommendation?
Only while it is not utilised. Once invoicing has marked it utilised the delete is refused, because the recommendation is now part of the trail from inspection finding to billed line.
Where do the Get and Post actions live?
On the service order and on the service opportunity — both carry Get Service Recommendation and Post Service Recommendation as server actions, and the opportunity version creates opportunity lines instead of order lines; the service order's Recommendations tab hosts the widget that calls them. Estimates have no Get/Post pair of their own — a recommendation reaches a quote line only through the order or opportunity line it was generated from, or through a mandatory complaint item posted on the estimate. The recommendation record itself has only the standard New, Edit, Clone and Delete actions (its saved view is two tabs, Related and Details); the decision is always taken from the document at reception. The document needs an asset before Get can list anything.
Do recommendations expire?
There is no automatic expiry — an open recommendation persists until accepted or rejected. Review the open list periodically and reject what is no longer relevant, or the reception view accumulates stale advice.