How would you prefer to be contacted?

This is what we use when something new is set up. It only applies from now on, so nothing you already receive changes on its own.

Also change these to text message?

Communications we can move

Tell me when my new bill is ready

Currently email

Direct Debit reminders

Currently email

Roadworks and disruption near me

Currently email

We need to ask you separately about these

You gave us permission to send these a particular way. Permission to contact you by email is not permission to contact you by text message, so we ask again rather than moving them with the rest.

Council Tax support and discounts — currently email

Council Tax bills and recovery notices, Camden libraries newsletter are not available by text message, so they stay as they are.

Why is this a question at all?

Every communication carries its own channel, decided when it was set up. That makes the record honest — we can always say why a message went where it went — but it means a later change of mind does not travel on its own. Asking is the whole fix, and it is a screen, not a rule.

Behind the scenes

Property names follow docs/profile-communication-subscriptions.md, which says its own spelling is illustrative. The shape is what was decided.

Usable destinations

email: no usable destination
sms: no usable destination
post: usable
in-app: usable

Seeded by seedChannel() against this fixture — §4.1, the one communication rule with real logic behind it here.

Subscriptions

subscriptionId: sub-ct-billing
catalogueTopicId: council-tax.billing-and-recovery
state: active
basisAtOptIn: statutory
noticeVersionAgreed: — nothing was agreed
channel: post
channelSource: catalogue-fallback
createdBy: Service
captureChannel: service-api
createdAt: 2026-06-29T08:02:00Z
context: {"originatingService":"council-tax","accountReference":"CT-4471902"}
deliveryIssue: none

subscriptionId: sub-ct-bill-ready
catalogueTopicId: council-tax.bill-ready-alert
state: active
basisAtOptIn: public-task
noticeVersionAgreed: v1
channel: email
channelSource: catalogue-fallback
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-02T09:20:00Z
deliveryIssue: We do not have a confirmed email address to send this to.

subscriptionId: sub-ct-direct-debit
catalogueTopicId: council-tax.direct-debit-reminder
state: active
basisAtOptIn: public-task
noticeVersionAgreed: v1
channel: email
channelSource: explicit
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-02T09:21:00Z
deliveryIssue: We do not have a confirmed email address to send this to.

subscriptionId: sub-ct-support
catalogueTopicId: council-tax.support-and-discounts
state: active
basisAtOptIn: consent
noticeVersionAgreed: v2
channel: email
channelSource: explicit
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-02T09:22:00Z
deliveryIssue: We do not have a confirmed email address to send this to.

subscriptionId: sub-libraries
catalogueTopicId: libraries.newsletter
state: active
basisAtOptIn: consent
noticeVersionAgreed: v3
channel: email
channelSource: explicit
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-14T18:40:00Z
deliveryIssue: We do not have a confirmed email address to send this to.

subscriptionId: sub-highways
catalogueTopicId: highways.local-disruption
state: active
basisAtOptIn: public-task
noticeVersionAgreed: v1
channel: email
channelSource: catalogue-fallback
createdBy: Citizen
captureChannel: my-account
createdAt: 2026-07-20T11:05:00Z
context: {"scope":"address","addressValueId":"ad-ctax"}
deliveryIssue: We do not have a confirmed email address to send this to.

Not modelled

Expiry, withdrawal history and officer-captured consent. Examples 6.3, 6.6, 6.7 and 6.8 are not fixtures, so nothing renders them.
What happens to a Subscription when the contact value it depends on is removed. Phase 1 sends to the primary confirmed destination for the channel, so there are no per-Subscription pointers to repair.
The material-change flow that forces re-opt-in. §5 lists the event; no owner and no journey exist for it.