How you prefer to be contacted
- Format
- Standard
- Accessibility needs
- None recorded
Your preferred way of being contacted is used when something new is set up. It does not change anything already set up — we ask you about those separately when you change it.
2 of your current communications use it.
Large print, easy read and interpreters
Recorded here, but nothing in this design decides how an accessibility need reaches the thing that actually sends the message. That is a gap, not a screen we have left out.
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
- 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
- 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
- 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
- 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
- none
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.