All scenarios

Wireframe Not agreed. Screens illustrate proposals in docs/ and .scratch/ , and invent the states those documents leave open.

Back to your communications

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.

You can choose post if you would rather have letters for everything.

Also change these to text message?

Communications we can move
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
usable
sms
usable
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
sms
channelSource
preferred-seed
createdBy
Citizen
captureChannel
my-account
createdAt
2026-07-02T09:20:00Z
deliveryIssue
none
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
none
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
none
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
none
subscriptionId
sub-highways
catalogueTopicId
highways.local-disruption
state
active
basisAtOptIn
public-task
noticeVersionAgreed
v1
channel
sms
channelSource
preferred-seed
createdBy
Citizen
captureChannel
my-account
createdAt
2026-07-20T11:05:00Z
context
{"scope":"address","addressValueId":"ad-ctax"}
deliveryIssue
We are not sure which address this should cover any more.

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.