Live
Give access a visible boundary.
A portal owner needs to answer a precise question: can this person see a whole portfolio, or only selected partners inside it? The difficult part is making that reach clear before a grant is saved.
My contribution
I led the portal’s product structure, interaction direction and delivery, and personally designed the access-editor experience shown here. Kenneth Fallon collaborated on the wider portal. The interface combines a financial dashboard, capital workflows and portfolio-scoped access.
Why the access model changed
The repository documents an earlier approach with separate portfolio and partner lists. A partner could be selected without its portfolio, and the grant could not clearly express “this portfolio, but only these partners”. That is the design constraint behind the current editor.
The current model starts with a portfolio and nests its partners underneath it. An unrestricted portfolio grant includes its partners; choosing specific partners narrows the grant. This keeps the business context attached to the selection.
Make the person and their reach visible
The register brings people, granted scope, role and status into one view. Portfolio, partner, role and status filters support a concrete operational task: finding who can see a particular part of the business.
Separate authority from scope
The editor distinguishes an internal administrator from a scoped portal user before asking what they can see. Portfolio-first selection keeps partner choices in context, while the reach summary shows what the selection adds up to. The administrator can inspect the result before saving.
Keep the register in view
Editing opens a side panel rather than replacing the register. Access management has its own page instead of sitting among display preferences. The repository also separates navigation visibility from server-side authorization: hiding a link is not the access boundary.
The same scope across the product
The dashboard carries one financial-data source through the filters, KPI row, chart and table. The capital area follows offers through application, disbursement and remittance states. A shared filter model keeps the selected business context consistent as the user moves through these views.
What this demonstrates
The delivered workspace makes financial information and access management available in one product. This case shows the interaction model and implementation; no retained usability study or measured reduction in reporting effort, support demand or permission errors is available.
Capture notes
Actual repository components rendered with fictional people and figures on 1 November 2026. No live merchant data or services were used. Capital is shown as a component preview, without a claim that every illustrated feature was available in production. Platform: Next.js, Cloudflare and AWS Cognito. Kenneth Fallon is credited for wider portal collaboration.
