Overview
SwiftComply can automatically create a communication whenever an assembly test or survey is accepted with a failed result. You set it up the same way as your due-date based communications: define a Communication Type with the new failed trigger, then write a template that says what failed and when. This article covers creating the trigger, timing the notice, adding the new failure-detail merge fields, and stacking multiple notices.
🎥 Watch a walkthrough
Before you begin
You need access to your organization's Communications settings.
It helps to already know how to build a Communication Type and template — see Building & Editing a Communication Type and Template.
A report must be accepted before any notice generates (see What happens next).
Step 1: Create the Communication Type (the trigger)
The Communication Type defines what sets the notice off.
In Communications, create a new Communication Type.
Set the Source:
Assembly for tests.
Location for surveys.
Set the Trigger Type:
Failed Test (shown when the source is assembly).
Failed Survey (shown when the source is location).
Set Trigger Info:
Assembly test for a failed test.
Survey for a failed survey.
Save the Communication Type.
The trigger label follows the source — you'll see Failed Test for assemblies and Failed Survey for locations. It's one trigger, labeled for each source.
Step 2: Create the Communication Template (timing and message)
The Communication Template uses that type, sets the timing, and holds the message.
Create a new Communication Template and choose the Type you just made.
Set the Period. For a failed trigger the direction is locked to After — you can't send before a failure.
Enter the number of days. It must be a whole number, at least 1 — there's no same-day option. Example: entering 5 sends the notice about 5 days after the failed report was accepted.
Write the message body, adding the merge fields below.
Save the Communication.
The form shows the note "Excludes inactive assemblies & locations." Communications are never automatically generated for inactive assemblies, inactive locations, or active assemblies at an inactive location.
Step 3: Add the failure details (merge fields)
In the message body, type each of these field names wrapped in double curly braces, wherever you want the detail to appear. The exact syntax is shown in the screenshot below. When the notice is generated, each field is filled in from the failed report.
Field name (wrap in double curly braces) | What it shows |
| The test or survey date |
| The user listed as the tester or surveyor on the report |
| The date the report was accepted |
| A table of what failed, with Item, Value, and Issue columns |
⚠️ Type these fields in by hand, wrapping each name in double curly braces exactly as shown in the screenshot below. A misspelled field prints as plain text instead of the real value.
Step 4: Stack multiple notices (optional)
To escalate when the responsible party ignores the first notice, set up more than one notice at different intervals. Repeat Steps 1–3 for each tier — each notice is its own Communication Type and Communication Template, which is what lets them fire independently.
Example cadence:
First Notice — 5 days after
Second Notice — 30 days after
Final Notice — 60 days after
What happens next
A nightly job checks for assemblies and locations whose most recent accepted report failed, then generates any notices that are due.
Notices wait in Unsent Communications. Nothing is sent automatically — generated notices land in your Unsent Communications queue for you to review and send. See Downloading, Sending, and Managing Unsent Communications.
"N After" is a window, not an exact day. A "5 After" notice is eligible from day 5 through day 12 — the extra week is a catch window so the nightly job never misses one. It normally goes out on day 5 and fires once per report.
The clock starts at acceptance, not the test date. A report accepted today starts counting today, even if the test was performed weeks ago. The actual test date is available in the test-date merge field.
A later report with a passing result stops it. If a newer report passes — or someone manually marks the record compliant — no further failed communications generate. Communications already in Unsent Communications stay.
A re-failure starts over. A new failed report is a new report, so the whole cadence begins again on the new failure.
Troubleshooting
Problem | Likely cause | What to do |
No communication generated for a failed test | The report isn't accepted yet (only accepted reports count), or the assembly/location is inactive | Accept the report; confirm the assembly and its location are active |
A merge field prints as literal text instead of a value | The field name is mistyped | Re-type it exactly, including the double braces |
A communication never went out | Generated communications wait in Unsent Communications; they aren't auto-sent | Review and send them from Unsent Communications |
A communication didn't arrive on the exact day | The job runs nightly and fires within a ~7-day window after your Period | Expected — allow up to a week |
A responsible party got both a failed-test communication and a past-due communication | Both triggers can fire on the same assembly | Expected today; contact SwiftComply support if the overlap causes trouble |
Related articles