At PowerObjects, we often find that clients desire the option to perform data migration on their own. This may be due to the sensitive nature of the data or because of an effort to ensure internal resources know the migration/integration packages well. Regardless of the reason – and no matter the experience and skill levels of your organization’s data integration teams, pitfalls exist for those not experienced with Dynamics 365. As such, we insist on the allocation of time and resources to provide education and training to the internal teams responsible for the ongoing integration. Otherwise, your business may face multiple trial-and-error data runs to get it right.

One common mistake we see stems from failure to set the Owner of records when creating them in Dynamics 365. By default, Dynamics will set the Owner of each record to whichever User record was used during the migration. Often, this is an admin user with the System Administrator role – we’ll call it “Admin” for the sake of this blogpost. The records will import without issue and record counts will yield expected results. Great, right? Not so fast, as this is where a full understanding of record ownership in Dynamics is crucial. When a user logs in from a different business unit or even the same unit but with lesser permissions, they may not see all the data! Not good.

See, records are owned by users; each user resides in a single Business Unit and is assigned Security Role(s). The combination of Business Unit and Security Role(s) determines which records each user can see. Of course, if all users are granted Organizational access to records, you’ll likely never have this issue. Likewise, if your organization has only a single Business Unit, this potential issue is not applicable. However, many businesses – especially larger organizations – require multiple Security Roles and Business Units.

Let’s consider a scenario in which an organization has a Business Unit structure with a top-level unit named “Contoso.” A child Business Unit of Contoso is “United States,” and children Business Units of United States are “East” and “West.” Records imported with the owner as a system administrator (Admin) who resides in the Contoso Business Unit means that all the imported records will live in top-level Contoso. When other users are added to East, West, or United States, they will not see the records in the system if they are given Business Unit (or lower) read access to the data.

Without testing visibility of data with roles other than Admin, you will not know you have this issue. And considering that your data migration will likely contain multiple jobs for multiple entities, as well as references to other entities, you could end up having to reload all of your data. With the possibility of millions of records in your migration, that data reload could set you back several days or even weeks. Also consider that not seeing the need to have all of your users loaded in Dynamics 365 could lead to a scramble to get all personnel added as users and making updates to the migration jobs.

Now, if you’re thinking No worries… I can just update the owner of the records with a subsequent job, you’re correct in that being a possibility. But… when you go to load your production environment, you will be adding time to your migration to make a second pass on all the records. Why not just avoid that problem entirely by setting the Owner appropriately from the very beginning?

Hopefully this post helps you avoid having to learn this lesson the hard way. For more Dynamics 365 tips and tricks, be sure to subscribe to our blog!

Happy D365’ing!