Who this article is for: Authority Users
Overview
Generated communications are notices that SwiftComply creates based on rules your organization configures — for example, a first test-due notice 60 days before an assembly's Next Test Due, or an overdue reminder 30 days after. These communications are generated only — they are not sent automatically. Each one lands in the Unsent Communications queue, and an authority user takes the final action to send the email or print and mail the letter.
The most important thing to understand: SwiftComply generates the notice for you, but delivery is still a human step.
Where to Find Generated Communications
Click Communications in the left navigation.
The default view is the Unsent Communications report. This is where generated communications appear after they're created.
Each row shows:
Communication Type — the rule/template that generated the notice (for example, "First Notice", "Overdue Inspection")
Location Name — the property the notice is about
Contact Name — the contact the notice is addressed to
Contact Method — email or letter, based on the template's settings
Due On — the date the assembly is due for test, if applicable
Generated On — the date SwiftComply created the communication
Use the search and filter controls on this page to narrow the queue.
How a Communication Gets Generated
Generated notices come from Communication Types — rules your organization sets up on the Communications page. Each Communication Type specifies what to look for (for example, assemblies with a Next Test Due 60 days away), which contact at the location should be notified, whether to send by email or letter, and which template to use.
SwiftComply runs your Communication Types on a schedule (typically daily). Each time a Type runs, it needs three things to line up for a notice to be created:
A matching record. The assembly or location meets the Communication Type's targeting — for example, a Next Test Due between 45 and 60 days from today.
A contact who should receive it. The Communication Type points to a contact type (Primary Contact, Owner, etc.) that exists on the matching location.
Valid contact info for the delivery method. If the Communication Type sends by email, the contact has a valid email address. If it sends by letter, the contact has a mailing address.
When all three line up, a new row is added to your Unsent Communications queue, ready for you to send (for emails) or download, print, and mail (for letters).
📝 Generated communications aren't backfilled. If an assembly met the criteria yesterday but the Communication Type wasn't running yet, no notice goes back and fills that in — SwiftComply only evaluates records on the day the Type runs.
Sending or Printing Generated Communications
Because generated communications don't send themselves, you still need to deliver them. For letters, you download them to print and mail. For emails, you send them from SwiftComply.
For the full workflow on acting on the Unsent Communications queue — sending emails, downloading letters to print, marking communications as sent after you mail them — see Downloading, Sending, and Managing Unsent Communications.
FAQ
Q: If communications are generated for us, why isn't my tester receiving them?
A: Because generated means "created," not "sent." Each communication waits in Unsent Communications until an authority user delivers it. Email communications need to be sent from SwiftComply; letter communications need to be downloaded, printed, and mailed, then marked as sent.
Q: How are the rules set up to generate communications?
A: Communication Types are configured from the Create Type or Communication Types area of the Communications page. The rule specifies the trigger (days before/after Next Test Due, for example), which template is used, and which contact at the location receives it. Communication Types are typically set up during your initial SwiftComply configuration.
Q: How often does SwiftComply check for assemblies that match my rules?
A: SwiftComply runs the evaluation on a schedule configured for your organization (typically daily). New communications land in Unsent Communications each time the rule runs and finds newly matching records.
Q: What happens if a contact doesn't have a valid email but their template says email?
A: No communication is generated for that contact. If the template has a fallback method configured (for example, "email if available, otherwise letter"), SwiftComply will generate the fallback instead. Review the template's configuration for the exact fallback behavior.