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.ops.update_account 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.ops.update_self_account, 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/:id as a read 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 shows both, labelled apart: the first is the address a person signs in with and the second is the address colleagues use, and neither reads as the other. (Product owner, 2026-09-30.)
5. Closed: the self read. The account read needs iam::accounts:read, which the default Viewer and Member roles do not hold, so a plain member's read of their own account was refused. iam.v1.ops.get_my_account answers the caller's own account with no account id and no permission, and it is on the allow-list of Authorised reads. The web server sends a request that names the signed-in person's own username to it, so the shell, the profile and the person page read the member's own name, picture and job title. (2026-10-10.)
6. Closed: the self write on a tenant with accounts. Step 4's save lands: the generated insert trigger validates modified_by above the version replace, so the actor's row is still current when the validator reads it, and the write whose actor is the account written no longer raises Invalid modified_by (23503). (Fix the self write refusal on a tenant with accounts; end-to-end run, 2026-10-05.)
7. An upload over the message fabric's payload cap. Step 2's photo replace cannot carry an image over roughly three quarters of a megabyte: the deployment's NATS takes the default 1 MB cap, the base64 body grows by a third, and the transport raises MAX_PAYLOAD_EXCEEDED (http 503) before the validator's own image_too_large answer can be reached. Captured at A profile image over the payload cap cannot reach the validator; the direction is HTTP storage for an upload larger than 1 MB. (End-to-end run, 2026-10-05.)

• 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