Is each field being used for what it is for?
Source truth asks whether a field holds sensible values. Field discipline asks a harder question: does the field behave the way its name promises? It reads the change history of your records — every value a field held, when, and what wrote it — and reports the fields whose history contradicts their purpose. Read Can you trust the field you report channels from? first if what you want is the values themselves rather than the behaviour.
Before you start
Open Insights in the left-hand menu, then Analysis, pick your tool along the top, and click Field discipline. The first read calls your tool one record at a time, and the screen says so: “The first read takes up to a minute.”
What this reads
Only the change history your tool keeps. Nothing here is written back, and no value in your tool is altered by opening the tab.
What a field promises
An experienced operator reads a field as a promise rather than a column of values. “Original source” promises to be the first thing that ever happened and never to move. “Most recent conversion” promises to move every time. A lifecycle stage promises to climb. A score promises that a rule wrote it, not a person. Your reports are built on those promises, and until now nobody checked them.
MarqIQ works out each promise in your workspace from the field itself: the words in its label and key, its type, its picklist, and the fields sitting beside it. A “Lead source” next to a “Lead source most recent” is the first-touch half of a pair by design. No list of field names is built in, so a custom field is read exactly as a native one is.
| What MarqIQ reads it as | What that means | How it is recognised |
|---|---|---|
| Set once, then left alone | The first value is the answer and nothing should replace it | Its name says first, original, initial, earliest, acquisition, originating, signup or registration; or a “most recent” twin exists beside it; or it is the field your reports read as where a record came from |
| Meant to update every time | It should move whenever something new happens | Its name says last, latest, recent, newest or converting |
| Meant to move forwards only | A ladder is climbed, not descended | It plays the part of a lifecycle or stage field, or its name says lifecycle, stage, funnel or deal stage and it offers three or more options |
| Written by a rule, not by hand | The number is the output of a rule, so a person typing into it breaks it | It is numeric and named as a score, a scoring field, or a running count |
| A forecast date | It is the date a deal is expected to close, which is what a forecast is made of | It is the deal’s close date field |
Every reading MarqIQ made is listed on screen under How each field was read, with the reason beside it. A reading you disagree with is shown so you can dismiss the finding built on it.
What is deliberately left out
A clock such as “Last modified” or “Last activity date” moves by design and promises nothing, so it is skipped. So are a person’s first and last name, which carry the words and none of the meaning. So is a field your tool calculates: there is no promise a customer could break. And a field that nothing but your tool itself has ever written is set aside as the tool’s own, counted in the method line rather than judged.
What it looks for
Nine faults, each with the evidence, what it damages in business terms, the fix, and a See it for yourself line telling you how to reproduce it in your own tool. Each one carries a Still happening tag when the most recent case falls inside the last 90 days.
A set-once field being replaced after it is first set
The commonest and most expensive. Raised when at least three of the records checked, and at least 2% of them, held one real value in that field and were later changed to a different one. It becomes a fault rather than a risk at 10% and five records.
The finding names what did the replacing — a workflow, a form, an import, an integration or a person — with a count against each, how long after the first value the first replacement typically came, and the month of the most recent one. It also prints the share across your whole database as an “at least” figure, which is the cautious end of a 95% range rather than the share of the sample.
The damage is stated plainly: every replacement moves a person or a deal, and any revenue attached, from the channel that really found them to whichever touched them last. First-touch reporting turns into last-touch reporting one record at a time.
Two things fighting over one field
A field whose value is set, set back, and set again. Raised when at least three records show the value flipping between the same handful of values four or more times, with at least two different writers involved. This needs no promise at all: a field two things keep flipping is wrong whatever it was meant to be.
A rolling field that stopped updating
Raised when nothing has written to a “most recent” field on any record checked for more than 180 days, and at least five of the records checked arrived after that date carrying no value. The finding names what used to write it. The usual causes are an automation switched off, a form replaced without its hidden field, or an integration disconnected.
A “most recent” field that is only a copy
Raised when a rolling field equals its first-touch twin on 95% or more of the records where both are filled, and has moved after first being set on under 3% of records. At least 20 of the records checked have to carry a value in both fields before the comparison is made. You have two fields and one answer, and nothing records what brought a person back the second time.
A stage going backwards
Raised when at least three records, and at least 2% of them, moved to an earlier rung than one they had already reached. It becomes a fault at 10% and five records. Exits from the ladder are not counted as backward moves: values whose names say lost, disqualified, unqualified, other, churn, junk, bad, nurture, recycled, closed lost, no decision or on hold are treated as off the ladder.
Where a stage field holds a ladder for each sales pipeline, each pipeline is judged as its own ladder, so a deal moving between pipelines is never read as a step down.
Records that jump to the end of the ladder
Raised when at least ten records reached the top rung of a ladder of four or more stages, and half or more of them were never recorded at any middle stage. On deals that usually means the deal was entered after it was already decided, so the pipeline never showed it while it was open.
A calculated score people are also typing into
Raised when a rule writes the score on 70% or more of the records checked and at least three records were also set by hand or by import. The fix looks through your other fields first and names an override field you already have, rather than telling you to create one.
A score that is typed in by hand altogether
Raised when a rule wrote under 30% of the records checked and a person or an import wrote the last value on 70% or more of them. A score people type is an opinion, and it goes stale the day after it is entered.
Close dates that are pushed, not forecast
Raised when a close date field has history on at least 20 deals in the sample, at least ten of those deals are still open, and at least three of the open ones — and at least 10% of them — have had the date moved later three times or more. It becomes a fault at 25%. The finding gives the total slip on those deals as a typical figure.
The two counting rules that stop false alarms
- Writing the same value again is not a change. Repeats are collapsed before anything is counted, so an integration that re-asserts a value every night raises nothing.
- Replacing a placeholder with a real value is the field being filled in, and is never counted against it. Unknown, Other, N/A, None, Null, not set, not provided, unspecified, test, a run of dashes, question marks and dots, and the to-be-decided shorthand all count as placeholders. The number of records enriched that way is printed in the finding as a separate line.
Note
A change your tool made to its own reading of a field is also never counted against that field. Only what your team, your automations, your forms, your imports and your integrations did is held against the promise.
What the numbers are measured on
This is the analysis where the denominator matters most, because it is the only one that reads a sample of change history rather than every record.
- A field is judged only when at least 20 of the records checked carry any history for it. Fields that carry a purpose and fall below that are listed by name at the foot of How each field was read, so a field you expected is never silently absent.
- Every share on the page is a share of the records checked, and the finding says so — “on 312 of 1,400 people checked”. The “at least” figure beside it is the cautious end of a 95% range for your whole database.
- The records read are an even spread across your whole database, never the newest. Older records have had more time to be overwritten, so the newest records would understate every finding here.
- The tiles at the top count fields, not records: Used against purpose, Early signs, Behaving and Fields tested.
What your tool can and cannot show
The whole analysis rests on your tool keeping a per-field change history, and the six that do keep different amounts of it. Where the history is limited, the card headed What could be tested, and what could not says so above the findings.
| Tool | What MarqIQ reads | What limits it |
|---|---|---|
| HubSpot | Property history — every value a property ever held | Nothing. This is the fullest history of the six |
| Marketo | The “Change Data Value” activities on the person | The activity log reaches back about 25 months |
| Salesforce | Lead, Contact and Opportunity field history, plus Opportunity History | Field History Tracking has to be switched on per field. Stage, amount and close date on the Opportunity are always kept, so those are readable without any setup |
| Pipedrive | The per-record changelog | One request per record, so a smaller sample is read — up to 60 records |
| Zoho CRM | The per-record timeline | One request per record, up to 60. The connection needs permission to read the timeline |
| Microsoft Dynamics | Audit history | One request per record, up to 60. Auditing has to be on for the organisation and for the contact, lead and opportunity tables, and the app user needs the “View Audit History” privilege |
Pardot (MCAE), Mailchimp, Salesforce Marketing Cloud, Adobe Campaign and Adobe Journey Optimizer keep no per-field change history, so the tab is muted for them and says so in one sentence.
How far this has been tested
HubSpot and Marketo are verified on live accounts. Salesforce, Pipedrive, Zoho CRM and Microsoft Dynamics follow the vendors’ documented APIs and are tested on payloads of that shape; none has been run against a customer account yet. Where a tool returns something unexpected, it ends as a plain sentence on the page rather than as a wrong finding.
Who made each change
Every writer is sorted into one of seven kinds — a person, an automation, a form, an import, an integration, the tool itself, or a source the tool does not name — and the finding names them with a count each, in your tool’s own words. Where the tool gives an automation’s name, the fix uses it: “In Lead routing v3, add the condition …” rather than “in the workflow that sets it”.
The fix itself is written for your tool. On HubSpot it names the workflow condition, the form mapping and the property-history export. On Marketo it names Block Field Updates in Admin › Field Management. On Salesforce it names a validation rule on ISCHANGED. On the other three it describes the change in general terms, because the mechanism differs.
Opening the records behind a number
This is the one analysis whose findings let you open the exact records. Where a finding carries them, up to 200 record ids are kept and listed, spread evenly across the set rather than taken most-recent-first, and the panel says when the list is shorter than the total. The other analyses collect no record ids for this panel today.
What it will not do
- It changes nothing in your tool. Every fix is a description of work.
- It never judges a field by its name alone. A field whose history contradicts the reading is shown with that reading, so you can see what was assumed.
- It does not tell you to create a field you already have. Before advising a “stalled” marker, an override field or a push counter, it looks through your full field list and names the one you hold.
- It claims nothing about a tool it cannot read a history from.
If it did not work
The headline says no field could be read as carrying a promise
Why: None of the fields MarqIQ read carries a first-touch, most-recent, ladder, score or close-date meaning under any wording it recognises.
Fix: Open Field Intelligence under Insights for the same tool and check what your source and stage fields are called. A field named only in internal shorthand carries no words to read a promise from; renaming its label is enough, because the label is what MarqIQ reads first.
Fields are listed as carrying a purpose but none was tested
Why: Fewer than 20 of the records checked have any change history for them. On Pipedrive, Zoho CRM and Dynamics 365 the sample is 60 records, so a field written on a minority of records reaches 20 rarely.
Fix: Read the line at the foot of How each field was read: it names the untested fields. Widen the population by clearing the Created filter, then click Read the latest from your tool.
A Salesforce field you care about shows no history
Why: Salesforce keeps field history only for fields with Field History Tracking switched on. Stage, amount and close date on the Opportunity are the exception and are always kept.
Fix: In Setup › Object Manager › the object › Fields & Relationships › Set History Tracking, tick the field. History starts from the moment you switch it on, so this analysis fills in over the following weeks rather than at once.
Dynamics 365 returns no audit history at all
Why: Auditing is off, or the connected app user lacks the privilege.
Fix: Switch auditing on for the organisation and for the contact, lead and opportunity tables, and give the app user the “View Audit History” privilege. The page prints that same sentence when the read is refused.
A field is flagged and you know the changes were legitimate
Why: The reading may be wrong for your workspace — a field named “Original campaign” that your team genuinely re-points each quarter, for example.
Fix: Open How each field was read and check the reason MarqIQ gives. Where the reading is wrong the finding is wrong with it, and you can dismiss it. The reading is shown for exactly this reason.
You fixed the cause and the finding is still there
Why: The reading of your tool is kept for a day, and the finding describes history, which does not disappear when you stop adding to it.
Fix: Click Read the latest from your tool. The Still happening tag drops off once 90 days pass with no new case; the historic count stays, because those records are still wrong until they are repaired.
Next steps
Related articles
Was this article helpful?