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.
Note
Every task repairs only values with one possible correct answer. Anything that would require a guess is reported and left exactly as it is — see What it will not repair below.
How a repair works
Nothing is changed until you have seen what would change.
- 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.
- Review — the report lists what would change, with a link to each record so you can open it and judge for yourself.
- Apply — rewrites the values. You are asked to confirm first.
Warning
An apply cannot be undone. The original values are not kept, so there is no way to restore them from inside Broadcast — recovering them would mean a database restore or a re-import.
Read the scan before applying it. If the data has changed since the scan ran, scan again first: the report describes the channel as it was at that moment.
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.
| Stored value | Repaired to | Why it is safe |
|---|---|---|
" 2026-01-24 " |
2026-01-24 |
whitespace only |
2026-1-4 |
2026-01-04 |
year first, just missing zeros |
2026/01/24, 2026.01.24 |
2026-01-24 |
year first, so the order is not in question |
20260124 |
2026-01-24 |
fixed width, year first |
Jan 24, 2026, 24 January 2026 |
2026-01-24 |
the month is named, not positional |
24/01/2026 |
2026-01-24 |
24 cannot be a month, so the day comes first |
01/24/2026 |
2026-01-24 |
24 cannot be a month, so the month comes first |
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.
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.
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.
