Company-Employee hierarchy Powe Apps Portal

(0) Share

Report

Posted on by Noorahmad004

Hi Folks

I have a requirement to implement in Power Apps Portal. Please check the below:

I have a "Company Products" table in Dynamics 365 and this is exposed to portal users.
A company owner can signup in portal in order to add company products in this table (Company Products).
How another employee of the same company can signup and become the part of the same company and have access to records.
Company owner also wants some his employees to add records in this table too (Company Products).

How can we achieve this in Power Apps Portal.
Would really appreciate.
@OliverRodrigues

Categories:

Power Apps portals

I have the same question (0)

All responses (8)

Answers (0)

ragavanrajan 7,044 Most Valuable Professional on at

Like (0)

Report

Hi @noorahmad001 ,

Note: Keep in mind that if the Owner of the portal/admin of the portal should add his employee and assign to appropriate web roles. Otherwise, it would expose security risks. As you are allowing anyone to sign up when they belong to the same company.

There are few ways to achieve this. I would do with the combination of Power Automate and Portal Web roles.

The overall idea would be when the person signup and choose a respective company you can trigger power automate and relate records to the appropriate web role.

Steps:

1. As a Owner/Admin of the portal. Create appropriate web roles with privileges

2. Trigger Power Automate flow when the person signup for the role and relate records to the appropriate web role.

3. Configure Web pages, entity forms according to the web role.

Adding two articles to achieve what you are expecting.

PowerApps Portals: How to Hide or Show Content based on Logged in User

https://readyxrm.blog/2019/08/26/powerapps-portals-how-to-hide-or-show-content-based-on-logged-in-user/

Associate / Disassociate two entities with 1: N and N: N relationship using Relate & Unrelate records in Power Automate

https://www.inogic.com/blog/2020/02/associate-disassociate-two-entities-with-1-n-and-n-n-relationship-using-relate-unrelate-records-in-power-automate/

Hope it helps.

------------

If you like this post, give a Thumbs up. Where it solved your request, Mark it as a Solution to enable other users find it.

Was this reply helpful? Yes No
Noorahmad004 27 on at

Like (0)

Report

Thank you @ragavanrajan for the response and the two links are helpful but the problem still remain the same. How can I solve the delegate access problem like: A company owner and his employee being able to add/edit company owned records from the Power Apps Portal.

Was this reply helpful? Yes No
Fubar 8,338 Super User 2025 Season 2 on at

Like (1)

Report

We have one where we allow the Organization to establish their own Portal Users. Registration is not open, and the first Organization user is manually invited to use the Portal. Rather than create contacts and assign Web Roles themselves we give them access to make a request to create, if the request is successful a Contact is created and the appropriate Web Role assigned and a Portal Invite is sent to that new contact. The request to create, allows us to either fully automate or stop the automation and have in internal user manually process/approve it (we don't give portal users direct access to assign web roles, they get a picklist of a couple of items and then we use a workflow to map that across to the web role to assign).

Your web roles need to be established with the correct entity permissions (account or parent through the relationship to an Account lookup on your Company Products record), you would need at least 3 roles - User that can manage their contact's web role assignment (we do this by a request to … and only give them a picklist to select a role from - and not a lookup to the actual web roles), another one to be able to create/edit Company Produce, and another that gives access to read.

Was this reply helpful? Yes No
ragavanrajan 7,044 Most Valuable Professional on at

Like (0)

Report

Hi @noorahmad001 ,

As mentioned by @Fubar, To solve the delegation problem either you do it manually or via automation via the provided links. Your web roles need to be set up properly along with the entity permissions. Once contact is created then it is about entity permissions and web roles to access the relevant records based on the company.

In the signup form.

1. Add a custom field for Account / Company name.

2. Assign an owner with full privileges for the company name.

3. When the user / employee signup by choosing the account name

4. The owner of that account either chooses to approve/reject that person and relate it appropriate web role ( you can do this manually or via Power automate)

5. Then based on the web roles they only see their pages.

Hope it helps.

------------

If you like this post, give it a Thumbs up. Where it solved your request, Mark it as a Solution to enable other users to find it.

Was this reply helpful? Yes No
Noorahmad004 27 on at

Like (0)

Report
Hello yes I got it but the portals will be used by multiple companies.

Company A
User 1
User 2
User 3
Company B
User 1
User 2
My problem is how to make this structure in Portals. One option is to add a custom field on "Contact" signup form for "Account Name" or "Account Lookup", if someone can select an existing account then associate that contact with that account and if someone doesn't selects existing account then I will create a new account record and associate the contact.

A web page will be developed which will accessible to company owner and they can approve/reject the contacts access and this can be achieved via the Web API.

@Fubar @ragavanrajan can you guys please comment on this approach.

Was this reply helpful? Yes No
Fubar 8,338 Super User 2025 Season 2 on at

Like (0)

Report

Depending on your situation, you have to think of Privacy - are you allowed to expose an Account to a person that you do not know if they belong to that Account - This is why we don't use Open registration and get a known person from the Account to request the addition of a Contact (we fully automate this, but it is an authorised person from the Account then saying add a person with this email address to be able to access our data, and this is the privileges we want them to have).

If you have the same Contact for multiple Accounts, then it is just a case of letting them select which Account they are creating the Product for (rather than metadata) with the appropriate entity permission setup (or providing a List View of Accounts, and on an Account record having a Subgrid for the Company Products). And not using the default Account-Contact 1:N relationship but a N:N.

Was this reply helpful? Yes No
Noorahmad004 27 on at

Like (0)

Report
Ok someone from Dynamics 365 sides manages the users and their rights based upon the requirements.
My case is different I will try to explain it again:

Company A
Company A Admin
User 1
User 2
User 3
Company B
Company B Admin
User 4
User 5
Lets say I create the Admin users (portal contact) myself and also their account and the rest of the users signup from portal. Now give an interface to Company Admin users to approve/reject the other users signed up from portal.

All User 1, User 2.... should be able to see only their created records but Company Admin can see all the records, how can I achieve this.

Would appreciate a response.

Was this reply helpful? Yes No
Fubar 8,338 Super User 2025 Season 2 on at

Like (1)

Report

As per the earlier posts, you need to establish a set of relevant Entity Permissions assign them to a respective Web Role, and then assign that Web Role to the respective Portal Users.
If you are talking about a Portal User only seeing their own records then you would use an Entity Permission based on Contact Scope. For the Admin you would have an Entity Permission based on Account Scope (or parental). https://docs.microsoft.com/en-us/powerapps/maker/portals/configure/assign-entity-permissions

We will point you in the right direction, but not provide a full set of entity permissions for your scenario as a lot more info is often required - and it can get complex depending on the precise nature of what you are trying to achieve overall.

Was this reply helpful? Yes No