Power Portals Pro

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 — as `id` or `name`, whichever is to hand.

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 on an export that export_solution or push_solution handed back still running, and once it has finished, save the zip to the workspace's `solutions` folder. Exports of large solutions take minutes, so poll this rather than exporting again.

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.

Give the portal's identity — the one it connects to Dataverse as, read from this folder's settings, or the one named by `portalClientId` — the Azure Maps Data Reader role on an Azure Maps account, and nothing more: the portal hands every viewer of a map that identity's token. Also adds the portal's sites to the account's allowed origins — its web project's local addresses, the bound App Service's host names and any in `origins` — keeping the ones already there. The account defaults to the one the folder's PowerPortalsPro:Maps:AzureMaps:ClientId names. A new role can take a few minutes to take effect. The user is asked to confirm; the first call only returns the details, and the second passes the code it names as `confirm`. Safe to re-run.

Make the portal's identity — the one it connects to Dataverse as, read from this folder's settings, or the one named by `portalClientId` — a Member of a Power BI workspace, which it must be to issue embed tokens for the workspace's reports. Pass the workspace a report's semantic model is in, too, when that is another one. Optionally adds the identity to an Entra security group, for a tenant whose 'Service principals can call Fabric public APIs' setting is limited to that group. Safe to re-run.

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 license check on a new environment, and how you upgrade an existing one — a managed upgrade keeps data and customizations. The user is asked to confirm first and is shown which environment will change; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. The import runs in the background: this returns a job id, and get_solution_import_status reports progress. Imports take minutes.

Link one of this folder's Dataverse environments to a deployment slot of its App Service, so the App Service tools given that environment — deploy_to_app_service above all — act on that slot. Then "publish to Azure" while working in UAT lands in the UAT slot instead of production. Pass slot "production" for the app itself, or "none" to remove the link. One environment per slot: linking a slot already linked to another environment moves the link. create_deployment_slot links the slot it creates, so this is for slots that already exist, and for production. Changes only this folder's .ppp/mcp.json.

List the Entra app registrations in the signed-in tenant, with their client ids, redirect URIs, and client-secret and certificate 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 App Service's deployment slots, production included, with each one's host, the Dataverse environment it actually runs against (its D365__Url) and the environment this folder links to it. Also says whether the environment settings are sticky — the thing that makes a swap safe — and whether the plan's tier allows slots at all. Read-only; use it before swap_slots, and whenever it is unclear which slot an environment deploys to.

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 operations a portal can be allowed to run with AddOperationAccess (or a role's WithOperationAccess): the environment's custom APIs, by unique name, with how each is bound and whether it is a function. Pass `includeMessages` to list Dataverse's own messages and custom actions as well — there are hundreds, so pass `search` with it. Then call describe_operation for one's parameters and outputs.

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 license this environment's portals — the URL each one covers, whether a license 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. License key values are never returned.

List Power BI content as the folder's Power BI account. Without `workspace`: every workspace the account can see, with whether it is on a capacity. With `workspace`: its reports, and for each report's semantic model whether it uses row-level security, its roles, and its tables and columns — what add_powerbi_rls_role and set_powerbi_report_access need — then its dashboards and their tiles, plus which reports, dashboards and tiles are registered for the portal in Dataverse.

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.

List the Dataverse security roles available in the root business unit, so a role can be chosen by name before assigning it. Use it before create_dataverse_application_user or assign_application_user_role rather than guessing a name — role names vary between environments and an assignment silently does nothing if the name does not match.

List the solutions installed in this environment and the Power Portals Pro releases available to install, so you can see whether the environment is behind. The framework needs PowerPortalsProCore; PowerPortalsProLocalization is optional and only backs the translation-memory features; PowerPortalsProEnhancedAuthorization is optional and assigns Power Pages web roles to new users on portals using enhanced authorization (it requires Power Pages in the environment). Use this before install_solution, and when a portal fails in ways that suggest missing tables or a 402 from every data endpoint.

Find Dataverse tables in this project's environment by name. Returns logical names — the names you write in code — alongside display names. A search term is required: a real environment has over a thousand tables. Use this to confirm a table's logical name before writing it.

List the configuration keys in this project's user-secrets store — names only, never values — with the Key Vault secret name and App Service setting name each would take. Use it before push_secrets_to_key_vault to propose which keys belong in production; the user decides each one, so propose only the ones the deployed portal needs, not everything in the store.

List a Dataverse table's saved views WITH THEIR REAL GUIDs. MainGrid and SubGrid take view ids (DefaultViewId, ViewIds), and those ids exist only in this environment — they cannot be guessed or remembered. Always call this before writing a grid that binds to views, instead of leaving a placeholder.

Publish all pending customizations in the environment, so changes made in the maker portal become live. Reach for this when the portal is serving stale metadata — a column you just added not appearing, a renamed label still showing the old text, a new option-set value missing from a choice. It is the same action as 'Publish all customizations' in the maker portal, so it publishes EVERYTHING pending in the environment, not only your own changes: on a shared development environment that can make a colleague's half-finished work live. Not needed after install_solution — importing a managed solution publishes what it brings. Safe to re-run, and on a large environment it can take several minutes.

Copy secrets that already exist in this project's user secrets into the workspace's Key Vault, and point the App Service's settings at them as Key Vault references. Pass the keys to offer (list_user_secret_keys shows them); the user then approves EACH ONE separately, all unticked to start, and only the approved ones are copied — a user-secrets store holds more than production credentials, so never offer everything by default. Values are never returned. A key whose value the vault already holds adds no new version. Needs create_key_vault first; run check_deployment afterwards.

Take the solution recorded for one of this folder's environments to another: export it (managed or unmanaged, as recorded, with its version raised by one in the last part) and import it into the target. This is how changes built in dev reach test and production. With `file`, imports a zip export_solution already saved, without exporting again. The import runs in the background: this returns a job, and get_solution_import_status with the target as `environment` reports on it. A solution that depends on another — Power Portals Pro's, say — fails to import until that one is in the target too; install_solution installs Power Portals Pro's. An unmanaged import needs publish_customizations in the target afterwards. Needs System Customizer or System Administrator in both. The user is asked to confirm.

Read records from any table in the environment. Either name a `table` for a straight page of it, or pass `fetchXml` for anything more — filters, joins, ordering, aggregates. The FetchXML a saved view carries (from list_views) can be run verbatim, which is how you see the rows a portal grid will actually show. Use this to find out what real data looks like: the option-set value a row really carries, whether a lookup is populated, whether the record your code just wrote came out right. Reads as the connected service principal or user, NOT as a portal user — none of the portal's table, column or row security applies, so this cannot tell you what a given portal user would see. Read-only: there is no tool that creates, changes or deletes a business record.

Register a Power BI report, dashboard or dashboard tile for the portal: a Portal Power BI Report row in Dataverse, under the key a PowerBIReport component names it by. Give `report` for a report; `dashboard` for a dashboard; `dashboard` and `tile` for one of its tiles. They are looked up in Power BI as the folder's Power BI account, so their ids are right. Updates the row when the key is registered already. Nobody can see it until set_powerbi_report_access says who may. With `embedMode: "user"` it is shown with each viewer's own Power BI access instead of the portal's.

Remove a certificate from an app registration by thumbprint, so the registration stops accepting sign-ins signed with it — the last step of a rotation, once nothing uses the old certificate. list_app_registrations and add_app_registration_certificate show the thumbprints. The certificate itself stays in Key Vault. The user is asked to confirm.

Take a Dataverse application user out of a column security profile. Unless it holds System Administrator or another profile covering the same columns, creating portal users starts failing immediately and password sign-in can no longer read stored hashes. Only a direct membership can be removed; a profile held through a team is changed on the team. Needs System Administrator on the environment. The user is asked to confirm.

Take a security role away from a Dataverse application user. The reason to reach for this is narrowing an application user that was given System Administrator to get things working — assign the narrower role first, then remove the broad one, so there is no window where the portal can do nothing. Removing the only role a user holds stops every Dataverse call it makes. Needs System Administrator on the environment. The user is asked to confirm.

Remove one of this folder's Dataverse environments, so no tool can reach it from here. Nothing in Dataverse changes, and the saved sign-in is kept, but adding it back needs the user to run `login` in a terminal again. Removing the primary makes the next environment in the list the primary. 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`.

Take privileges on one table away from a security role, or with `depth`, lower them to that depth instead. The undo for add_table_privileges_to_role: a grant made by mistake, a table the portal no longer serves, or access narrower than first granted. Every holder of the role loses the access at once — the application user included, so the portal's pages on that table fail with a privilege error if nothing else grants it. describe_role_table_privileges shows what the role holds first. Refuses a managed role, for the reason add_table_privileges_to_role does. Safe to re-run: privileges not held, or already at or below the depth, are left alone. The role is added to the solution recorded for the environment, so the removal is exported with it; with none recorded this refuses. Needs System Administrator on the environment. The user is asked to confirm.

Give one of this folder's Dataverse environments a new name — "dev", "test", "uat", "acme-prod", whatever the user calls it. The name is what the `environment` argument of every Dataverse tool accepts, and what each result's first line shows. Names are unique within the folder and cannot be a bare number, which would read as a position. Changes nothing in Dataverse and nothing about which environment is the primary.

Draft a Power Portals Pro issue — a bug report, a feature request or a question — on the public feedback repository, https://github.com/Power-Portals-Pro/PowerPortalsPro-Feedback/issues. Returns a link that opens the repository's own issue form with the fields filled in, plus the versions this server can see (this server, the project's Power Portals Pro packages, the framework's solutions in Dataverse). Nothing is posted: the user opens the link, reviews it and submits it signed in to GitHub. Use it when the user wants to report a problem or ask for something, or when you have established that a problem is in the framework rather than in the project's own code — check the documentation and check_setup first, and ask the user before drafting. The repository is public: write in the framework's terms and leave out the customer's name, environment URLs, record data, email addresses, secrets and file paths. A draft naming an environment, a Power Pages site or a local path is refused.

Restart the App Service web app — to clear an app stuck after a failed deployment, or to reset a portal that has stopped responding. Anyone using the portal is disconnected for a few seconds. The user is asked to confirm first.

Search PowerPortalsPro documentation, component API reference and code samples. Returns ranked results with an id and a short excerpt; pass an id to get_doc, get_component_api or get_example for the full content. Use this for open questions ("how do I filter a grid per user"). If you already know the component name, call get_component_api directly instead. Search in English: the documentation is English, so translate the user's question first if they asked in another language. Answer them in theirs — and note that component, parameter and column names are always English in code, whatever language the conversation is in.

Add or update application settings on a web app, merging with what is already there rather than replacing it. Use the double-underscore form of a configuration key — D365:ClientId becomes D365__ClientId — because the colon form does not work on Linux App Service. Prefer a Key Vault reference (@Microsoft.KeyVault(SecretUri=...)) over a literal for anything secret. The user is asked to confirm and is shown which names are being set, never their values. The app restarts.

Move one of this folder's Dataverse environments to a position in its list. Position 1 is the primary environment — the one every Dataverse tool uses when it is not given an `environment` argument — so moving an environment to 1 makes it the primary, and moving the primary elsewhere makes the new first entry the primary. When the move changes the primary the user is asked to confirm, because every later write that does not name an environment goes to the new one; the first call only returns what will change, to show them, and the second passes the code it names as `confirm`. Only use it when the user asks to reorder or to switch the primary — to act on another environment once, pass `environment` to that tool instead. dataverse_status lists the environments and their positions.

Pause or resume a Fabric capacity in the folder's Azure subscription. Paused, it costs nothing and every report on it stops rendering in the portal; resumed, it is billed again by the second. The user is asked to confirm; the first call only returns the details, and the second passes the code it names as `confirm`.

Say who may see a registered Power BI report, replacing its access rows. Each entry lets in an audience — holders of a portal role, every signed-in user, anonymous visitors, or internal users signed in as Dataverse users — and gives them the model's row-level security roles it names. A viewer sees the report when any entry applies, with every role the entries that apply name. Power BI doesn't check role names, so each is checked against the model here; a model with row-level security needs every entry to name at least one.