Power Apps Portal Studio has built-in functionality that allows you to change the appearance of a website without writing code. In this blog post, we explore how it’s done!
The duplicate detection functionality in Microsoft Dynamics CRM was developed to help you maintain integrity of your data. You can configure duplicate detection rules for any entity in CRM. The duplicate detection can be used during the creation of a record, updating a record, during imports or as a scheduled job.
One thing to note is that the duplicate detection setting only allows you to check against records that you have access to in CRM.
Let's say, for example, that a salesperson attends a conference and receives a handful of business cards. He would like to create them as leads in CRM to validate that they actually want to do business. Currently, this user has full access to leads, but his access to the accounts and contacts are only for records that are in his business unit. The system administrator created a few duplicate detention rules to help prevent duplicate data in the system:
1. The first rule was set up to check against existing leads.
2. The second one was to check the first name, last name and email address of the lead against existing contacts.
3. The last one was to check the company name against the account name in the account entity.
With these three duplicate detection rules setup in CRM, the system administrator believed they could catch all records that may have been duplicates. What the administrator didn't realize is that when the duplicate detection functionality is run by the user, it only checks against records that the user has access to.
Below is the current organizational structure. There is a business unit based on each territory. Security is set up so that users can only see and access data in their specific business unit, except for leads.
Let's say that a user in the Eastern BU creates a lead, but a contact already exists in the Midwest BU. Since the user doesn't have access to check against the records in the Midwest BU, this would allow the user to create the lead record. If the contact existed in the Eastern BU, the duplicate detection would have caught this duplicate record.
There are a few different ways to handle this situation:
The option you go with will depend on how your organization handles the way data is shared among its users.
If you need help developing best practices for your particular organization regarding security roles and duplicate detection, PowerObjects can help. Contact us for more information.