FIELD NOTE / POWER PAGES / FIT TEST
Test Power Pages against the hardest record-isolation path
Power Pages is credible when an authenticated external user can complete the hardest transaction, see the correct Dataverse rows, fail safely, and leave enough evidence for support. Build that vertical slice before the home page. The result either establishes a workable fit or supplies a precise rejection reason.
Define one complete external journey
Choose a transaction containing identity, relationship-based row access, attachments, validation, state change, internal review and a downstream notification or API call. Write the personas, records, prerequisites and expected denial cases before configuration.
Use synthetic organisations and contacts. Assign stable IDs to the test records. The trace should join the external identity, portal contact, parent organisation or relationship, case row, timeline event and audit operation.
Prove identity-to-contact resolution
Record the identity provider, tenant, subject/object identifier, email claim use, invitation path and contact mapping. Test an existing contact, a new invitation, a changed email and a user with two organisation relationships.
Reject ambiguous mapping. Email domain and display name cannot establish authority to an organisation. The relationship record requires an approver, effective dates and an audit trail.
Model table permissions from the relationship
Create only the table permissions required for the transaction. Record table, scope, relationship, web role and privileges. Keep create, read, write, append and append-to distinct. Use child permissions only where the business relationship supports the traversal.
Run direct-record URL and Web API tests as the external personas. View filters improve navigation but do not enforce row security. A prohibited persona must receive no row or field content, including through lookup and attachment endpoints.
Exercise failure after the first side effect
Force a validation rejection, attachment failure, integration timeout and approval rejection. Record whether the case remains draft, creates a duplicate or sends an acknowledgement. Give the operator a stable correlation or case ID.
Retry the same request with an idempotency key. The resulting case count must remain one. Reconcile the portal row, downstream effect and message history before accepting the path.
Package the slice as a release
Put tables, forms, site metadata, cloud flows, connection references and environment variables in controlled solutions. Export an unmanaged source artifact, build the managed target artifact, retain its checksum and deploy through the approved route.
pac auth create --environment https://contoso-dev.crm.dynamics.com
pac solution export --name ExternalService --path ./out/ExternalService.zip --managed false
pac solution check --path ./out/ExternalService.zipRun commands only in the authorised development tenant. Production values and connections remain separate target configuration with named owners.
Measure support and recovery
Define who owns invitations, relationship approvals, content changes, certificates, flows, integrations, releases and incident response. Test a revoked user, expired invitation, broken connection and rollback to the previous managed artifact.
Capture portal diagnostics, Dataverse audit, flow run ID and external request ID without copying personal payloads into a general incident channel. A second operator should resolve a synthetic incident from the runbook.
Price verified users, transactions and support
Model authenticated users, anonymous page views, Dataverse storage, file capacity, Power Automate consumption, connector licensing, environments, monitoring and support hours from measured volumes. Mark growth, peak and retention assumptions.
Compare the same journey against a custom Azure application, a simpler SharePoint/Power Platform pattern and a hybrid option. The score includes delivery skill, security review, accessibility, release effort and whole-of-life support.
Record the fit decision and rejection triggers
Accept Power Pages when the proof meets identity, isolation, journey, ALM, operations and cost thresholds. Reject or redesign when the relationship model cannot be enforced, the user experience depends on unsupported customisation, required throughput exceeds the measured architecture, or the operating team cannot sustain it.
The decision applies to the tested service and volumes. Re-run the proof when identity, data model, licensing or Microsoft behaviour changes materially.