Role Configuration Admin
PortalRoleAdmin is the administration page for portal roles: which roles the portal has, and which of them a newly registered user is given. It ships with the framework on both stacks, so a portal picks up improvements to it by updating its packages — the page you write is the role gate and the heading.
What's on the page
Two grids, each with New, Open and Delete. Every change is written as soon as you save or delete it — there is no page-level Save.
- Portal roles — a name and a description, edited in a side panel. What a role grants is not configured here: it is bound to the role's name in code at startup, so adding a role makes it assignable rather than powerful, and renaming one detaches it from what it grants.
- Role configurations — which role a newly registered user is given, and when — to nobody, to everybody, or to whoever matches a rule you write.
Rules that decide who qualifies
A rule is a FetchXML query over contact. When someone registers, the portal narrows the query to that contact and assigns the role if Dataverse returns them. Joins to related tables are honoured, and columns, sorts and top make no difference to the answer, so a query copied from a view works as it is.
In React the rule is written with the FetchXML query builder, pinned to Contact with aggregates switched off, on a page of its own so the builder has room. Run shows the contacts the rule matches today — the only way to find out whether it selects the people you meant.
In Blazor the same column is edited as FetchXML text; there is no Blazor query builder yet.
A broken rule fails quietly
A rule that is empty, is not valid FetchXML, is an aggregate query, or is rooted in a table other than Contact matches nobody. Nothing reports it as an error — the role is simply never assigned. The React editor warns about each of these above the builder while you write the rule.
Adding it to your portal
Both project templates already include this page at /RoleConfigurationAdmin, under the Admin menu. To add it yourself, gate a page on the SystemAdmin role and drop the component in:
The configuration page (React)
configurationUrl opens a configuration on its own page instead of in a side panel. Leave it off and the panel is used, which works but leaves the query builder little room. The page it points at supplies the record context and the Save button; the form itself is the framework’s PortalRoleConfigurationForm:
Web roles under enhanced authorization
On a portal running enhanced authorization, users are given Power Pages web roles rather than portal roles: Power Pages grants each user the Dataverse security role it pairs with each of their web roles, and what that role allows comes from the site's table permissions. WebRoleAdmin is the counterpart of PortalRoleAdmin for that model — one grid of rules, each handing a web role to every new user or to those matching a rule written exactly as above. The rules live in the Power Portals Pro Enhanced Authorization solution, which needs Power Pages installed in the environment.
Both project templates show whichever page applies: the Admin menu offers Web Role Configuration when enhanced authorization is on and Role Configuration when it is off. Your own navigation can make the same choice with ISecurityModelInfo.IsEnhancedAuthorizationEnabledAsync() in Blazor or useAuthOptions() in React, both answered from GET /api/auth/options.
The web roles themselves live in Power Pages
Create web roles, and give them table permissions, in the Power Pages Management app — this page only decides who gets them. A web role with no paired security role grants nothing until Power Pages pairs one, and a web role belonging to a different site than the portal's is skipped; the portal logs both. Role and privilege changes can take a minute or two to reach a signed-in user.