Who this article is for: Authority Users
Overview
Compliance History is an audit trail. Whenever something changes the compliance record — either by accepting a test/survey or by an authority user manually editing compliance fields — SwiftComply writes a new row to the history so you can see what happened, when, and who did it.
In plain terms: Compliance History answers "How did this assembly (or location) end up with the compliance status it has today?"
Where Compliance History Lives
There are two separate Compliance History tabs in SwiftComply. They look almost identical but track different things:
Location of the Tab | What It Logs | Driven By |
Assembly record → COMPLIANCE HISTORY tab | Changes to the assembly's Last Test Result, Last Tested On, and Next Test Due | Accepted test reports and manual edits to the assembly's compliance fields |
Location record → COMPLIANCE HISTORY tab | Changes to the location's Last Survey Result, Last Surveyed On, and Next Survey Due | Accepted surveys and manual edits to the location's compliance fields |
📝 The two tabs don't cross over. A test report only affects the assembly's history. A survey only affects the location's history. If you look at an assembly that's never had a test, its Compliance History will be empty even if its location has survey history — and vice versa.
The column layout is the same on both tabs. Only the Compliance Type column tells you which kind of event you're looking at: "Assembly Test" on the assembly tab, "Survey" on the location tab.
Finding the Tab
On an Assembly
Click Assemblies in the left navigation.
Click the assembly to open its detail page.
Click the COMPLIANCE HISTORY tab.
On a Location
Click Locations in the left navigation.
Click the location to open its detail panel.
Click the COMPLIANCE HISTORY tab.
If the tab is empty, you'll see "No Compliance History Found" — meaning no test (for assemblies) or survey (for locations) has been accepted yet, and no one has manually edited the compliance fields.
Reading the Columns
Both tabs have the same seven columns. Click the Table Columns gear icon (top-right above the table) to hide or show any of them.
Column | What It Shows |
Compliance Type | The kind of compliance this entry is for — Assembly Test on assembly records, Survey on location records |
Compliant | Green check if the event reflects a passing test/survey; red X if it reflects a failing test/survey or a manual edit setting the result to Fail |
Compliance Date | The Last Tested On (assembly) or Last Surveyed On (location) value as of this event |
Expiration Date | The Next Test Due (assembly) or Next Survey Due (location) value as of this event |
Test Updated Compliance Expiration | Green check if the event advanced the expiration date; blank if it did not. The most common reason it stays blank is when a passing test was accepted outside the Allowable Window Days |
Modified By | The name of the user who triggered the event |
Modified On | The date and time the event was recorded |
💡 If you see several entries where Test Updated Compliance Expiration is blank, tests are being accepted outside the Allowable Window Days. Run the Assemblies Passing Test Didn't Update Due Date report to list them. See Compliance Rules for how the Allowable Window Days setting works.
What Creates an Entry
On the Assembly's Compliance History
A test report is accepted. When a test report is accepted (manually or via auto-accept), SwiftComply updates the assembly's compliance fields if the test date is newer than the current Last Tested On:
Last Test Result and Last Tested On update to match the report.
Next Test Due advances only if the test passed, the test date is newer than the current Last Tested On, and — when Preserve Date is enabled — the test date falls within the Allowable Window Days.
A new row is written to the assembly's Compliance History reflecting those changes.
An authority user manually edits the assembly's compliance fields.
Open the assembly and click Edit.
Change Last Test Result, Last Tested On, or Next Test Due in the Standard Properties section.
Click Save.
Each save creates a new row in the assembly's Compliance History, with the authority user's name in Modified By.
On the Location's Compliance History
A survey is accepted. When a survey is accepted, SwiftComply updates the location's compliance fields the same way — Last Survey Result, Last Surveyed On, and Next Survey Due — and writes a row to the location's Compliance History.
An authority user manually edits the location's compliance fields. Same pattern: open the location, edit the relevant fields on the DETAILS tab, save — a new row is recorded.
📝 Changing your compliance rule settings (for example, adjusting Allowable Window Days) does not create new Compliance History entries and does not retroactively update existing records. The new settings only affect future test or survey acceptances.
FAQ
Q: I'm on an assembly and the Compliance History is empty, but the location has entries. Why?
A: The two tabs track separate things. The location's history shows surveys; the assembly's history shows assembly tests. If this assembly has never had a test accepted, its own history will be empty regardless of what's on the location.
Q: The Compliant column shows a red X even though the test/survey passed. Why?
A: That specific entry wasn't from a passing event. Compare the Compliance Date to the REPORT HISTORY tab (for assemblies) or the SURVEYS tab (for locations) — the entry may be from a failing submission or a manual edit where someone set the result to Fail.
Q: Why does Test Updated Compliance Expiration show blank on one of my accepted tests?
A: The test was accepted but it didn't advance Next Test Due. The most common cause is Preserve Date being enabled and the test falling outside the Allowable Window Days. The test is still accepted and recorded; the due date just stayed where it was. See Compliance Rules.
Q: I need to correct an older Compliance History entry. Can I?
A: No. Compliance History is an append-only log — once written, rows don't change. To correct the current compliance status, edit the compliance fields on the DETAILS tab. That creates a new row showing the correction; the older rows stay for historical reference.
Q: Can Service Providers see Compliance History?
A: No. Both Compliance History tabs are authority-only views. Service Providers don't access individual assembly or location detail pages.
Q: Does auto-accept show up differently in Modified By?
A: Modified By shows the name of the user who triggered the event — whether they manually accepted the submission or whether auto-accept processed it on their behalf.