Active-Company Resolution Team-Precedence Automation: The Same Bug, Independently Caught a Second Time

A person who belongs to several organizations inside the same product isn't an edge case in a system built for organizations that serve multiple clients — it is a completely ordinary situation for staff. The moment more than one organization is a valid possibility, some piece of code has to decide which one to open by default, and that decision either reflects how the person actually uses the product — as staff, most of the time, at the organization they work for — or it reflects an accident of list order that has nothing to do with their actual role.

It's natural to build and test the "remember what I chose last time" path first, since it is what a returning user experiences on every visit after their first — and once that path works, it's easy to treat the code as complete. The fallback used before any choice is remembered, or after that memory is cleared, gets exercised far less often in normal testing, which is exactly the gap where "just take the first item in the list" quietly becomes the actual behavior for a specific, real situation that testing didn't specifically construct: a person genuinely belonging to more than one organization under two different kinds of role.

The incident was concrete and dated: an internal admin who was also a client-portal contact on a separate, older organization opened Centriu Maestro and landed on that older organization — seeing a client's own view rather than their own staff permissions and data, with the interface giving no indication that a choice had even been made, let alone which one. The resolution logic that decides which organization to open was checking, first, whether the person had a remembered choice from a previous session that still matched one of their current memberships — a correct and working check — and falling back, whenever that check found nothing, to simply the first membership in an unordered list. Nothing in that fallback distinguished a genuine team or staff role from a client or client-contact role; it took whichever came first, and for this specific person, that happened to be the older client-portal organization.

The fix inserts a real preference into exactly that fallback path: a small check that classifies a membership as "team" whenever its role is anything other than client or client-contact, and looks for a team membership BEFORE falling all the way through to an arbitrary first entry. The result is a three-step resolution, in order: a remembered organization from a previous session, if one still matches; otherwise, an organization where the person holds a genuine team role; and only if neither of those applies, the first membership on record. The fix is deliberately narrow — eight lines, touching only the fallback step, leaving the already-correct "remembered choice" behavior completely untouched.

Worth stating plainly, because the commit that fixed this says so directly: this is the identical defect class already found and fixed once before, in Centriu Link's own, completely separate authentication code. That earlier fix did not, and structurally could not, protect Maestro — the two products maintain their own independent implementations of the same underlying concept, with no shared code between them at this layer. Finding and closing the same category of gap here required looking at Maestro's own logic specifically, on its own terms, rather than assuming a fix made once somewhere else had already covered every place the same idea appears.

A staff admin at one organization is also, separately, a registered client-portal contact at a different, older organization they were once associated with. Before the fix, opening the application with no remembered organization from a previous session landed them on whichever of the two happened to be first in an unordered list — in the reported case, the older client organization, with a client's own limited view rather than their real staff access. After the fix, the same person lands on the organization where they hold a genuine team role, by design rather than by list order.

A person who belongs to more than one Centriu Maestro organization under different kinds of role — most commonly staff who are also a client-portal contact elsewhere — now opens the application on an organization matching their actual working role by default, the first time and every time their remembered choice doesn't apply, rather than on whichever organization happened to be returned first.

This fix addresses which organization opens by DEFAULT when more than one applies — it does not change what a person can see or do once they've switched to a different organization through the product's own organization switcher, which remains under the platform's existing access controls. It is also specific to Centriu Maestro's own authentication context; a similar-sounding issue in a different Centriu product runs on independent code and is not affected by this fix.

Falling back to "the first item in the list" when no explicit choice has been made looks harmless because it always returns something valid — every organization in the list is one the person genuinely belongs to. The gap only becomes visible for a person who belongs to organizations under meaningfully different roles, where "first in the list" and "the one they actually work at" are not the same thing. Centriu Maestro's fix replaces that arbitrary order with a stated, checked preference for a genuine team role.