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 nearly the same on both tabs. 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 page.
Click the COMPLIANCE HISTORY tab.
If the tab is empty, you'll see "No compliance history found for this assembly." (or "...for this location.") — 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
The assembly tab shows the seven columns below by default. The location tab shows six: its version of Test Updated Compliance Expiration is named Survey Updated Compliance Expiration and is hidden by default. 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 accepted report advanced the expiration date; red X if it did not; three dots if the entry has no value. A passing test accepted outside the Allowable Window Days shows a red X |
Modified By | The name of the user who triggered the event. Auto-accepted reports show System User |
Modified On | The date and time the event was recorded |
💡 The Assemblies Passing Test Didn't Update Due Date report lists assemblies whose passing test was accepted without advancing Next Test Due. 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 a red X on one of my accepted tests?
A: The test was accepted but it didn't advance Next Test Due. One 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: Yes. When auto-accept processes a submission, Modified By shows System User. When someone accepts it manually, it shows that person's name.