Power Portals Pro

Create a certificate in Key Vault whose private key can never be exported, and add its public half to an existing app registration, so the app can sign in with no secret anywhere. The vault signs each sign-in instead, for whoever holds Key Vault Crypto User on it — connect an environment that way with `dnx PowerPortalsPro.Mcp login --client-id <id> --certificate <url>`. Also how to rotate: run it again with the same certificate name and a new version is created and added; the old one keeps working until removed with remove_app_registration_certificate. Creating needs Key Vault Certificates Officer on the vault; this tool grants no vault roles itself. NOT idempotent: every call creates a new version. The user is asked to confirm.

Make an app registration accept a user-assigned managed identity's token in place of a secret (a federated credential), so a portal hosted in one tenant can sign in to Dataverse in another as that registration with no secret at all. The registration and the identity must be in the same tenant, and the registration must be multi-tenant with consent in the customer's tenant. The issuer, subject and audience are read from the identity rather than typed, because Entra accepts wrong ones silently and only refuses the first sign-in. Reports the D365__ settings the App Service then needs. Safe to re-run: a credential that already trusts the identity is left alone. The user is asked to confirm.

Add a reply URL to an existing app registration, keeping the ones already there. This is the step after a first deployment: the sign-in registration only knows the localhost URI until the production one is added, and sign-in fails with AADSTS50011 until it is. Pass the deployed URL and the callback path — for the templates' Microsoft sign-in that is /signin-microsoft. The user is asked to confirm.

Add a new client secret to an existing app registration and write it to the project's user secrets or an App Service application setting. Use it to rotate before an expiry — client secrets last a year by default and the portal stops starting the day one lapses, with an error that does not mention Entra. Adding a secret does not revoke the old one, so the swap has no gap. The value is never returned. NOT idempotent: every call mints another secret. The user is asked to confirm.

Add a row-level security role to a report's semantic model. In the portal's tokens USERNAME() is the viewer's contact id, and `filter` says what the role keeps them to: `contact` (the default) — rows whose column holds their contact id; `company` — rows whose column holds the company on their own contact row; `company-and-subsidiaries` — that company and every company under it, through the table's parent column (models that import their data only: Power BI refuses PATH in a DirectQuery role); `mapping` — the values a mapping table lists against their contact id, for a contact who may see several companies, say; `value` — rows whose column holds one of `values`, the same for everyone given the role, for a role an access row hands to a portal role; `customdata` — rows whose column holds the custom data the portal's IPowerBICustomDataProvider puts in the token (DAX CUSTOMDATA()), to filter on something the portal decides, such as an account number; `all` — every row, for staff. Written into the model in the service, as the folder's Power BI account. The same role should also go into the report's .pbix (Modeling > Manage roles) — republishing from Power BI Desktop replaces the model, role and all — so the answer gives the DAX to paste. Refuses to change an existing role of the name unless `replace` is true. list_powerbi_reports shows the tables and columns.

Let the portal's Microsoft sign-in connect viewers to Power BI, for items registered with `embedMode: "user"`: adds Power BI's delegated Report.Read.All and Dashboard.Read.All (read only), and Microsoft Graph's openid and offline_access that connecting also asks for, to the sign-in app registration — the one in this folder's Authentication:Microsoft:ClientId, or `clientId` — and a /signin-powerbi redirect URI for each site it has a /signin-microsoft one for, at the site's root. Every permission and redirect URI already there is kept. Viewers consent when they first connect, unless the tenant only lets administrators consent; the result gives the admin-consent link for that. Re-run it after adding a deployed portal's redirect URI. The user is asked to confirm.

Grant a security role privileges on one table. This is the step after installing the managed solution: the role that ships with PowerPortalsProCore covers the framework's own tables only, and the application user needs access to the consumer's tables too. This holds under both security models: impersonation intersects privileges rather than delegating them, so this role caps what every portal user can do. Purely additive — a privilege already held at an equal or deeper scope is left exactly as it is, and nothing is ever revoked. Safe to re-run. Refuses a managed role, the one that ships in PowerPortalsProCore included: Dataverse permits it, but that role is our component and an upgrade can reapply it. Grant to a custom role instead — create_security_role makes one and assign_application_user_role gives it to the application user. The role is added to the solution recorded for the environment, so the grant is exported with it; with none recorded this refuses, and create_solution makes one. Needs System Administrator on the environment. The user is asked to confirm.

Add a Dataverse application user to a column security profile — by default the 'Power Portals Pro Application User' profile the managed solution ships. Any application user on a role narrower than System Administrator needs it: a security role can never grant a secured column, and the portal creates contacts and handles password hashes through two of them. Without it, creating a portal user fails with 'does not have create permissions to a … secured field' and password sign-in cannot read the stored hash. Works for any application user by client id — the app registration's, and the managed identity's a deployed app connects as. Needs System Administrator on the environment. The user is asked to confirm.

Give a Dataverse application user a security role. Use it when get_application_user shows the user exists but holds no role, or holds one too narrow for what the portal needs. Roles are additive — assigning one never takes another away. Needs System Administrator on the environment. The user is asked to confirm.

Show which Azure subscription this folder deploys to, where that came from, and whether the saved sign-in still works. Call it first whenever an Azure tool reports that nothing is configured, and before suggesting the user run any `az` command — this server does not use the Azure CLI and does not read its logged-in state, so `az account show` says nothing about what these tools will do.

Compare what this project's portal needs against what its App Service actually has, and report what is wrong. This is the first thing to reach for when a deployed portal misbehaves: it catches the configuration keys that only ever existed in the developer's user secrets (the app then never starts), ASPNETCORE_ENVIRONMENT left on Development (a React portal's deep links redirect to localhost), WebSockets off on a Blazor Server portal (the circuit silently degrades to long polling), session affinity set wrong for the stack, and a Portal Website record whose URL does not match the host (every data endpoint returns 402 while the pages render perfectly), and Key Vault references that cannot resolve — a secret missing from the vault, or an app identity with no role that reads it. It also asks the running site whether it can reach Dataverse (a portal that cannot still serves pages, full of raw localization keys), whether a failing API call reaches the browser as problem+json, and on a React portal whether the scripts and stylesheets its page loads are served (a blank page otherwise). Read-only: it needs nothing but Reader (plus permission to list the vault's secrets, to check they exist), and the requests it sends the site read nothing, so it is safe against production.

Check whether the portal's sender address can actually deliver email, and say what to fix when it cannot — the question behind 'confirmation emails never arrive'. Finds every mailbox with the address, a queue's or a user's (teams have no mailbox, so a team cannot send), says which one the portal sends from — a user's is resolved before a queue's — and reports its approvals, delivery method, Test & Enable result and recent alerts. Defaults to the project's D365:EmailSenderEmailAddress. Changes nothing.

Check that the portal can draw its maps: which provider its PowerPortalsPro:Maps settings choose and whether that provider's key is set (key names only, never values); for Azure Maps, that the account the client id names exists in the folder's subscription, that the portal's identity holds a role that reads it, and that its allowed origins cover the portal's local and deployed addresses; and then, signed in as the portal itself with the client secret in this folder, whether Azure Maps hands it a tile — one request. Changes nothing, so it is safe against production.

Check that the portal can embed its registered Power BI reports, dashboards and tiles, end to end: each registration and its access rows; the item and the models behind it in Power BI, and the role names against the models'; the portal identity's workspace membership; the capacity, or the trial allowance; and then, signed in as the portal itself with the client secret in this folder, whether Power BI lets it in and issues a token — which is how the tenant settings only a Fabric administrator can change are checked. Each run issues one embed token per registration. An item shown with each viewer's own access is checked for what that needs instead: its access rows, and the sign-in app registration's Power BI permissions and redirect URI.

Check what this project folder still needs before the portal will run: whether a project exists, which configuration keys its startup code requires, which of those are actually set, whether the Dataverse connection works, whether the managed solution that provisions the framework's own tables is installed, whether every portal role name the code uses has an active Portal Role record, whether the application user's security roles allow what the table access registered in code needs, whether each operation registered with AddOperationAccess exists and is one the application user may run, and which environments the folder is bound to. Call this when a portal will not start, when every data endpoint returns 402, when a page fails with a Dataverse privilege error, when a registered operation is refused, or when an assigned portal role appears to do nothing. The Dataverse half checks the primary environment unless given another.

Apply the recommended platform settings to an existing web app: Always On, HTTPS only, HTTP/2, TLS 1.2 minimum, and the WebSockets and session-affinity pair that this project's stack needs. Use it after check_deployment reports a platform finding, or on an app that was created outside this server. The user is asked to confirm; the change restarts the app. Changes nothing that is already correct.

Record an existing unmanaged solution in .ppp/mcp.json as the one an environment's customizations go into, or change whether export_solution and push_solution package it managed or unmanaged. Use it when the solution was made in the maker portal or by a teammate; create_solution makes a new one. Changes only the binding file, nothing in Dataverse.

Create the Azure resources a portal runs on: the resource group, an App Service plan and the web app, with the platform settings this project's stack needs (WebSockets and session affinity for a Blazor Server or Auto portal, affinity off for React or WebAssembly) already applied. The user is asked to confirm and is shown the plan's real monthly cost from Azure's price list before they answer; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. Safe to re-run — anything that already exists is reused rather than duplicated. Defaults to the cheapest tier that can stay warm, for every environment including production.

Create a Gen2 Azure Maps account in the folder's Azure subscription for the portal's maps, which sign in to it with the portal's own identity: its keys and SAS tokens are turned off, and the sites allowed to draw its maps are the portal's — its web project's local addresses and the bound App Service's host names, plus any in `origins`. Writes the account's client id to the web project's user secrets as PowerPortalsPro:Maps:AzureMaps:ClientId. No standing charge: Azure Maps bills per use after a free monthly allowance. The user is asked to confirm; the first call only returns the details, and the second passes the code it names as `confirm`. Then grant_azure_maps_access. Safe to re-run: an existing account is reported, not made again.

Create the Entra app registration the portal connects to Dataverse as, add a client secret, and write the client id and secret into the project's user secrets (or an App Service application setting) — into user secrets with the environment's URL as D365:Url too, unless one is already set. This is the backend identity for the client-credentials flow — no redirect URIs, no Graph permissions and no admin consent are needed or added, except that a multi-tenant one gets Graph User.Read and a reply URL, the least another tenant's admin consent will accept. The secret value is never returned; only where it was stored and when it expires. Safe to re-run: an existing registration with that name is reused. The user is asked to confirm first. IMPORTANT: this is only half the setup — Dataverse also needs an application user for the client id, and the tool output says how.

Create the Dataverse application user for an Entra app registration and give it a security role, in one step. This is the other half of create_dataverse_app_registration and nothing works without it — a registration on its own gets a token and is then refused by every Dataverse call. The Entra service principal must exist first, which create_dataverse_app_registration ensures. Safe to re-run: an existing application user is reused and an existing role assignment is left alone. Needs System Administrator on the environment. The user is asked to confirm. When Power Portals Pro hosts the portal, the customer uses Power Portals Pro's own registration instead of creating one: pass its client id, 46c0b100-f468-4bfc-ba89-d128bceabe31, after an administrator in the customer's tenant has opened its admin-consent link — https://login.microsoftonline.com/organizations/adminconsent?client_id=46c0b100-f468-4bfc-ba89-d128bceabe31&redirect_uri=https%3A%2F%2Fpowerportalspro.com%2F — and accepted.

Create a deployment slot of the App Service that runs against one of this folder's Dataverse environments — a "uat" slot for the UAT environment — and link the two, so deploy_to_app_service given that environment lands in the slot. The slot copies production's platform configuration, managed identities and application settings, then gets its own D365__Url (and sender address) pointing at the environment and its own PowerPortalsPro__PublicUrl, marked as deployment slot settings so a swap never carries one environment into another. Safe to re-run on an existing slot: it repoints it and repairs the sticky settings without copying anything over. Needs a Standard or Premium plan. The user is asked to confirm; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`.

Create a Dataverse queue to act as the portal's no-reply email sender, for the address in D365:EmailSenderEmailAddress. This is the recommended sender for account-confirmation and password-reset mail: the address belongs to the portal rather than to a person, so no employee's name appears on automated messages, replies do not land in anybody's inbox, and nothing breaks when somebody leaves. It approves the queue's mailbox and runs Test & Enable on it, and reports what is left: approving needs an Office 365 Global Administrator or Exchange Administrator, and the address needs a mailbox in Exchange Online — a shared mailbox, which needs no license. Safe to re-run, and the way to finish once either is fixed: an existing queue with that address is reused rather than duplicated, and the test runs again until it passes. The user is asked to confirm.

Create an Azure Key Vault for this portal's secrets, grant the App Service's managed identity read access to it, and grant the signed-in user write access so secrets can be put in. Afterwards, the secret tools accept destination:"key-vault", which sends a newly minted client secret straight into the vault and leaves only a reference in the app settings. IMPORTANT: a Key Vault name is reserved for 90 days after deletion unless explicitly purged, so the name is the one thing here that is not cheaply undoable. Costs a fraction of a cent per thousand operations. The user is asked to confirm.

Create a user-assigned managed identity in Azure - an Entra identity that holds no secret and so has nothing to expire. It is a resource in its own right, which is the point: it survives the App Service being deleted and rebuilt, and is shared by every deployment slot, so the Dataverse application user and Key Vault grants built on it stay valid across a teardown. This only creates it; enable_managed_identity attaches it to an app. Free, and safe to re-run. Returns the identity's CLIENT id, which is what goes in D365:ManagedIdentityId and what a Dataverse application user must be created from - not the principal id, which is for Azure RBAC.

Create a Portal Role record in Dataverse so an AddPortalRole registration has something to bind to. Give it the exact name used in code — the string is the only thing joining the two, and a mismatch produces a role that grants nothing with no error anywhere. Safe to re-run: a role of that name is reported back rather than duplicated, which matters because two roles of one name are indistinguishable to whoever assigns them. Creating the role does not give it to anybody — assign it to contacts in the model-driven app, or use create_portal_role_configuration to hand it to new users automatically. Administrators can also maintain roles, and the rules that hand them out, on the portal's Role Configuration page (/RoleConfigurationAdmin in both project templates).

Create a Portal Role Configuration row, which decides whether newly registered users are given a role as their account is created. Modes: "automatic" gives it to every new user; "criteria" gives it to those whose contact matches a FetchXML rule; "none" leaves the row dormant. Criteria FetchXML must be rooted in the contact table and must not be an aggregate — this tool checks that before writing, because the portal fails closed on bad criteria and a broken rule looks exactly like a rule that matched nobody. Safe to re-run: an existing row for that role is reported back rather than duplicated. The portal's Role Configuration page (/RoleConfigurationAdmin) edits the same rows, and in React builds the criteria visually and shows who it matches today.

Create a Power Portals Pro Website record so a portal served from that URL passes the license check. Without one, every data endpoint on that host returns 402. Safe to re-run: an existing record for the URL is reported back rather than duplicated, which matters because two records for one URL leave it undefined which answers the check.

Create a Fabric capacity (an F SKU) in the folder's Azure subscription, for production embedding — a workspace on no capacity only gets trial tokens. Costs money for as long as it runs: the user is shown the live list price and asked to confirm; the first call only returns the details, and the second passes the code it names as `confirm`. The folder's Power BI account is made its administrator, so it can put workspaces on it (create_powerbi_workspace with `capacity`). F2 is the smallest. Safe to re-run.

Create a Power BI workspace for the portal's reports, as the folder's Power BI account, optionally putting it on a capacity. Safe to re-run: an existing workspace of that name is reported back. A workspace on no capacity can embed with Power BI's trial tokens, for development; production needs a capacity. Don't put the reports in a Premium Per User workspace — embedding for portal visitors isn't supported there.

Create an empty custom security role in the root business unit, to hold the application user's privileges on the customer's own tables. The role that ships with PowerPortalsProCore covers the framework's tables only and is a managed component an upgrade can reapply, so add_table_privileges_to_role refuses it — this role is where those grants go instead, and the application user holds both. Next: assign_application_user_role to give it to the application user, then add_table_privileges_to_role once per table. The role is created in the solution recorded for the environment, so it is exported with it; with none recorded this refuses, and create_solution makes one. Safe to re-run: a role of that name already in the root business unit is left as it is, except that one outside the solution is offered to be added to it. Needs System Administrator on the environment. The user is asked to confirm.

Create the Entra app registration behind 'Sign in with Microsoft' on the portal's login page, with the /signin-microsoft redirect URI filled in from the project's launchSettings (the templates randomize the local port, so there is nothing to guess), add a client secret, and write both into the project's user secrets or an App Service setting. Its ID token is given the email-verification optional claims (email, xms_edov, verified_primary_email, verified_secondary_email) and the delegated Microsoft Graph email permission they need — on an existing registration too — so a work or school account whose address Entra vouches for signs in without a confirmation mail. Users can consent to that permission themselves, except in tenants that only let administrators consent. This is a SECOND, SEPARATE registration from the Dataverse one — sharing one means a single secret rotation takes down both sign-in and data access, and gives the sign-in app a Dataverse role it never needed. The secret value is never returned. The user is asked to confirm.

Create a publisher and an unmanaged solution in a Dataverse environment, and record the solution in .ppp/mcp.json as the one that environment's customizations go into. Do this once, in the environment where the portal's Dataverse changes are made (usually dev): create_security_role, add_table_privileges_to_role and remove_table_privileges_from_role refuse to change an environment with no solution recorded, so everything they change lands here and is exported together — export_solution and push_solution take it to test and production. An existing publisher of that name is reused; an existing unmanaged solution of that name is recorded without being changed. Ask the user for the names and the prefix rather than inventing them: the prefix begins the schema name of everything the publisher creates and cannot be changed later. Needs System Customizer or System Administrator. The user is asked to confirm.

Report which Dataverse environments this project folder is bound to — each one's position, name and URL, which is the primary, which account it connects as, and whether that connection currently works. Every other Dataverse tool acts on the primary unless given an `environment` argument; this is where to find the names and positions to pass. Call it first if any other Dataverse tool reports it is not configured — it explains exactly what is missing and which command the user should run.

Permanently delete a Portal Role record, and with it every assignment of that role to a contact. Prefer update_portal_role with active:false — deactivating grants nothing and mints no claim either, but keeps the assignments so it can be reversed; deleting throws them away and nothing remembers who held it. The user is asked to confirm; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. Show the user what will be lost before calling, and never call this to tidy up on your own initiative.

Permanently delete the Portal Role Configuration row for a role. The role itself and its existing assignments are untouched — this only stops the role being given to users who register from now on. Deactivating the row with update_portal_role_configuration has the same effect and is reversible. The user is asked to confirm; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`.

Permanently delete a Power Portals Pro Website record. This takes the site's license with it: from the next request, every data endpoint on that URL returns 402. Prefer update_portal_website with active:false, which does the same thing reversibly — deletion is only right for a record that was wrong to begin with, such as a typo'd URL or a duplicate. The user is asked to confirm; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. Never call this on your own initiative.

Delete a Power BI report's registration and its access rows, so the portal stops showing it: every PowerBIReport naming the key shows that the report isn't available. The report itself, in Power BI, is not touched. The user is asked to confirm; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. Never call this on your own initiative.

Delete a custom security role that no user or team holds — one made for a test run, or replaced by another. Refuses a role anyone still holds, naming them, so taking access away is always a separate, visible step: remove_application_user_role first for an application user. Refuses a managed role, which belongs to the solution that installed it. Cannot be undone: the role and every privilege in it are gone, along with the copies Dataverse keeps in other business units. Needs System Administrator on the environment. The user is asked to confirm.

Build this project with `dotnet publish` and push the result to its App Service. On a React portal the publish also runs the Vite build and stages the SPA, so Node must be installed. The user is asked to confirm first — this replaces what is currently serving traffic. Deployment itself costs nothing beyond the plan that is already running.

Show one web app's platform configuration and the NAMES of its application settings. Values are never returned, except for a short list of documented non-secrets such as ASPNETCORE_ENVIRONMENT and D365__Url — a portal's settings hold the Dataverse client secret and every sign-in provider's secret, and those must not reach a transcript. Use check_deployment instead when the question is whether the app is correctly configured; this is for when you need the raw picture.

Describe a custom API, custom action or Dataverse message by name: how it is bound, its request parameters (type, whether optional, the table a record parameter is of) and its outputs, the privilege it asks of whoever runs it — through a portal, the application user — a starting AddOperationAccess registration that lets portal users run it, and the OperationButton markup that offers it on a page to the users it is for. Call this before writing a registration rather than guessing parameter names: a request carrying a parameter the registration doesn't accept, or one it gets wrong, is refused.

Show what a security role currently grants on one table, privilege by privilege, with the depth of each. Use it before add_table_privileges_to_role to see what is actually missing, and after a portal reports an empty grid or a failed save to find out whether the role is the reason. Depth matters as much as the privilege: an application user owns no records, so a privilege held at User depth grants it nothing at all.

Show the solution recorded for an environment — its publisher and prefix, its version, whether it exports managed or unmanaged, and what it holds — or say that none is recorded and how to set one up. Use it before export_solution or push_solution to see what would move, and when a customization tool refuses for want of a solution.

Describe a Dataverse table's columns, with the PowerPortalsPro editor each one maps to. Use this before writing a form or a grid: it gives you the exact column logical names and tells you whether a column needs a TextEdit, a LookupEdit, a ChoiceEdit and so on. Platform bookkeeping columns are hidden by default.

Send a web app's (or a deployment slot's) logs — every category it offers, its console output and HTTP requests among them — to the app's own Log Analytics workspace ("<app>-logs", in the app's resource group), kept for a set number of days. create_app_service already does this for a new app; use this for one created before, for a slot, or to change how long logs are kept. Safe to re-run: the workspace is reused and only its retention changed. The user is asked to confirm.

Give the App Service a managed identity, so it can authenticate as itself with no secret. PREFER passing managedIdentityId with a user-assigned identity from create_managed_identity: a user-assigned identity is a resource of its own that survives the app being rebuilt and is shared across deployment slots. Omitting it turns on the app's SYSTEM-assigned identity instead, which is created and destroyed with the app and differs per slot - so rebuilding the app mints a new identity and orphans the Dataverse application user and Key Vault grants built on the old one. Free, safe to re-run, and the app restarts. The user is asked to confirm.

Export the solution recorded for an environment to a zip in the workspace's `solutions` folder, managed or unmanaged as `exportAs` says, or as recorded for the environment when it is left out (unmanaged unless the binding says otherwise). The solution's version goes up by one in its last part first — 1.0.0.3 becomes 1.0.0.4 — unless `version` sets it, so every export is told apart in the target's history. Waits up to ten minutes; a larger solution returns a job to finish with get_solution_export_status. push_solution exports and imports in one step. Changes made in the maker portal since the last publish are exported as last published, so run publish_customizations first if there are any.

Check whether a component or feature exists on both the Blazor and React stacks, and what differs. Use it before assuming a Blazor parameter has a React equivalent, or vice versa — the two stacks are close but not identical.

Show the Dataverse application user for an Entra client id, the security roles it holds, and its column security profiles. Call it whenever the portal authenticates but every Dataverse call is refused — either there is no application user for the client id, or there is one and it holds no role, and both look identical from the portal's side — and whenever creating a portal user fails with 'does not have create permissions to a … secured field', which means it holds a role but no profile covering the secured contact columns.