How to Keep Each Client's Data Separate in Power Pages

A client portal must do more than ask users to sign in. It must ensure that each authenticated person can access only the records, documents, and actions they are authorized to use. In a Power Pages portal backed by Dataverse, this requires a deliberate relationship model, web roles, table permissions, and testing of both normal navigation and direct access attempts.

The key design question is: what business relationship proves that this user is allowed to access this particular record? The answer should be represented in the data model and enforced by server-side authorization - not inferred from a field or filter displayed in the browser.

Start with the organization and contact model

For a typical business-to-business portal, a client organization may have several contacts. Those contacts may need access to shared onboarding records, or each may need access only to their own submissions.

Document these rules before configuring the portal:

• Can several contacts from one organization see the same onboarding case?
• Can a contact belong to more than one organization?
• Are any records private to a particular contact?
• Can external users create new cases, or only respond to invitations?
• Can one user act on behalf of another contact?
• What happens to access when a contact leaves the organization?

A model that assumes one contact per organization may become a security and maintenance problem when the business later needs multiple users. Model real relationships rather than relying on assumptions hidden in the UI.

Understand the security layers

Power Pages and Dataverse use several related mechanisms. Their exact configuration depends on the solution, but the design should consider:

• Authentication: Establishes who the external user is.
• Web roles: Group users according to their portal access responsibilities.
• Table permissions: Define which Dataverse records a role can access and what operations are permitted.
• Record relationships and permission scope: Determine which records are accessible through contact, account, parent, or other supported relationships.
• Page and site configuration: Control access to portal pages and functions where applicable.
• Document access controls: Protect files as well as the records that refer to them.

These mechanisms are complementary. A restricted page does not prove that every underlying record or file is protected. Consult current Microsoft Power Pages table permissions guidance and verify the implementation against the current platform behavior.

Design permissions around business rules

Consider a portal where Organization A and Organization B each have onboarding cases. A user from Organization A must not read or modify Organization B's cases, even if they guess a record identifier.

A sensible design process is:

1. 1Identify the record that establishes the client relationship, such as the organization or contact.
2. 2Define which roles can read, create, update, append, or perform other relevant operations on each table.
3. 3Configure supported permission scopes and relationships so access follows the intended ownership or association.
4. 4Review related tables, such as documents, tasks, and submissions, for indirect access paths.
5. 5Ensure that fields intended for staff only are not exposed through forms, lists, APIs, or other portal features.
6. 6Test all permitted and denied operations using realistic external accounts.

Do not assume that hiding a button, removing a record from a list, or filtering a query in client-side JavaScript enforces authorization. Those measures may improve usability but are not a substitute for server-side permissions.

Test the failure cases, not just the happy path

Create at least two test organizations with multiple test contacts. Use records and documents belonging to each organization.

Record the test account, role, test data, action, expected outcome, actual outcome, and evidence. Repeat the relevant tests after changes to relationships, roles, forms, workflows, or document handling.

Protect documents and related records

A common design error is to protect the onboarding record but overlook the file. A document link, storage configuration, or integration may create a separate access path.

For every file, determine how authorization is checked, whether the URL is publicly accessible, how staff and client access differ, and how access is revoked. Test the actual file access path as an unauthorized user - not just whether the file name appears in a list.

See how to collect client documents online using Power Pages and SharePoint.

Document the security model

Handoff documentation should explain:

• User types and web roles.
• Table permissions and their scopes.
• Organization/contact relationships.
• Staff-only data and operations.
• Document access rules.
• Test scenarios and outcomes.
• Account provisioning and revocation procedures.
• Known limitations and administrator responsibilities.

Security is an ongoing responsibility. Changes to the data model, new tables, additional integrations, and new portal functions can alter the access paths. Review permissions as the solution evolves.

Plan the portal before configuration

Client-specific security should be part of the initial discovery and architecture - not a final checklist item. The client onboarding portal overview explains how security fits into the overall design. Use the requirements checklist to document user relationships, data access, and testing requirements before development begins.