User Journey: Present myself

"I want the system to show me as I actually am." The member sets the photo, name, job title and reporting line that other people see. The journey is done when the member's own screen reads correctly, and the next record they touch carries the right name in its provenance.

The member: an account of type user, signed in, acting on their own record. The trigger is the account menu, or a nudge to supply a photo. It starts when the member opens My profile, and ends when they leave it.

This is the self-service half of the profile topic. An administrator runs the same screen for somebody else — see Change someone's details.

1. Open my profile. The member chooses My profile from the account menu. The system shows one screen: identity and photo on the left, contact details and sign-in state beside them.
2. Replace the photo. The member picks a new image. The system shows the current picture, opens the shared image picker, and previews the new picture at the size other screens will show it.
3. Correct the identity. The member edits the full name and job title. These are the fields that appear in provenance, so a correction here changes how history reads.
4. Save. The system asks why the record changed, records the reason, and writes a new version. The screen shows the new values and the new version.
5. Leave. The member goes back. The account menu now shows the new name and photo.

One screen. The photo, the identity fields, the contact details and the sign-in summary are panels of that screen rather than separate screens, because the member thinks of them as one thing.

Two panels are read-only here and belong to other journeys: the contact details are Keep my details current, and the sign-in summary is Protect my account.

iam.v1.accounts.update exists, but it needs iam::accounts:update, which is 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 change their own profile. The candidate is iam.v1.accounts.update-self, restricted to the caller's own account and to the fields a member owns: full_name, job_title, image_id, and the contact record.
2. No image upload. The BFF serves /api/images and /api/images/:id as reads only. Nothing uploads a new image, so the photo cannot be changed at all. The candidate is an upload path into ores.assets that returns an image id.
3. No size or format rule. Nothing states the accepted image formats or the maximum size, so the picker has nothing to enforce.
4. Two email fields. account.email and account_contact_information.email both exist. The screen must show one, and which is authoritative is undecided. This is a modelling error the journey exposes.

• Keep my details current — the contact panel sits on this screen, and the address and telephone are edited there.
• Protect my account — the sign-in summary is a read-only panel here, and the password and sign-in state live there.
• Change someone's details — an administrator runs this same screen for a colleague, so a person goes there when the record is not their own.
• Draw the reporting line — the reporting line is one of the identity fields here, and the tree shows the shape it makes.

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

• User Journeys