Power Portals Pro

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.

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. Cannot modify the role that ships in the managed solution: Dataverse permits it, but it is our component and an upgrade can reapply it. 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). Read-only: it needs nothing but Reader and is safe against production.

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, and whether the folder is bound to an environment. Call this when a portal will not start, when every data endpoint returns 402, or when an assigned portal role appears to do nothing.

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.

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; where the client cannot prompt, pass the app name 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 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). This is the backend identity for the client-credentials flow — no redirect URIs, no Graph permissions and no admin consent are needed or added. 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.

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. Safe to re-run: an existing queue with that address is reported back rather than duplicated, since two queues sharing an address leave it undefined which one answers. 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 licence 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 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 randomise 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. 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.

Report which Dataverse environment this project folder is bound to, which account it connects as, and whether that connection currently works. Call this 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; where the client cannot prompt, pass the role's exact name 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; where the client cannot prompt, pass the role's exact name as `confirm`.

Permanently delete a Power Portals Pro Website record. This takes the site's licence 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; where the client cannot prompt, pass the record's exact URL as `confirm`. Never call this on your own initiative.

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.

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.

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.

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.

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.

Return the full API reference for a PowerPortalsPro component or type: every parameter and prop with its type, default, permitted values and description. This is the authoritative source — prefer it over recalling a parameter name, because the surface is large and changes between releases. Wide types are summarized; pass `filter` to search members by name or `section` to get one group in full.

Return the PowerPortalsPro golden rules and conventions for a stack — the same guidance shipped as AGENTS.md in every generated project. Read this before writing PowerPortalsPro code for the first time in a session: it covers data access, localization, security filtering and the mistakes that are easy to make and hard to diagnose.

The ordered steps to get this project running on Azure App Service, the plan tiers available with their real current prices, and the settings the portal will need. Needs no Azure sign-in, so it works before anything exists. Use it to answer 'how do I deploy this' and to tell the user what a given tier will cost before they commit to anything.

Return one documentation section in full, by the id from search_docs (e.g. "grids/main-grid#views"). Passing a page id without the #fragment returns the whole page, which is longer — prefer the specific section.

Return a complete, working code sample verbatim from the PowerPortalsPro demo site. These compile and are current, so prefer adapting one over writing from scratch. Accepts a sample id from search_docs, or a component name to get that component's main example.

Return everything about one topic as a single coherent unit: the guide prose, the Blazor sample, the React sample and the API reference links. Prefer this over several separate calls when you are about to implement a feature — one complete working example beats three fragments you have to reassemble.

Read a single record by its id, from any table. Shows one column per line rather than a table, so a wide record stays readable — the shape you want when checking what a specific row actually contains. Reads as the connected service principal or user, NOT as a portal user, so none of the portal's own security applies. Read-only.

Explain what has to exist before a Power Portals Pro portal will run: creating the project from the template, importing the managed Dataverse solution, registering the Entra app the portal connects to Dataverse as, registering the Entra app people sign in with, provisioning an Azure Translator resource, and binding the folder to an environment. Says what each step creates, which permissions it needs, and which configuration keys it produces. Use this to answer 'how do I set up a new portal'; use get_setup_script to turn it into commands.

Generate a ready-to-run setup script for a new Power Portals Pro portal, with the supplied values filled in. Covers creating the project, registering both Entra apps (Dataverse connection and Microsoft sign-in), creating their secrets and writing them to user secrets, adding the Dataverse application user, provisioning an Azure Translator resource, and binding the folder. The script is written, NOT run — present it to the user to review and run themselves, because it creates real objects in their tenant, environment and subscription. It is safe to re-run and never prints a secret.

Check how a solution import started by install_solution is going. Returns whether it is still running, the percentage complete where Dataverse reports it, and the outcome with Dataverse's own message once it finishes. Imports take minutes, so poll this rather than waiting on the install call.

Plan an upgrade of this project from the PowerPortalsPro version it references to a newer one: which releases it crosses, every breaking change in them with its migration instructions, which files name a version that has to change (project files, package.json, and the server pin in .mcp.json), and the order to do it in. Call this before changing any version string — bumping the packages without the breaking changes produces build errors whose cause is several releases back. Writes nothing; install_solution upgrades the Dataverse side and the file edits are yours to make.

Download a Power Portals Pro managed solution and import it into the environment this folder is bound to. Installs PowerPortalsProCore by default, or PowerPortalsProLocalization, or PowerPortalsProEnhancedAuthorization (needs Power Pages installed); takes the latest release unless a version is given. This is how you provision the framework's tables and licence check on a new environment, and how you upgrade an existing one — a managed upgrade keeps data and customisations. The user is asked to confirm first and is shown which environment will change; where the client cannot prompt, pass the environment URL as `confirm`. The import runs in the background: this returns a job id, and get_solution_import_status reports progress. Imports take minutes.

List the Entra app registrations in the signed-in tenant, with their client ids, redirect URIs and client-secret expiry dates. Use it to find an existing registration before creating a duplicate, to get the client id for a configuration value, and to answer 'why did the portal stop starting' — an expired client secret is the usual reason and the expiry dates are right here. Secret values are never returned; Entra does not store them in retrievable form either.

List the App Service web apps in the bound Azure subscription, with their host names and state. Use it to find the app a portal is deployed to when the user refers to it by a name you cannot map to a resource, or to confirm a name is free before creating one.

List the options of a Dataverse choice column, with their integer values and labels. Needed whenever you filter or compare on a choice — the stored value is the integer, and it is environment-specific for custom option sets.

Browse what PowerPortalsPro ships: components, hooks, enums, interfaces and options classes. Use it to discover whether something exists before writing it yourself. The catalog is large, so narrow with stack, kind, package or filter. Framework plumbing — abstract bases, query-builder internals, extension containers — is left out unless you ask for it.

List the Dataverse queues that have an email address, which are the ones usable as the portal's D365:EmailSenderEmailAddress. Use it to find an existing no-reply address before creating another, and to check that a queue's outgoing delivery method is set to actually send — a queue with outgoing delivery None accepts the email and delivers nothing.

List the Portal Role records in the environment and the Portal Role Configuration rows that decide which of them newly registered users start with. Use it before writing an AddPortalRole call, so the code binds to a name that exists, and before creating a role, so an almost-identical duplicate isn't added. Shows each role's active state: an inactive role grants nothing and mints no claim. check_setup compares every role name the project's code uses with these records.

List the Power Portals Pro Website records that licence this environment's portals — the URL each one covers, whether a licence key is set, and whether the record is active. Use it when every data endpoint returns 402, which is what a missing or inactive record for the request's host looks like. Licence key values are never returned.

List a Dataverse table's relationships by schema name. SubGrid takes a RelationshipName and ManyToManyLookupEdit takes an N:N one, and both must match exactly — call this rather than guessing the name from the table names.