Lists: sendable counts, duplicate, and an email field that lives on the object

The second half of the Lists work: the numbers on a list mean something now, and the field a list sends to belongs where it always should have.

Records, and records you can actually email

A list shows both. Sendable is the count that matters before a send, and hovering it breaks down the difference: how many unsubscribed or are blocked, how many have no address, how many are a second record holding an address already counted. Each reason links somewhere you can do something about it.

A list that has not been counted yet says so, rather than showing zero. Those are different facts and only one of them should send you looking for a problem.

Duplicate, and Refresh data

Both are on the … menu, on the index and inside a list.

Duplicate copies a list. For a static list it copies the members too - and it copies their consent records exactly as they stand. How and when each address opted in is carried over rather than re-dated to today, because a consent record saying somebody agreed on a day they did not is precisely the thing a deliverability review would be shown. People who had unsubscribed stay unsubscribed in the copy; a duplicate is not a way back through a door somebody closed.

Refresh data recounts on demand. It only exists because the counts are now cached - before, they were recalculated on every page load, and a refresh button would have done nothing visible and taught you to ignore it. The cache is also why the Lists page stopped being slow: a workspace with ten segments over fifty thousand records was re-evaluating all ten, in full, every time you opened it. Sending never reads the cache - a campaign always works out its audience fresh, at the moment it goes.

And Export CSV gives you the whole filtered list with the columns you have chosen, not the page on screen.

The email field moved to the object

A list used to declare which field it sends to. That meant five lists of contacts each stored their own answer and could quietly disagree about the same person’s address. Which mailbox belongs to someone is a fact about your contacts, not about one list of them - so it is now set once, per object, in Settings → Objects & fields, and lists use it. A list can still override it for the rare case that genuinely differs.

Existing lists keep their own setting and send exactly where they always did. Nothing moves on its own.

New lists can only be created on something with an email field, with a note saying where to add one. Before, you could make a list nothing could ever reach, and the only symptom was a campaign that went to nobody.

Deleting that field is refused, not obeyed

If a marketing list sends to a field, deleting the field is blocked, and the dialog names the lists. A list that merely filters on it is a warning instead - a deleted field reads as empty, which is a visible, understandable outcome.

This is deliberately not a cascade. Deleting a list takes its members with it, and those rows carry the consent record for every address on it - the answer to “how did you build this list?”, which cannot be recreated. A mis-click in settings should not be able to erase that for a few thousand people and cancel live campaigns on the way out. If an administrator forces the delete anyway, dependent lists are pointed at the object’s next address field, or paused where there is none - never deleted. A paused list refuses to be scheduled, by name and with the reason, instead of quietly sending to nobody.