User Journey: Keep my details current

"I want the system to reach me at the right address." The member keeps the address, city, postcode, telephone and web page that colleagues and the system use. The journey is done when the contact panel reads correctly, and the member stops having to correct a colleague who used an old number.

The member: an account of type user, signed in, acting on their own contact record. The trigger is a move, a new telephone number, or a nudge when a record looks stale. It starts when the member opens My details, and ends when they leave it.

This is the contact-details half of the profile topic. The identity half is Present myself. An administrator runs the same screen for somebody else, with permission, in Change someone's details.

1. Open my details. The member chooses My details from the account menu. The system shows one screen: photo and identity on the left, contact details beside them.
2. Read the current record. The system loads the member's own account and the single contact record attached to it, and fills the panel with the current street, city, postcode, telephone, email and web page.
3. Correct the address. The member edits the street lines, city, postcode and country. The system validates the country against the tenant's country list.
4. Correct how to reach me. The member edits the telephone, the contact email and the web page. The system keeps the contact email separate from the login address.
5. Save. The system asks why the record changed, records the reason, and writes a new version of the contact record. The panel shows the new values and the new version.
6. Leave. The member goes back. Nothing else changes, because the member does not change their own identity here.

One screen. The photo and identity form one panel and the contact details another, because the member reads them together even though only the contact panel is editable here.

The identity panel is read-only here and belongs to Present myself, because a member does not change their own name or job title from this journey.

The account subjects come from ores.iam.account_messages. The contact subjects are derived from the account_contact_information entity model, and iam.v1.account_contact_informations.put carries the same shared change intent as the account write.

iam.v1.account_contact_informations.put exists, but it needs iam::account_contact_informations:write, a tenant-administrator permission. A member cannot call it for their own record. So partial here means the operation exists and the caller may not use it.

1. No self-service update. There is no subject for a member to write their own contact record. The candidate is iam.v1.account_contact_informations.update-self, restricted to the caller's own account and to the fields a member owns. Until it exists, the screen must show the contact panel read-only and say that a tenant administrator makes the change.
2. No image upload. If the screen shows the photo, the member cannot change it: the BFF serves /api/images and /api/images/:id as reads only, and nothing uploads a new image. The candidate is an upload path into ores.assets that returns an image id.
3. Two email fields. account.email is the login address and account_contact_information.email is the contact address. The member can change the first through iam.v1.accounts.update-email, but not the second. The screen must label them, so the member does not expect one to change the other.

• Present myself — the identity panel is read-only here, and the name, job title and photo are edited there.
• Choose where I work — the parties panel sits on this screen, and the party a person acts for is chosen there.
• Protect my account — the login address and password are account credentials, not contact details, so they are changed there.
• Change someone's details — an administrator edits the same contact panel for a colleague who cannot do it themselves.

• Identity and Access Management
• How do I add a PlantUML diagram?
• Profile journeys

• User Journeys