There have been some changes to terminology since I first wrote this:

  • Entity Permissions are now known as Table Permissions and entities are now known as tables
  • Scope is now known as Access Type

Note – depending on when you last updated your portal solutions, yours may still use the old terminology

Okay, let’s confront the elephant in the room… permissions and security trimming aren’t the most exciting topic when learning about portals – especially if you arrived here as part of your journey into mastering the Portal Web API. However, there’s no denying the fact that they’re absolutely necessary and foundational to a successful portal project that provides secure access to your organisation’s precious data and processes… so keep on reading!

In this write-up, I compare portal security to analogies from the security model in Dynamics 365 and model-driven apps. If you aren’t yet familiar with those, I highly recommend you start by reading Paddy Byrne’s excellent content on Securing the Dataverse over at Virtual Power Group

Otherwise, here are some analogies you might find helpful:

  • Each table permission is like a key
  • A web role is like a set of keys (each portal ‘user’ we assign this web role to gets all the table permissions associated with it… all the keys in the set)

Similar to the security roles and privileges you’d configure and apply to users within Dynamics, table permissions and web roles allow us to apply ‘Record-level’ and ‘role-based’ security for portals.

Users and ownership in Dynamics vs Contacts and relationships in Power Pages

One key difference is that the privileges within a Dynamics 365 security role are dictated based on ownership – the relationship a user, their team, business unit or organisation has with records in a particular table. Users and ownership mean nothing in the context of portal security.

As you may be aware, portal ‘users’ are actually Contacts and the basis of row based security is the relationship that the logged in contact (or their account) has with the record.

For example, when we log in to online banking, we expect to see the equivalent of contact scope; the balance and statements for our own bank accounts only, and that no other customers get to see information about our bank accounts. If we have a business or joint account, perhaps we’d open up the data model so that multiple contacts could have a relationship to the bank account

In order to be security-trimmed on the portal, each table must either:

  • Have a direct relationship (eg a lookup or a many-to-many relationship) to the Contact or to the contact’s Account record (e.g. a case where either the contact or its parent account are selected in the Customer field)
  • Be the child of a record that has a direct relationship to the Contact or Account table (think notes and/or activities related to a case)

Table Permissions

Table permissions are equivalent to the table-level privileges within a security role in Dynamics. Here we determine what anyone with the selected web role(s) is permitted to ‘do’ with those records:

  • Read
  • Write
  • Create
  • Append
  • Append To

Note – I go into these in more detail shortly, right after ‘access types’…

Access Types

The Access Types for Table Permissions are similar to the level for privileges within Dynamics / Model Driven App Security Roles:

Privilege levels for a Security Role in Dynamics:

Privilege Levels in the Customer Service Representative security role in Dynamics 365, highlighting the Key which shows access levels of None Selected, User, Business Unit, Parent: Child Business Units, Organisation

Access Types for a Table Permission in Power Pages: Access Types for Table Permissions in Power Pages. Access Types displayed: Global access, Contact access, Account access, Self access

Global access type is similar to Organisation level privileges

Account access type is similar to Business Unit level privileges in that the user / contact doesn’t necessarily own the record directly but the contact belongs to the team / company that does ‘own’ the record

Contact access type is equivalent to User level privileges

Tip: If in doubt, follow the trail back to the contact

Access type Definition Examples
Global Allows all portal users to see / interact with all records, no relationship required, no security trimming applied Allow everyone to see and select all the products you offer / the full list of subjects
Contact Allow portal users to see / interact with records that they have a direct relationship with Personal bank accounts where they (the contact) are the customer / account holder
Account Allow portal users to see / interact with records that their account has a direct relationship with Invoices where the portal user (contact)’s parent account is the customer
Parent Allow portal users to see / interact with child records associated with a record with which they (the contact) or their account has a direct relationship with Attachments regarding a bank account where either:

a. the portal user (contact) is the customer / account holder

b. the portal user’s account is the customer / account holder

Self Allow the portal users to see / interact with their own contact record Logged in portal users (contacts) are able to amend their contact information and preferences on the Profile page in the portal

Once the access type is defined, privileges allow you to control the level of access they have to their records – what can they ‘do’ with those records?

Privilege Description Example
Read See existing records View a list of cases
Write Edit existing records Update an existing case
Create Create new records Raise a new case
Delete Delete existing records Delete portal comments
Append Relate records for this table to other records Attaching a document to an application form (The Append privilege is required on the table that the portal user is attaching ‘from’ i.e. the document)
Append To Relate records to this table Attaching a document to an application form (The Append To privilege is required on the table that the portal user is attaching ‘to’ i.e. the application)

Note: Table permissions are more granular than security roles. Unlike security roles, granting table permissions, let’s say notes regarding cases where I am customer (a child permission of  ‘cases where I am customer) is specific to that relationship only and doesn’t mean the user then has permissions to see all notes ‘across the board’ (such as notes regarding opportunities where I am customer, notes regarding my contact record or even ‘orphaned‘ notes).
You’ll need to set up separate permissions for each relationship e.g. access to notes related to Cases within contact access type doesn’t provide that same contact access to notes relating to Opportunities, etc.

What about lookup columns? Are they a pain?

Example: I need to populate the Customer column on a case

The portal user needs a web role with permissions to:

  • Read, Create / Edit and Append To the Case table


  • Read and Append privileges on the Contact and Account tables

So that’s how we define the permission but how do we give someone those privileges?…

Web Roles

The Web Roles list allows you to specify which web roles a portal user must have in order to receive this table permission.

It’s very important that you remember to select one or more web roles otherwise the permission isn’t applied to anyone.

Where table permissions are like privileges within a security role, a web role is the equivalent to a security role.

By default, the portal solution includes 3 web roles; authenticated users, anonymous users and administrators:

Out of the box web roles

  • Anonymous users (any visitor that hasn’t logged in. This role might be useful for lead generation or a contact form.
    Note – Even registered users that are yet to sign in are treated as anonymous.)
  • Authenticated users (contacts that have logged in to the portal)
  • Administrators (enables front-end editor and ability to refresh the cache and rebuild search index)

There’s nothing you need to do to manually assign someone the anonymous users or authenticated user web roles, they’re given automatically based on whether the user (Contact!) is logged into the portal. However, you need to decide who you wish to give administrator access to.

For customer self-service, the most commonly used web role for table permissions tends to be Authenticated Users, meaning that only logged in portal users receive this permission. 

If, for example, your portal has an enquiry form allowing the public to submit leads without the pre-requisites of registering for and logging into the portal, you would add the Anonymous Users web role to the table permissions for the Lead table.

In addition to these out-of-the-box web roles, we can create any number of custom web roles to provide more granular security trimming.

Examples of ‘personas’ that might require different levels of access (web roles)

Here are some more examples of where it might make sense to create additional / custom web roles for your portal project. Think of how the required level of access and level of visibility within the same web app would differ between the following personas:


Teacher vs Student vs Parent


Landlord vs Tennant vs Guarantor vs Solicitor


Free Listeners vs Premium Subscribers vs Record Label Staff vs Independent Artists

Tiered access

Membership tiers / support plans e.g. Gold support plan vs Silver support plan vs Free


Further reading – the sequel

Interested in learning more? Would you like to see some examples to help consolidate your learning? Check out part 2 where I break down the table permissions that come out-of-the-box with the Customer Self-Service starter portal

Franco Musso

You may also like

Leave a reply

Your email address will not be published.

More in Power Pages