Channel Maintenance

Data arrives from spreadsheets, other platforms and API integrations, and it does not always arrive in a form Broadcast can use. A date written 24/01/2026 cannot be compared by a segment rule. An address stored as " Bob@Example.com " will not be found by a lookup for bob@example.com. Neither is visible from the outside: the segment simply matches fewer people than it should, and nobody is told why.

Settings → Maintenance finds those values and repairs them. It also holds one task that is not a repair at all — copying this channel’s suppression list onto the global list — because it works the same way: a bulk job over the whole channel, previewed before anything is written.

How a repair works

Nothing is changed until you have seen what would change.

1. Scan and Check — walks every record in the channel and reports what it found. Nothing is written. On a large channel this takes a while, so it runs in the background and shows a live log of the records it is working through. You can leave the page; the scan carries on.
2. Review — the report lists what would change, with a link to each record so you can open it and judge for yourself.
3. Apply — rewrites the values. You are asked to confirm first.

Applying is only offered for the most recent scan of a task, and only when that scan found something. Once a repair has run, its scan describes data that has already moved on, so it can no longer be applied.

The repairs

Repair dates in custom fields

Rewrites dates stored in custom fields as ISO (2026-01-24) wherever there is only one possible reading. Segment rules compare custom fields as text, so a date written any other way cannot be used by a rule like “signed up in the last 30 days” — this is what makes those fields usable.

A field can also settle its own ambiguous values. If any value under a key proves the order — 24/01/2026 can only be day-first — then 01/02/2026 in that same field is read the same way. One clear value rescues the rest.

Repair dates typed into segment rules

A rule comparing against a date like 24/01/2026 matches nobody, and the segment gives no sign that anything is wrong — it just shows zero. This rewrites those values as ISO so the rule starts working. See Segments API for how rules are evaluated.

Tidy subscriber email addresses

Trims stray spaces and lowercases addresses, so lookups and imports stop missing them.

Addresses have been tidied automatically for some time, so this only affects records written before that — most channels will find nothing. If tidying an address would produce one that another subscriber already has, it is skipped and reported rather than merged: combining two real subscribers is a decision, not a repair.

Trim stray spaces from subscriber data

Removes leading and trailing whitespace from names and custom field values. A value stored as " pro " will not match a segment rule looking for pro.

A value that is nothing but whitespace is left alone. Emptying it would change it from non-empty to empty, which would silently change which subscribers an “is empty” rule matches.

Copy this channel’s suppressions to the global list

This one adds rather than repairs, and it is the only task that reaches outside the channel it is run from.

A suppression added here — by a bounce, a complaint, or by hand — stops mail from this channel only. If the same person appears in another channel, they can still be emailed from it. For a hard bounce or a spam complaint that is usually not what you want: the address is bad everywhere, and mailing it again costs sending reputation across your whole installation.

This task copies every address on this channel’s suppression list onto the global list, so they are blocked in every channel.

The channel’s own list is kept. Nothing is deleted or overwritten — the addresses simply appear on both lists, which is how you can still see which channel a suppression originally came from. Running it a second time adds nothing.

It follows the same two steps as a repair. Check what would be copied reports how many addresses would be added and lists them, without writing anything. Addresses already on the global list are excluded from the count, so a channel whose list has already been copied reports nothing to copy. The confirmation names the number and states plainly that the addresses will stop receiving mail in every channel, not just this one.

To reverse it, remove the addresses from the global list under Settings → Suppression List → Global. Removing them there does not touch this channel’s own list.

What it will not repair

01/02/2026 is the 1st of February in most of the world and the 2nd of January in the United States. Nothing in the value says which, so Broadcast will not choose — picking one would move every affected date by a month with no sign it happened.

The report names these separately so you can decide what to do:

• The order is not knowable — the field holds ambiguous dates and no other value in it settles the question.
• Two formats in one field — the field contains both day-first and month-first dates, so no single reading is right for all of them.

For either, the way out is to re-import that column with its format declared at the mapping step, which reads it exactly as you intend. See Managing Subscribers.

Values that are not dates at all — prose, numbers, today — are never touched.

Who can run it

Maintenance requires write access to channel settings, not just permission to view them. These tasks rewrite subscriber data in bulk, so read access is not enough. Every run records who started it and when.

Copying suppressions to the global list needs write access to global suppressions as well, because it changes what every channel on the installation can send to. Someone with channel settings access but not that permission will not see the task offered.

After a repair

Segments that were quietly matching too few subscribers start matching them. It is worth re-checking the subscriber counts on any segment that filters on a date field, and re-running any broadcast audience you sized before the repair.