In our business it is certainly not uncommon for one customer Account to have multiple/different Customer Sites associated with it (e.g. large property managers or commercial real estate owners with multiple sites). If that was it, then a parent and subordinate relationship between two Account types (i.e. the Billing Account and the Site) would suffice. But in our business it is also possible to have multiple Accounts associated with a single Customer Site. For example, on Customer Site XYZ, we might perform work for the tenant, the owner, a general contractor (GC) or a construction manager (CM). Hence, we were thinking a Many-to-Many relationship makes more sense. We also have entirely different data fields we want to track for the Customer Site vs. the Account.We additionally want the Customer Assets (equipment we install/service) to be subordinate records associated to the Customer Site (parent entity), so that when the site changes hands and is purchased by a new Customer Account, we can easily maintain the continuous service history of the Site and Assets under the new ownership Account.Does anyone see any reason why we shouldn't create a custom entity for Customer Sites? Is there inherent functionality in the Account entity and how it relates to Work Orders, Cases, Invoices, Orders, etc. that would make this a bad idea?Appreciate any feedback the community can provide.-Rob V.
RobertI would like to know what those risks are as well. We currently have over 300+ custom entities and I have been updating from 8.2 to 8.2.8 (8 updates with no issues). I hope your consultant is not pulling your chain just to avoid work. *wink*
The best question to ask about creating a new entity is how many fields are there that won't be used by the account entity? If it's just one (the discriminator) then I would go with your consultant's recommendation.
A self referencing N:N relationship is supported in Crm
or you can also use connection roles.
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/describe-relationship-entities-connection-rolesBased on what you have written, I would say connection roles are your best bet.
If you've found this thread useful, dive deeper into User Group community content by role