Share
ReportGreetings,
I would like to request your opinion on the best approach in the following scenario.
When migrating a 20-year old, legacy application to Dataverse, consideration to use existing common and system tables is made as part of the design process.
One of these tables is the systemuser (User) table. In an ideal case, all users of the legacy app are still alive and employees with active user account in the customer's tenancy.
For users without a valid D365 user account, we just need to create a D365 user account and set them up with a proper license and access to the new solution. Job done.
However, we do not live in an ideal world and chances of having historical data relating to former employees are quite high. When it comes to historical data, we would like to keep every piece of information of course.
To make it more complicated, some of the former employees never existed in the current AD/AAD since they left the business before rolling our Active Directory services. So I am aware of the following three options to solve this problem.
1.) We create and license temporary D365 users accounts for the single sake of relating them to historical records in Dataverse. This method involves a bunch of non-dev tasks, additional budget to purchase D365 licenses, requesting approvals, revoking licenses after project completion, etc.
2.) We move away from using the systemuser table and create another entity that removes the need of mimicking former employee user accounts. (I hate this idea as we lose the benefit of integration with the built-in User table.)
3.) We create a polymorphic lookup field that relates both the systemuser and another table in which former employee records are recorded. (This approach will have impact on how the end users need to use the lookup field on the forms.)
Please kindly advise on how you overcome this problem when migrating applications to Dataverse.
Thank you,
Bela
All responses (
Answers (
291,280
