Share
ReportIn OOTB Dynamics 365 the same address (e.g. Some Address 1, USA) can and needs to be created for two different customers, which gives us challenges in terms of customer asset "ownership" and identification (i.e. ensuring we do not created duplicate customer assets).
An example could be a mall.
Store 1 is created as a billing account with the service account Some Address 1, USA. Upon servicing this customer, a customer asset ABC is created.
4 months later, the the owners of the mall contact us to purchase our services. The mall owners are created as a billing account with the service account Some Address 1, USA.
Since customer asset ABC is associated with the other Some Address 1, USA (belonging to Store 1), we will obviously not see it under the newly created service account Some Address 1, USA.
One could argue - given we can actually identify the customer asset ABC, which in itself is a challenge - that it should be moved to the newly created address. But what happens if Store 1 contacts us again? We will have the same challenges identifying the customer asset, and the process is manual.
One could also argue that functional locations should be used, because they can be "shared" between different service accounts. However, the functional location visualization tree (where customer assets can be shown) ONLY shows the customer assets associated with a specific service account so that gives us the same challenge.
Currently, the only solution we see to the issue is to create a unique service account (integrating to an external database). So in the scenario above, the 2 service accounts with the same address would be populated with a unique ID from the database upon creation, which in turn enables us to create a unique service account automatically. On the unique service account, functional locations and assets would be linked/owned. This ensures it is the unique address which owns the asset (and the functional locations). If the mall gets sold or Store 1 is rented by some other company, they can be created as new billing and service accounts as described above, but the unique address logic would ensure no information about the customer asset and functional locations are duplicated and can easily be found. Also, it would remove the need to manually identify and move customers assets around. In other words, the customer asset is owned by a unique address and in theory not by a customer - a given customer just pays for the servicing of the asset at a given point in time.
It does involve a lot of customization and changes to the standard processes, so have others faced similar challenges which they solved in a better way?
Thanks,
All responses (
Answers (
2,435
