# Channel Maintenance

> Repair imported data that Broadcast cannot use (dates in the wrong format, stray spaces, and addresses that stop lookups matching) with a scan you review before anything is written.

Source: https://sendbroadcast.net/docs/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.

Note

A **repair** only changes 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](#what-it-will-not-repair) below.

## 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.

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](https://sendbroadcast.net/docs/api-segments) 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, the two are the
same person, and both were counted (and sent to) separately. The untidy copy is deactivated so it
no longer counts; nothing is deleted, and its history says which subscriber it duplicates. The
preview lists these before anything changes.

### 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.

### Repair Postmark server names

Earlier versions of Broadcast sent Postmark a server name with `Postmark - ` in front of it, and
added another prefix each time Guided Setup was re-run for the same server. Over several runs a
server ended up named `Postmark - Postmark - Acme` inside your Postmark account. Nothing about
your sending was affected, since it is only the name you see in Postmark's own dashboard, but it
grows until it hits Postmark's limit on how long a name can be.

Broadcast no longer adds the prefix anywhere, and existing names in Broadcast were tidied when you
upgraded. This task fixes the other half: the name held by Postmark itself, which no upgrade can
reach.

The scan asks Postmark what each server on this channel is currently called, and only offers to
rename the ones where the remote name is your Broadcast name wearing that old prefix. A server
whose Postmark name differs for any other reason is reported and left alone, since you may have
renamed it in Postmark deliberately, and that is not Broadcast's to overwrite. A server Broadcast cannot
ask about, because it has no stored account token or server ID, is reported for the same reason.

Most installations will find nothing. It is safe to run either way, and it needs the **email
servers** write permission, because it changes something in your Postmark account rather than in
this channel's data.

## 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.

Note

You can also reach this from **Settings → Suppression List**: the **Channel** tab has a **Copy to global list** button that brings you straight here.

## 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](https://sendbroadcast.net/docs/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.