Model Driven Form show hide fields if table contains record with certain field value

(0) Share

Report

Posted on by Billy

396

Hi there,

I have this weird and complex problem, I don't know how to explain this, but I have a Contact Person table that I have connected to a Reminder table to create reminders for certain contact persons.

The issue I have is that I am trying to make Reminder settings, so each contact person can be contacted based on those settings, so they only get those specific reminders. Now some of these settings are also only for internal contact persons which are also systemusers. I didn't want to change the systemusers form as I don't want users to be able to change that information.

Anyway, I'd like to show or hide fields meant for internal contact persons only so those fields won't be shown for external contact persons.

Now to do this I would have to check whether there is an equivalent systemuser and based on that I would be able to show or hide these internal reminder settings.

My question is what would be the best way to achieve this??

I was thinking to use a separate field that says whether this record has an equivalent systemuser record or not, or otherwise to use JavaScript to determine this. Except that I don't know if it is even possible to do either of these options.

To give you an example I have an internal contact person called Mike Reeves, and he needs reminders about the projects but only of projects that were created for his business unit only, so I change the settings for this contact person as follows:

I set the project reminders such that he needs updates of projects in de status Lead, Quote, Sent, Won and that only for projects of his business unit. So I set 2 fields, 1 with the different project levels and 1 field that kinda act as ABAC (Attribute-Based Access Control).

Any ideas on this?

Thanks in advance,

Billy Cottrell

Categories:

Microsoft Dataverse with Power Apps

I have the same question (0)

All responses (3)

Answers (1)

EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Hi @Billy_C,

To simplify why not use the out-of-the-box (OOB) User (systemuser) table for internal contacts? That way you won't have to sync or have additional fields to check, and allows you to have additional filters like "current user" or current team. You can still import old as system users via Excel of CSV import and for new user you may not necessary have a license for all these users, but the high-level idea is to assign a temp license to the user, wait until it syncs into Dataverse and then unassigned the license Those users will be automatically be created in Dataverse and then be set as inactive once the license is unassigned. You can automatically assign the license when new users get created in O365 and unassigned once they got created in Dataverse with the help Power Automate flows and group base licensing.

If you need to have internal contacts as Contacts then perhaps with Power Automate flow might be the easiest with the Dataverse connector. Have the flow trigger whenever a contact is created/update and when a User is created/updated because the contact might exists prior being an internal user. You can check if the Contact is an internal user with the connector action and think that you might need to check in O365 since users might not all be in Dataverse if they have no license.

Hope this helps!

Was this reply helpful? Yes No
Billy 396 on at

Like (0)

Report
Copy link

Link copied!

Hi @EricRegnier,

I'd rather avoid having to use any of the OOB tables. The biggest reason why I didn't want to use these, is because I didn't understand how they work nor what they do and since there isn't enough information to explain it I just started to avoid it. So instead I started to create a 100% customized environment where the OOB tables aren't being used. So at the moment, we haven't used any of these OOB tables, but I am getting the impression that one cannot create a 100% customized environment without using the OOB tables. There are many reasons why I am not using them and I can't list them all, but they all end up at one point which is I don't understand any of it.

Also, I don't think that Power Automate will solve the issue at the moment since there are internal users that also work at other companies, and at the moment there is only 1 email address which is set to the email address of the other company they are working at. At the moment all users are using Powerapps, so there is no need to check in O365 as I only would need to list the Dataverse system users. We won't add users who won't use the system anyway, so all system users will be actually using the system and have a licence.

I guess for now the best idea would be to manually set users to external or internal and show and hide the other fields based on this and then later determine the best way to automate the external or internal value.

Thanks in advance,

Billy Cottrell

Was this reply helpful? Yes No
Verified answer

EricRegnier 8,720 Most Valuable Professional on at

Like (0)

Report
Copy link

Link copied!

Even though you might not reference or understand some of the out-of-the-box (OOB) tables/entities, I strongly recommend you try to leverage some of those where possible especially for Account, Contacts and System Users. See these tips for more info: https://powerusers.microsoft.com/t5/Power-Apps-Community-Blog/Top-15-best-practices-when-configuring-Power-Platform-and/ba-p/850804

You can always create new forms and apps and only add what you use and leave the OOB apps/forms/views as-is.

If internal users can access Dataverse then they must exists in O365 (even as guests) and have a license assigned... The Power Automate flow would check based on the O365 username not the email which is the Username field/column on the User table.

Hope this clarifies, and suggest to have a look at: https://docs.microsoft.com/power-platform/admin/grant-users-access to better understand user management and security. It will probably save you some time and effort as opposed to re-invent the wheel...

That said, if you can't for whatever reason, manually manage a user type (internal, external) would work and can show/hide with business rules or JavaScript.

Hope this helps!

Was this reply helpful? Yes No