Answered

Security table permissions based on contact that could be related to many accounts

(2) Share

Report

Posted on by wilmandx

Hello !

I am working on a Power Pages Portal and I am facing a challenge regarding Power Pages security roles in my current dataverse configuration. We want to support many to many relation between contacts and accounts, so we have created a new table "Contact Account Authorization". Now we have another table called "Projects" and we want let authentified users to see only projects related with his accounts (our table many to many), the project table has the link with the account table.

We tested permissions on "Project" table using account level but this is not working, Is there a other way to achieve this? maybe also reading rule in dataverse using a plugin ?

Thanks

Categories:

General topics

I have the same question (0)

All responses (3)

Answers (1)

Verified answer

Fubar 8,487 Super User 2026 Season 1 on at

Like (4)

Report
Copy link

Link copied!

Table Permissions with scope = Account, means the Contact record is linked to the Account using the out of the box parent account /company.

You will need to establish a set of table permissions that use scope = parent for the respective table relationships (in the designer these are called child permissions, but in the Power Pages Management app you will see they have scope = parent).

edit: you should be able to do a Table Permission with scope = Contact for the Contact Lookup on Contact Account Authorization, then a table permission with scope = Parent for the relationship between Account and Contact Account Authorization, and then another Table Permissions With scope = Parent for Account to Project.

Was this reply helpful? Yes No
aofosu 105 on at

Like (0)

Report
Copy link

Link copied!
I have a similar situation, but mine is a little bit complex. Realize that when you follow @Fubar's approach, it allows a single contact to traverse through the permissions to get to the Project table like this Contact -< Contact Account Authorization -< Account -< Project.

@Fubar I would like to pick your brain on this solution:

In my case, the client wants contacts belonging to one account to collaborate on a project. I proposed the following:

Use the OOB parent organization, which allows contacts to belong to one account.

Have a bridge table on Account called Authorized Account

Connect the Authorized Account to the Submission table so that partner organizations can submit data on behalf of their delegatees.

Then again, the client wants a contact who belongs to an account to belong to another account where they can collaborate with the contacts under that account. My answer to them was that that user would need to create another user profile for that account. With your expertise in this area, what would you suggest? I would like to know if I am missing anything or if there is an alternative way to do this where a contact can belong to more than one parent account.

Thank you!

Was this reply helpful? Yes No
Fubar 8,487 Super User 2026 Season 1 on at

Like (0)

Report
Copy link

Link copied!
@aofosu key thing to remember is that the access is granted based on the relationships between records, so to give access or remove access you need to be able to add/remove a record in a way that will break the relationships path to the target record. I would create a link table between the Project and the Contact e.g. "Authorised Project Contact" - would have a lookup to Contact, Account, and Project (the account lookup is just so you can show it against the account, the permissions are for the Contact and Project).

Table permissions

Authorised Project Contact: scope = Contact

Authorised Project Contact -< Project: scope = Parent

(note: account is intentionally not in the scopes above)

You then have to manage the adding/removing of the Contact e.g. subgrid on Account. The Account itself does not give permissions it is just there so you can display the record against specific accounts.

Was this reply helpful? Yes No