User Journey: Change someone's details

"I want a colleague's record to be right, without waiting for them." The tenant administrator corrects a colleague's profile, photo and contact details, usually after a move, a name change, or a data-quality report. The journey is done when the colleague's screen reads correctly and the correction is on the record with a reason.

The tenant administrator: an account that holds iam::accounts:update and iam::account_contact_informations:write inside its tenant. The trigger is a support request, a joiner correction, or a data-quality review. It starts when the administrator finds the colleague on Change someone's details, and ends when they leave it.

This journey runs the same screen as the two member journeys, with two differences. The administrator first chooses the person, and the permission check passes. That is the whole difference: the member sees the screen and cannot save; the administrator sees the same screen and can. The member journeys are Present myself and Keep my details current.

1. Find the person. The administrator searches for the colleague by username or name. The system lists the matches inside the tenant.
2. Open the record. The administrator picks a person. The system shows the same screen the member sees: photo and identity on the left, contact details beside them, both editable.
3. Correct the profile. The administrator edits the full name, job title and reporting line, and picks a new photo. The reporting line must be another account in the same tenant.
4. Correct the contact details. The administrator edits the street, city, postcode, telephone, contact email and web page.
5. Save. The system asks why the record changed, records the reason, and writes a new version of the account and of the contact record. Because two records change, the screen shows both new versions.
6. Leave. The administrator goes back to the directory. The colleague's screen now reads correctly.

One screen, and it is the member's screen with a person search above it. The photo and identity panel and the contact details panel are the same two panels in both journeys; this journey only adds the picker that chooses whose record is in view.

The picker reads account through the list operation that the directory journeys also use. The contact panel is the same entity the member journeys edit; only the caller and the permission differ.

Both write subjects need a permission the administrator holds. iam.v1.accounts.update needs iam::accounts:update, and iam.v1.account_contact_informations.put needs iam::account_contact_informations:write. The tenant-administrator role holds both, which is what makes this journey exists where the member's journey is partial. The account subjects come from ores.iam.account_messages, and both writes carry the shared change intent.

1. No image upload. The administrator can set image_id, but nothing puts a new image there: the BFF serves /api/images and /api/images/:id as reads only. The candidate is an upload path into ores.assets that returns an image id. Until it exists, the picker can only offer images the tenant already holds.
2. Two records, two writes, no single save. The profile and the contact details live in different records, so one Save sends iam.v1.accounts.update and iam.v1.account_contact_informations.put as separate requests, and nothing makes the pair atomic. Until a composite operation exists, the screen must send both and say which record failed.
3. Two email fields. account.email is the colleague's login address and account_contact_information.email is the contact address. iam.v1.accounts.update writes the first and the contact put writes the second, so the screen must label them, or the administrator changes the wrong one.

• Present myself — this is the same screen as the person sees it, so an administrator goes there to check what they will see.
• Keep my details current — the contact half of this screen, which the person keeps for themselves when they can.
• See who has access — the roster is where the person is picked, and it shows the roles this screen does not.
• Change someone's access — the access half of the same colleague record, changed from the same place.
• Draw the reporting line — the reporting line is a field on this screen, and the tree shows the shape it sits in.

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

• User Journeys