Who this article is for: Authority Users
Overview
Every assembly in SwiftComply has three fields that drive its compliance: Next Test Due, Last Test Result, and Last Tested On. These fields update automatically when accepted test reports are processed, and they can be edited manually by an authority user. This article explains what each field means, when it updates, and how to find assemblies that need attention.
The Three Fields
Field | What It Shows |
Next Test Due | The date the next backflow test is due for the assembly |
Last Test Result | The result of the most recent accepted test — Pass or Fail |
Last Tested On | The date the most recent accepted test was performed |
All three appear on the Compliance info card at the top of the assembly detail page, and are available as columns on the Assemblies table (add them from the Table Columns gear icon if they aren't visible).
How Next Test Due Is Calculated
SwiftComply calculates Next Test Due using your organization's compliance rule settings. The key settings are Compliance Period, Preserve Date, Allowable Window Days, Minimum Expiration Buffer, and End of Month Expiration. These are configured by SwiftComply — authority users cannot change them directly. If you need a setting changed, contact your CSM to submit a change request.
Without Preserve Date, Next Test Due is calculated from the test date plus the Compliance Period.
With Preserve Date on, Next Test Due stays on the same month and day and advances by the Compliance Period from the existing due date — as long as the test falls within the Allowable Window Days (more on this below).
For the full details on each setting and how they interact, see Compliance Rules.
📝 The End of Month Expiration setting moves the calculated due date to the last day of the month during the calculation. It only affects dates that are calculated after the setting is enabled — it does not retroactively move due dates that were set before.
When Last Test Result and Last Tested On Update
Last Test Result and Last Tested On update when:
A test report is accepted and the test date is newer than the current Last Tested On, OR
An authority user manually edits these fields on the assembly's DETAILS tab.
A failing test still updates these two fields as long as the test date is newer than the existing Last Tested On. The difference is that a failing test does not advance Next Test Due — only a passing test does.
📝 Accepting an older test report (one with a test date earlier than the current Last Tested On) does not change any of these fields. The report is accepted and recorded, but it will not overwrite newer data.
When Next Test Due Updates
Next Test Due advances only when all three of these conditions are met:
A test report is accepted.
The test's Tested On date is newer than the current Last Tested On.
The test result is Pass. (A failing test will not advance Next Test Due.)
How Allowable Window Days Affects This
If your compliance rule has Preserve Date enabled, Allowable Window Days (AWD) comes into play — but only when the test date is before the assembly's current Next Test Due:
Test date is before Next Test Due AND within AWD → Next Test Due advances using Preserve Date logic.
Test date is before Next Test Due AND outside AWD → The test is still accepted, but Next Test Due stays where it was. These tests show up on the Assemblies Passing Test Didn't Update Due Date report.
Test date is on or after Next Test Due → AWD doesn't apply at all. Next Test Due advances normally.
In other words, AWD is the rule for "how early before the due date a test can happen and still preserve that date." Tests on or after the due date are evaluated without AWD.
How the Minimum Expiration Buffer Affects Next Test Due
Starting August 13, 2026, the Minimum Expiration Buffer adds one more rule when Preserve Date is on and the assembly already has a due date on record. When a test report advances Next Test Due, the system keeps the new date a minimum distance past the test date. The buffer only comes into play when an assembly is tested after its due date has already passed.
Why it exists: with Preserve Date, Next Test Due keeps the same month and day and moves forward one Compliance Period at a time. When an assembly is tested years late, the next date in that sequence can land only days after the test — so an assembly can be due again almost immediately after it was tested.
The buffer sets a minimum gap: the new Next Test Due must be at least the buffer percentage of your Compliance Period past the test date. If the normal Preserve Date advance would land closer than that, the system advances one more Compliance Period. The default is 25% — on a 1-year Compliance Period, a test report that advances the due date pushes Next Test Due at least 3 months past the test date.
Example (1-year period, 25% buffer): an assembly's Next Test Due is July 31, 2023, and you accept a passing test report with a Tested On date of July 18, 2026. Without the buffer, the new Next Test Due would be July 31, 2026 — only 13 days after the test. With the buffer, the earliest allowed date is October 18, 2026 (3 months past the test date), so Next Test Due advances to July 31, 2027.
A few things the buffer does not do:
It is not retroactive. Due dates already on record don't change — the buffer only applies to test reports accepted after it takes effect.
It doesn't apply to an assembly's first-ever test. With no due date on record, Next Test Due comes from the test date plus the Compliance Period.
It doesn't change the Allowable Window Days rules. A passing test outside the window still leaves Next Test Due where it was.
It doesn't replace End of Month Expiration — the system applies that setting after the buffer.
It does nothing when Preserve Date is off.
It doesn't affect routine tests. At the default 25% on a 1-year period, the buffer only changes the result when the assembly is more than 9 months past due.
The new due date still lands on the assembly's usual month and day, so the buffer can push it out further than one full Compliance Period from the test date. That's expected — it's the trade-off for guaranteeing the minimum gap. SwiftComply configures the buffer for your organization, like the other compliance rule settings. Contact our support team to use a different percentage, or to set it to 0 (which restores the previous behavior).
Next Test Due can also be changed manually by an authority user — see below.
Editing These Fields Manually
An authority user can edit Last Test Result, Last Tested On, or Next Test Due directly on the assembly's DETAILS tab:
Open the assembly from the Assemblies table.
Click Edit.
In the Standard Properties section, update the field you need to change.
Click Save.
Each manual change is logged in the COMPLIANCE HISTORY tab with the authority user's name.
Finding Assemblies That Are Due Soon or Past Due
Past Due
On the Assemblies table, the cleanest way to find past-due assemblies is to filter by Next Test Due directly:
Click the Advanced Filter Builder icon in the Assemblies toolbar.
Build a rule: Next Test Due is less than today's date.
Click Apply Advanced Filter.
You can also filter by Overall Compliance status to see all non-compliant assemblies (Overdue and Failed together). See Understanding Assembly Compliance Status for how Overall Compliance is determined.
💡 If you find yourself running the same filter often, save it. Apply your filters, click the Save Filters icon, and name the view. It will appear in the saved filter selector at the top-left of the table.
Due Soon
Use the Advanced Filter Builder to find assemblies with Next Test Due in an upcoming window — for example, Next Test Due greater than today AND Next Test Due less than 60 days from today. This gives you a working list for upcoming notices or scheduling.
FAQ
Q: I accepted a passing test, but Next Test Due didn't change. Why?
A: The most common reason: your compliance rule has Preserve Date enabled, the test date was before the assembly's current Next Test Due, and the test fell outside the Allowable Window Days. The test is accepted and recorded, but Next Test Due stays where it was. Run the Assemblies Passing Test Didn't Update Due Date report to find these assemblies.
If the test date was on or after the current Next Test Due, AWD isn't the cause — check that the Tested On date on the report is newer than the assembly's existing Last Tested On.
Q: A newly accepted test report has Last Test Result set to Fail, but my Last Tested On didn't change. What happened?
A: Last Tested On only updates when the accepted test's date is newer than the existing Last Tested On. If the failing report was older than the current Last Tested On, the fields stay as they are.
Q: Can I change Next Test Due without entering a test report?
A: Yes. An authority user can edit Next Test Due on the assembly's DETAILS tab by clicking Edit, updating the field, and clicking Save. The change is logged in the Compliance History tab.
Q: Who configures the settings that control how Next Test Due is calculated?
A: SwiftComply configures the compliance rule settings (Compliance Period, Preserve Date, Allowable Window Days, Minimum Expiration Buffer, End of Month Expiration) for your organization. Authority users can't change them from the UI. To request a change, contact your CSM to submit a change request.
Q: I tested a long-overdue assembly, and its new Next Test Due is more than a year out. Why?
A: That's the Minimum Expiration Buffer. When the normal Preserve Date advance would land too close to the test date, the system adds one more Compliance Period — so the new due date can land more than one full Compliance Period past the test date. If you'd prefer a smaller minimum gap, contact our support team to lower your organization's buffer percentage.
Q: Will the buffer correct due dates that were set before August 13, 2026?
A: No. The buffer isn't retroactive — it only applies to test reports accepted after it took effect. To find assemblies whose due date already landed too close to their last test, run the Assemblies With Due Date Close To Last Test report and update their Next Test Due dates manually.