Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2021 Release Wave 2Discover the latest updates and new features releasing from October 2021 through March 2022.
2021 release wave 2 plan
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
In our educational recruiting process, we interact significantly with minors. While following all appropriate laws and statutes, we as an organization also have policies to follow when keeping track of a minor's information. We are able to use the minor's name and DOB for identification purposes but only those who directly interact with minors can have access to their contact information. However, once a minor reaches 18, we want them to be accessible by other users.
Obviously we want to avoid duplicates but situations like the following are likely to occur: someone interacts with a minor and puts them into the CRM. This record is restricted to users with certain permissions. Once that minor turns 18, they again interact with another user who, unable to see the minor's previous records, enters them in again, creating a duplicate.
So, how would you handle this situation? We currently have one business unit and would like to keep our security roles as uncomplicated as possible. How much would field security play into this? How difficult would it be to automate changing security roles once a minor turns 18? What's the best way to prevent duplicates while also protecting the minor's contact information?
A lot of this depends on more information of your setup. To avoid changing your current 1 BU and to not completely redo your security here is one option. If its a no go, Im willing to take another shot.
1. Make a custom entity for 'minors'
2. Make a new security role that only gives permission to this entity.
3. Give the role either to the specific users or a team (then youre using team security)
- At this point only certain users can see the minor information and they dont have a contact record (assuming they are currently contacts).
Now, to handle the 18th birthday
1. Have a lookup to contact, which is empty until they turn 18.
2. Also track the DOB on the new entity.
3. If you have access to Flow/Power Automate this will be easier, because I dont want to have you use a WAIT/TIMEOUT condition.
- Make a flow that runs 1x per day, List Records in the new entity that have NULL contact lookup and Today minus DOB is 18 years old or greater
- For all records returned create a contact and populate the Contact Lookup field.
If you do this, then you only have to manage a team/security roles assigned to users going forward.
This is excellent! Yes, the minors are currently contacts and will be treated exactly like any other contact. Sounds like we could just copy the Contact entity and rename it which makes that aspect of it pretty simple. And I do have access to Flow so I can definitely have that created.
One small hiccup - there are occasions where someone who doesn't normally interact with a minor will have an interaction and need to record it. Besides the obvious solution of having them ask someone with the proper role to record it for them, do you see anyway that someone without the proper permissions could record this information themselves within the Minor entity?
Should the 'one off' person see the data once its been created/recorded? - if No then you could try giving everyone create rights to the new entity (im not 100% sure this would work if they dont have READ).
If the 'one off' person was on another team with access its possible, but then the main/proper team wouldnt be able to see the record.
Maybe two new roles? One role for Global access (the proper team) and one role for Owner access (the one off group).
- Then one off person can create and view records they own and the 'proper team' can see all the minor records? Not sure if that breaks the rules of limiting the number of people.
Preferably, that person would be able to see the records they've created. The two new roles solution seems to solve that issue completely without any major security headaches!
What would be a good way to prevent duplicates within the Minor entity? Say two separate people in the Owner Access role have two separate interactions with the same minor (a possibility for us) and both try to enter them in. Is there any way to prevent duplicates from being created when both only have read/write owner access?
Off the top of my head, I didnt think of anything. You'd probably be best off having duplicate detection rules setup and have someone either alerted or looking at that rule/report. At that point its really not going to be 'built to stop creation of duplciates' and more, how do you want to handle it if two people interact, are not aware, and try to enter the same person.
You could try setting up a key for the entity, but I'm not sure that would stop creation/what the error would look like based on security.
Idea from way out there, on create on record trigger a flow to query if the minor exists already, if true, send an email to the two people or anyone who can handle it, to alert them.
Some mix of duplicate detection, flows and alerts would likely solve this. These suggestions are a good start! Thanks so much for your help!
Business Applications communities