Work History is one of TrueContext's most impactful features for field technicians - but like any powerful tool, getting the most out of it comes down to how you set it up and how your team uses it. Here are the best practices we've pulled together to help you hit the ground running.
Understanding the Two Parts of Work History
Before diving into best practices, it's worth being clear on the distinction between the two components, because they serve different purposes:
- Record History - Surfaces entire previous form submissions that are relevant to what you're working on right now. If a technician is servicing a piece of equipment at a site, they can see every previous inspection for that asset at that location - including submissions from other forms. Great for context.
- Data History - Dives into the specific data within a form. It shows how individual answers, measurements, and values have changed over time. Answer history even includes a line chart view for numerical questions, so you can spot trends heading towards an exception before it becomes a problem.
Both are valuable, but for different reasons. Record History gives you the big picture. Data History gives you the details.
Best Practice 1: Use System-Populated Identifiers for Entity Questions
Work History matches submissions together based on the values in your entity-mapped questions. If those values are inconsistent, the matching breaks down.
A free-text field where technicians manually type a serial number or site code is a red flag. You'll end up with "Northwest Corner," "NW corner," "northwest corner unit 3," and a dozen other variations - none of which will reliably match across submissions.
The ideal setup:
- Entity questions are populated from a data source or dispatched automatically from your back-office system
- The values are consistent and unique - Salesforce IDs, asset codes from your ERP, or similar
- The field is required, so there's never a blank that kills the match
If you're on Salesforce and you've noticed that your 15-character IDs don't always match your 18-character IDs, enable Salesforce ID Normalization in the Work History settings - it handles the conversion automatically.
Best Practice 2: Keep Entity Questions at the Top Level of the Form
In the current phase of Work History, entity questions need to be at the top level of your form - not inside a repeat section.
This affects a lot of forms where the top-level page captures who filled out the form and where they are, but the actual asset work happens inside a repeatable section. In that scenario, Data History won't be available for the individual assets inside the repeat.
What you can still do:
- Record History works at the site level if you have a site entity mapped at the top
- Aggregations, calculations, and footer totals from a repeat section are available in Data History - so a summary like "total defects found: 3" can still show history, even if the individual rows can't
If this limitation affects your forms, it's worth noting that future phases will address this with a different underlying architecture.
Best Practice 3: Pick the Right Entity for Data History
When enabling Work History in the Form Builder, you map entity questions to one of six entity types:
|
|
|
|
|
Preventive/corrective maintenance, vehicle inspections, depot repairs
|
|
|
Site inspections, safety audits, permits to work
|
|
|
Work orders spanning multiple visits, multi-form job workflows
|
|
|
Proposals, satisfaction surveys, account-level history
|
|
|
Employee evaluations, competency tracking, training records
|
|
|
Work on the same model of equipment, not the same physical unit
|
For Data History specifically, you can only pick one entity per form, so choose the most granular one relevant to the work being done. For a preventive maintenance form, that's almost always Asset. For an employee evaluation, it's Person.
Don't feel limited to the classic "site + asset" pattern either. Some of the most compelling use cases are the less obvious ones - recurring customer proposals, technician performance trends, or warranty claims against a product type.
Best Practice 4: Enable Work History on "Source" Forms Too
Work History doesn't need to be visible in a form for it to contribute to history in other forms.
A good example is an installation form. When you're installing a piece of equipment for the first time, there's no history to show - so you wouldn't enable the Work History display. But if that installation form is mapped to the same Asset entity as your ongoing maintenance forms, its submission becomes part of the record history that technicians will see later during maintenance visits.
Turn it on. Feed the history pool, even when you don't need to display it.
Assessing Whether Work History Is Right for Your Forms
Not every form is a good fit for Work History in this phase. Here's a quick gut-check:
Green light - strong candidate:
- Technicians do recurring work on the same sites and/or assets
- Entity values come from a data source or dispatch, not manual entry
- The workflow is consistent visit-to-visit (not dramatically different based on conditional logic)
- Entity questions are at the top level of the form
Red light - not a fit right now:
- All the interesting detail is inside repeat sections
- No consistent identifiers exist (free-text only, or not required)
- It's a one-time workflow with no recurring visits
- Data privacy restrictions prevent technicians from seeing each other's work
If you're on the fence, the best move is to look at a few real submissions from the form and ask: do we have consistent values that could tie these records together over time? If yes, you're probably in good shape.
Work History is the kind of feature that gets more valuable the longer it runs - the history builds up, the trends become meaningful, and the time technicians spend hunting for information keeps going down. Set it up right from the start and it pays dividends quickly.
Got questions on how to set up Work History in your environment? Drop a comment below.
------------------------------
Ian Chamberlain
Solutions Architect
TrueContext
------------------------------