---
id: USER-WP-0036
type: workplan
title: "Show allowed and active access on the account page"
domain: communication
repo: user-engine
status: ready
flavor: extension
owner: grok
topic_slug: user-engine
created: "2026-09-26"
updated: "2026-09-26"
related: [USER-WP-0026, USER-WP-0028]
state_hub_workstream_id: "2d182130-88d0-5b17-b2bf-3e28f5df4f37"
---

# USER-WP-0036 - Account situational awareness

The signed-in account page mixes three different facts. The verified token
names the tenant this sign-in is using. A portal membership row is access the
portal has recorded. A tenant account written on first sign-in is neither.

On 2026-09-26 a directory sign-in for `tenant:trial:demo-company` had a portal
tenant account, no membership rows, and company admission from the directory
group on the token. The account page showed that token tenant under "Tenant
access" and then "No tenant memberships yet." Workload access listed nothing,
because the page only reads memberships whose scope is an application,
service, workload, or asset. The company application does not consult that
list.

A person may hold access to more than one tenant and more than one workload.
An ordinary session uses one tenant at a time. Vendor roles, administrators,
and a person hired by more than one vendor may have more than one tenant
active, and each active tenant stays visible. Allowed access and active
access are both shown. Login state is shown separately from either list.

Allow, deny, and unavailable workload decisions stay with USER-WP-0026-T03
and USER-WP-0028-T02. This plan does not infer those decisions.

## Separate login state, active access, and allowed access

```task
id: USER-WP-0036-T01
status: todo
priority: high
state_hub_task_id: "ffc8f42f-5ca3-56a2-8850-d2da9beba72c"
```

On `/onboarding`, and in the signed-in home identity block, present three
labelled situations in ordinary language.

Login state names the verified portal identity, or says the portal session is
absent. Say that this is the portal session and that an application can keep
its own session. Do not infer identity from the URL.

Active now is this verified token: its tenant, roles, and directory groups.
An ordinary session has one active tenant. A tenant administrator,
platform operator, platform root, vendor role, or multi-hire membership may
have more than one tenant active, and each one is marked. Until the account
carries one of those exception roles, show a single active tenant. Do not
invent a new role catalogue to detect the exception.

Allowed access is portal membership rows for this user. A tenant membership
shows the tenant and kind. A workload membership is only a row whose scope is
application, service, workload, or asset. An empty list says that nothing is
recorded. A tenant account created on first sign-in is not a membership. The
token tenant is not repeated as a membership. Remove the "Viewing <tenant>"
line that currently does that.

A workload with no catalogue decision is "not checked." That is neither
access nor a denial. Do not copy a successful application login, a directory
group, a platform role, or a tenant account into a membership to fill the
list.

The observed case renders as: signed in, one active tenant taken from the
token, no allowed tenants, no allowed workloads, workload decisions not
checked. Keep the layout readable on a phone.

## Change the active tenant only through sign-in

```task
id: USER-WP-0036-T02
status: todo
priority: high
state_hub_task_id: "136a27ff-fd3e-5f0a-8a3a-bb080f1965d5"
```

An ordinary user changes the active tenant through the existing
reauthentication handoff, `/login?tenant_hint=`. The identity provider
replaces the token tenant. After return, the page shows that tenant as the
only active one and leaves other allowed memberships inactive.

An exception role may show more than one active tenant. Those tenants still
come from verified sign-in context. Do not add a control that marks a second
tenant active inside the portal session alone. Recognize only roles and
membership kinds the account already stores: `tenant-admin`,
`platform-operator`, `platform-root`, and a vendor or multi-hire kind when
one is already recorded.

Switching tenant does not claim to end application sessions. The existing
sign-out copy remains the place that explains a remaining shared sign-in.

## Record the journey and prove the three situations

```task
id: USER-WP-0036-T03
status: todo
priority: medium
state_hub_task_id: "4c9b0600-5034-58ce-9b02-90a040f6f65f"
```

Update `docs/account-journeys.md` U01 and U09 so login state, active access,
and allowed access are the contract. U10 keeps explicit reauthentication as
the tenant switch.

Add portal tests for signed-out, a token tenant with no membership, an
allowed tenant that is not active, a recorded workload membership, and an
exception role whose verified context has two active tenants. Assert that a
tenant account alone does not appear as allowed access, and that an absent
catalogue decision renders as not checked.

Do not close USER-WP-0026-T03 or USER-WP-0028-T02 from this plan. They remain
the owners of allow, deny, and unavailable workload decisions.