The scheduled communication generation (the automated process that generates communications from published templates) tracks what's already been generated using two things:

It checks: "Has a communication with this type name already been generated for this record (e.g., an assembly or location) within the last 65 days?" If yes, it skips it. If no, it generates one.

Because the type name is what the system matches on, changing it in any way — whether by assigning a new type or renaming the existing one — breaks that match.

The suppression records still reference the old name, so the system sees no history and regenerates communications. This affects every record that currently falls within the template's configured time range (called the "generation window" — more on this below).

Note: There are two ways to change the type name — both cause regeneration:

Both break the suppression match and regenerate communications for all records in the active window.

Renaming is especially dangerous — it also rewrites the type name on every historical communication generated under the old name. You permanently lose the record of what type was in use when those communications were originally generated. There is no undo. Never rename an existing type. Always create a new one.

After a communication is generated for a record, duplicates are suppressed for 65 days. If the record still meets the criteria after 65 days (e.g., still hasn't been tested), the system generates the communication again, starting a new 65-day window.

Example: A template generates 90 days before Next Test Due. It creates a communication for an assembly. 65 days later, if the assembly still hasn't been tested, the system generates that communication again.

Use this when you need to change the layout, content, subject line, or formatting — and do NOT want to regenerate communications that already exist.

You do not need to manually unpublish the original — the system automatically unpublishes it when you publish the clone, as long as it shares the same type and targeting. The original stays active while you work on the update, so you don't miss any communications in the meantime.

Auto-unpublish is based on type + targeting. If two templates share the same type but have different targeting rules, they can both be published at the same time. When you clone and publish, make sure the targeting matches the original if your intent is to replace it. It should match if you use the Clone function.

If some communications need to be redone but not all of them, use a more targeted approach instead of changing the type:

Ad hoc and batch communications are not subject to duplicate suppression — suppression only applies to the automated scheduled generation. So these will always go through, even if the record already has an existing communication of the same type.

Use this only when there's a critical issue and every record in the window needs a new communication.

When you publish a template with a new type, it doesn't generate communications for every record in the system — only those that currently fall within the template's configured time range. This is the period setting on the template (e.g., "30 days before due date" or "7 days after due date").

That time range is a window, not a single day:

Any record within that window that matches the template's targeting will get a new communication generated, since there are no suppression records under the new type name.

Once the duplicates have been generated, it's done — the system won't generate them again. There's no action needed on the template or type. All that's left is cleaning up the duplicates: