Testing Power Pages
Power Pages sites are discovered through an existing Dataverse connection. You do not need a separate environment connection for each site.
Select New > New case and choose Power Pages in the platform selector. The website designer starts with Open portal. Power Pages cases offer website actions and use portal personas in Log in to portal. A suite can contain both Power Pages and D365 cases; each case keeps its own platform and designer.
Discover and manage sites
- Open Manage connections and refresh the connection's metadata, or select its Power Pages globe icon and choose Refresh.
- Review the discovered sites and their URLs. Both standard and enhanced data models are supported.
- The public HTTPS portal URL is shown read-only from Dataverse metadata. If no usable URL is available, check the Power Pages site configuration and refresh sites before adding or connecting a persona.
Portal discovery warnings appear separately from Dataverse table metadata. Check the connection user's permissions to website tables if sites cannot be retrieved.
Add a portal persona
- Open the connection's Manage personas dialog and select Power Pages users. Select Add persona and choose a discovered site in Portal. You can also choose Manage personas beside a site in the Power Pages manager to open this tab with that site selected.
- Search Portal user by name or email to select a Dataverse contact. Testgrity fills the persona name and expected identity and tries to detect the sign-in provider and local username. Review the detected values. If contacts or provider details cannot be loaded, enter the persona name and expected identity manually and select the provider yourself.
- Select Local account, Microsoft Entra ID, Entra External ID / Azure AD B2C, or Other external provider in Login provider.
- Review Expected signed-in identity and Identity verification page.
The default page is
/profile/; verification reads its#emailaddress1email field. The page must stay on the selected site and display the expected user. The current form does not offer a selector editor; sites with a different profile layout need administrator assistance.
Anonymous tests need no persona. Portal personas are separate from D365 users and are selected in Log in to portal, rather than the case's D365 execution persona field. The persona list shows the site, provider, expected identity, and connection status for each saved persona.
Authenticate a local account
Enter Sign-in username and Password, then select Authenticate. Testgrity signs in through the site's local sign-in form, verifies the expected identity, and saves an encrypted session. The password is used only for this authentication and is not stored. Local sign-in must be enabled on the site.
Capture an external sign-in session
- Install or update Testgrity Recorder to 0.4.10 or later in desktop Chrome or Edge and reload Testgrity. The portal requires the current extension version; portal session capture was introduced in 0.4.7.
- For an external provider, select Authenticate in the persona form. Testgrity saves the persona and opens a portal tab. For an existing persona, use its key icon (Authenticate persona or Capture session).
- Complete sign-in in the opened portal tab, including MFA or passwordless authentication. Return to Testgrity and choose Save captured session.
Choose Cancel capture to abandon capture. Switching persona tabs or closing the persona manager also cancels an active capture. If opening sign-in fails after the persona is saved, use its key icon to try again.
Testgrity verifies that the identity element's text or input value exactly matches the expected identity, ignoring case and surrounding whitespace, before saving an encrypted session. Only cookies and browser storage for the selected site's host are captured; identity-provider cookies stay in your browser. If verification fails, check the page, selector, and actual user.
Background tests reuse the verified session for either provider type; they do not re-enter credentials during a test. Editing an external persona disconnects its previous session until capture succeeds again. For a local persona, enter its password again and authenticate to save the updated session.
Author a portal test
Use actions in the Designer's Power Pages group:
| Action | Target |
|---|---|
| Open portal | A site discovered from the selected connection |
| Log in to portal | A saved portal persona for the most recently opened portal |
| Open portal page | A relative path beginning with / |
| Click portal button/link | One button or link's exact accessible name |
| Fill portal field | The field's exact accessible label and the value |
| Select portal option | The select field's exact accessible label and option label |
| Verify portal text | One exact visible text |
| Set portal checkbox | Field label and true/false; preserves an already correct state. |
| Select portal radio option | Labelled radio group and exact option label. |
| Set portal lookup | Field label and exact result; supports combobox suggestions and the standard lookup dialog. |
| Verify portal field value | Field label and expected value; dropdowns compare the selected option label. |
| Verify portal field state | Field label and required/optional, visible/hidden, enabled/disabled, readonly/editable, or checked/unchecked. |
| Verify portal validation error | Field label and exact associated error message; use Form for a validation summary. |
| Search portal list | List name or css: selector and search text. |
| Filter portal list | List, inline filter field label, and filter value. |
| Open portal list row | List and an exact cell value identifying one row with a unique link. |
| Change portal list page | List and the exact Next, Previous, or numbered page-control label; waits for results or the current page to change. |
| Verify portal list results | List and expected loaded row count and/or exact cell text. Count applies to the current page. Zero rows requires an explicit empty state. |
| Upload portal file | Upload field label and a file selected in the Designer, up to 5 MiB. Submit the form separately. |
| Verify portal downloadable file | Link name and filename; fetches the same-site attachment and verifies a nonempty response without saving a local file. |
| Next portal form step | Next button name and expected destination step. |
| Previous portal form step | Back button name and expected destination step. |
| Verify portal form step | Exact current progress-step text, or a heading if no progress indicator is present. |
| Verify portal page access | Same-site path, exact expected HTTP status, and expected page text. Redirects and network errors fail. |
Example: Open portal → Log in to portal → Open portal page → Fill portal field → Click portal button/link → Verify portal text.
The Power Pages designer starts with Open portal. A suite can contain separate D365 and Power Pages cases.
Select the site in Open portal before choosing Log in to portal. Its persona
selector offers only personas belonging to the most recently opened site. Keep
page paths on that site, for example /support/; full URLs and // paths are not
accepted. Button/link names, field labels, option labels, and verification text
must match the visible page exactly and identify a single target.
For an anonymous smoke test, use Open portal → Verify portal text without a login step. For authenticated testing, add Log in to portal after opening the site and choose the intended persona.
Richer form, list, and permission tests
The extended field, button, and list actions accept an explicit css: selector
when labels are duplicated, for example css:#requests or css:#NextButton.
Selectors must identify one element; the runner does not choose an arbitrary match.
Field-state checks for hidden controls require that the control still exists.
List search requires a list-local search control. Filters use labelled inline inputs or dropdowns; custom filter menus are not automatically configured. Result counts describe loaded rows on the current page, not the Dataverse total. An empty list must show an explicit empty state rather than only a missing table.
For attachments, select a test file in the Designer. Its contents are stored with the case and included in browser runs. A later Submit step completes the upload. The download check supports same-site links returning an attachment with the expected filename. It checks the authenticated response and does not save a local file or follow external storage redirects.
For multistep forms, enter the exact Next/Back button name (or a unique css:
selector) and the expected destination step. Add Verify portal form step to
check a current step without navigating.
For access checks, use Verify portal page access with a path such as
/requests/customer-b/, the expected HTTP status, and expected page text. A portal
that renders its denial page with HTTP 200 should expect 200 and the denial
message. This action always expects successful verification: a failed request
cannot count as proof that access was denied.
To test customer isolation, create separate cases using two portal personas. Verify that each persona can access its own record page and receives the expected denial response for the other customer's record. To check that restricted fields or buttons are hidden, use Verify portal field state with a unique target. These are portal-session checks; D365 security roles do not establish portal permissions.
Run a portal test
Choose Background or Browser execution:
- Background starts each Open portal in an anonymous session and restores the saved persona for Log in to portal. It uses a separate browser context from D365. Reconnect an expired persona in Connections → Personas → Power Pages users. A suite containing only Power Pages cases can run with cached site metadata even when the Dataverse connection's saved sign-in is disconnected. Authenticated portal steps still require a valid saved portal persona. Refreshing sites or loading contacts requires access to Dataverse.
- Browser requires Testgrity Recorder 0.4.10 or later in desktop Chrome or Edge. It uses the current portal login in that browser profile. Log in to portal verifies the selected persona's identity on its configured verification page; complete sign-in in the run tab if prompted. A different signed-in user fails the step. Saved cookies are not restored and your browser session is not cleared. To test anonymously, use a profile signed out of the portal, or choose Background. Keep the managed test tab open until the run finishes.
Portal actions and results work in either mode. Portal interaction recording is not yet available. The D365 users tab manages Dataverse personas; those persona cases still require Background execution.