Portals as doors

Under the Access section a Portal is a door. It decides who may come in - and nothing else. Which assets a visitor can use is decided entirely by the groups they belong to and what those groups are assigned to. Every visitor signs in first: there is no anonymous use of a Portal.

Admission

The Access page holds two settings, and the door is inferred from them:

• Admitted groups - the groups allowed through this door. A plan counts as a group here, so you can admit "everyone subscribed to Pro". With no Storefront attached, only members of a ticked group get in, and an empty list admits nobody. Name groups to make a private door - a workforce Portal that admits only Internal Team, say.
• Self-service - attach a Storefront and the door is open: anyone may sign in and pick a plan there. Admitted groups add nothing to an open door; they still decide what their members reach once inside.

An email that is not an existing admitted user of a private door gets Invalid login before a code is ever sent, so the Portal reveals nothing about itself. A visitor who is admitted but whose groups reach nothing sees a named empty state with a way to switch account or, when a Storefront is attached, a link to its offers.

Signing in grants nothing

Creating an account at a Portal puts the user in no group. They reach only what an admin has assigned to a group they belong to, or what a plan they picked on the attached Storefront unlocks. Removing someone from a group takes effect on their next request. There are no automatic "default groups" for new sign-ins.

Attached Storefront

Attach one Storefront under Self-service. This is how a Portal sells: the sign-in screen gains a Sign up button to the Storefront, and a signed-in visitor who holds no plan is offered it. If the Storefront has a default $0 plan, new sign-ups start on it straight away; otherwise they choose a plan first. Leave it empty for a private door.

The Portal list shows a Storefront column - the attached Storefront's name, or "Sign-in only".

A locked door

Saving a private Portal whose admitted groups reach nothing, or whose list is empty, warns you: nobody could use anything past this door. Fix it by assigning the groups to an asset, admitting a group that already has assignments, or attaching a Storefront.

What moved out of the Portal

• The product picker and portal defaults - assets are no longer added to a Portal. Replace a former default with a $0 default plan on the attached Storefront, which every new sign-up starts on.
• The Plans tab - offering happens on a Storefront.
• Anonymous access - every Portal requires sign-in. A visitor verifies their email before anything renders.
• Require plan selection - a door with an attached Storefront and no $0 default forces the pricing screen by construction.

The previous layout

Before the switch, a Portal carried its own product list ("defaults" everyone past the door could use), a Plans tab that attached plans from the catalog with a default and hidden flags, and an access policy with an anonymous-access and a require-plan-selection switch. All of that is expressed now as groups assigned on the asset plus the door settings above; the migration note covers the one behavioural difference for sellers.