Ask which customer account stays active when the language changes
A portal language selector changes presentation. It should not silently change which organization a signed-in person is acting for. This distinction becomes important when one person legitimately works with more than one customer account and those accounts have different preferred languages.
The fictional example below concerns user U-26, who is authorized for accounts A-7 and A-9. A-7 normally communicates in French and A-9 in Dutch. The person is reviewing A-7's request Q-81 and chooses Dutch because that is more convenient for this task. The intended result is the same authorized A-7 request presented in Dutch, not a switch to A-9.
Separate three choices in the specification
The first question is which identity is signed in. The second is which authorized account is active. The third is which language presents the current task. Those values may influence defaults, but they should not be collapsed into one choice without a deliberate business rule.
The team writes the expected state before touching the interface: U-26, active account A-7, request Q-81, language Dutch. It also identifies a control request Q-92 belonging to A-9. Both records use fictional data and have distinct references even if their displayed descriptions are similar.
The specification asks whether changing language preserves unsaved work, whether the current subject has a real counterpart and what happens when it does not. A language switch that discards an edited explanation can be harmful even when permissions are otherwise correct.
Investigate the observed account change
In the first test, U-26 opens Q-81 under A-7 and chooses Dutch. The navigation handler finds the user's “Dutch account” and sets A-9 as active before rendering the next page. The user remains authorized for A-9, so a simple access-denied check does not expose the problem. The interface has performed a valid but unintended account change.
The evidence is the before-and-after state, not a claim that another customer's records have leaked. The fixture user can legitimately access both accounts. The defect is that a presentation action has changed business context without an explicit account choice.
The team corrects the handler so the language action preserves the selected authorized account and request. The account selector remains a separate action with its own visible label. The account's default language is used only at the agreed entry point, not as a command to select another organization.
Test both authority and intent
After the change, Q-81 remains under A-7 when the interface becomes Dutch. Its request reference and entered explanation are preserved. U-26 can still explicitly switch to A-9 and open Q-92 through the account control. Returning to French within A-9 does not silently move the person back to A-7.
A second test user U-27 is authorized only for A-7. Changing language does not reveal A-9 in the account list, and a direct attempt to open Q-92 remains denied through the application's actual authorization path. This control addresses permission boundaries that the two-account user alone could not prove.
The reviewer also checks a missing translation. The page offers the agreed clearly labeled alternative while retaining the active account; it does not use the missing locale as a reason to select a different customer.
Turn the answers into a maintainable rule
The resulting rule is precise: language changes presentation, explicit account selection changes the active authorized account, and every record action still enforces its own permission check. The team records the relevant defaults without treating a stored language preference as authority to view data.
These questions belong before implementation because a polished selector can conceal a confused data model. Customer portal development can define identity, account membership and document access together. The language adaptation guide covers a different problem: preserving the same public service when switching among translated pages.