--- title: "The Multi-Role Member Problem Every Association Portal Ignores" url: https://www.axelerant.com/blog/multi-role-member-portal-problem published: 2026-07-23T10:00:00Z author: "Bassam Ismail, Director of Digital Engineering" source: Axelerant Thinking --- # The Multi-Role Member Problem Every Association Portal Ignores > Association portals fail when one interface serves six member roles. What discovery interviews revealed, and the sequence that actually fixes it. Ask an association's support team where the calls come from. It is rarely the public website. It is the portal: a certified instructor who cannot find the form they submitted last year, an employer admin updating a roster through a spreadsheet upload, a learner staring at a dashboard built for someone else's job. The instinct is to call this a design problem and commission a redesign. It usually is not. It is a role problem, and it sits deeper than the interface. ## What The Interviews Actually Showed During discovery for a large membership and certification organization, we ran interviews across every user group the platform served: learners, instructors, evaluators, training providers, employer admins, auditors. One finding repeated in almost every session. Nearly every participant had access to portals outside their actual role. They never explored those sections on their own. When we prompted them to click during the session, the pages came up blank or broken, because the person was never supposed to be there. The experience read as broken even where the underlying system worked. Trust in the whole platform eroded from sections the user should never have seen. The second pattern: the same person holds multiple roles, and the platform had no concept of it. An instructor completing their own recertification is a learner that day. An employer admin registering staff is sometimes registering themselves. The portal forced one identity onto people whose relationship with the association changes by task. The third: post-login landing was inconsistent. Log in from the homepage, land one place. Log in from an account link, land somewhere else. Small on paper. In the interviews, it was the single most disorienting moment in the journey. None of this shows up in a visual audit. All of it shows up in ten user interviews. ## Why The Redesign Reflex Fails A redesign repaints the doors. The paths stay broken. New navigation on top of the same flat role model produces a prettier version of the same confusion: everyone still sees everything, multi-role members still have no way to switch context, and the blank pages just get a nicer 404. The deeper reason redesigns fail here is structural. Role information usually lives in the association management system, not the website. If the rebuild does not decide, deliberately, how roles flow from the AMS into the web platform and what each role is allowed to see, the new site inherits the old confusion on day one. ## The Order That Works Map the roles before the journeys. Not the org chart's version, the operational one: which roles exist in the AMS, which combinations actually occur, and what job each role comes to the portal to do. This is [UX Research](https://www.axelerant.com/what-we-do/design/ux-research) doing its work, and it is the cheapest step to get right and the most expensive to skip. Design one journey per role, then design the switch. For the organization above, the durable answer was an active role system: the platform knows every role you hold, one is active at a time, and a visible switcher changes your menus, your dashboard, and your permissions together. Multi-role members stopped guessing which version of the site they were in. Let the system of record stay the system of record. Identity, certifications, and role assignments belong in the AMS. The web platform reads them at login, maps them to its own access model, and never forks the truth. Each experience the member touches should generate clean data back into that record, not a parallel copy of it. Migrate by audience, not by page count. Public content first, then one role's portal at a time. Every phase ships something a real user group can validate, and role-based defects surface while they are still cheap. ## What This Looked Like In Practice The organization above replatformed from a legacy CMS onto a modern open-source platform with the AMS as the identity provider. Role attributes arrive at login and map to platform roles automatically. Menus, dashboard blocks, and content visibility all key off the active role rather than the union of everything a person holds. The blank-page problem did not get styled better. It became structurally impossible, because access to a section outside your active role does not render at all. The build ran public site first, then portals audience by audience, with the association's own stakeholders validating each role's experience before the next began. That is [Platform Engineering](https://www.axelerant.com/what-we-do/engineering/platform) work, but the decisions that made it succeed were made in the research phase, months before the first sprint. ## The Honest Edge An active role model does not solve role governance. Someone at the association still has to own which roles exist, who grants them, and when they expire, and that is an operational discipline no platform enforces for you. It also adds a real cost: every new feature must now be reviewed against every role, which slows delivery slightly and forever. That trade is worth it. It is not free. And role clarity does not fix content that was never written for the role reading it. If your instructor resources are written for administrators, the right portal will deliver the wrong page perfectly. ## What Compounds Associations that organize the platform around roles get something durable: every new program, credential, or member type slots into an existing model instead of forcing another one-off portal. The support queue shifts from "I'm lost" to questions worth answering. If your portal serves more than two roles and your support team can predict the complaints, start with the role map, not the redesign brief. That work lives in how we approach [the experience layer](https://www.axelerant.com/how-we-do/experience). --- Read on the web: https://www.axelerant.com/blog/multi-role-member-portal-problem