Craggle
commented
7 years ago Hi peterf1, I think you've perfectly highlighted exactly why the out of box entity relationships with "customers" do not always exactly fit the purpose for all use cases, and for me, validates why this project exists. There are two sides to this, on one hand we have ...
A "How dynamics CRM currently works"
and the other
B "the common customisation / tweaks that are regularly made by various industries to fit the model to a business requirement".
In the scenario above, the Account Entity is re-purposed into "Organisation" and Contact into "Individual". The problem I see here, is that the label is now different to the purpose of the record.
So, With account being Organisation, this means it's purpose as a grouping entity (or container), is somewhat lost by its new title. For the out of box implementation, an account is not a company or organisation, but we all think of it like this instinctively, and with the CRM platform evolving over time we see significant focus on Accounts and Contacts branded "customers". (hence the incident lookup you mention, labelled as customer). and this is what we learn from, and use to guide us, perhaps down a wrong path.
The same applies to contacts, I've seen these renamed on countless projects to "Customer", "Person". and even in extreme cases I've seen contacts renamed to "account" or "Entity". With renaming, we re-brand a record's purpose. but with the out of box schema, that re-branded purpose often does not then fit with the wider system.
For me, I think your example is excellent in highlighting where were we are vs where we want to be. Specifically the issue... "A Case (incident) can be related to more than 1 Organisation and /or Individual (so the customer field is irrelevant)."
I agree with this, for your scenario
If I translate this back to standard labelling, Its the case that an incident can be related to many accounts and contacts. If we understand an account to be "A Legal Entity" and a Contact to be a record containing contact information (nothing more, not a person or individual), then perhaps the incident lookup to customer is more accurately described in your case as "Raised by" to link the incident to the source of its creation, and a method of direct response. Who and what the incident relates to, should be a separate relationships. Perhaps connections such as "involved parties"?
What I feel the schema project to date introduces (as of now) is a specific representation for a person (individual) and Company (Organisation) which are not a rename of the contact and account but are instead new Entities related through defined connections. I think your use case fits that model, to allow incidents to be "raised by" either a legal entity, or a specific instance of Contact information, related to an individual. then, the incident requires just a little customisation to relate other parties which are then correctly defined using these new entities (related organisations, Related Persons)
Apologies for the long reply, I promise I did try and keep it succinct. but I'd love to hear your thoughts on this, or perhaps discuss a little more?
peterf1
Very high view
In government the main focus on CRM is to use it for Case management not Sales. Cases are usually connected to Organisations (accounts) and/or Individuals (contacts).
Organisations are legal entities with a government issued Business Number. They need to have a contact address, email and phone number (independant of an Individual). In many systems the CRM is not the source of truth for the Organisation so actual source identifiers need to be stored to enable synchronisation.
Individuals are citizens. They need to have a contact address and/or email and/or phone number (to make them unique). In many systems the CRM is not the source of truth for the Individual so actual source identifiers need to be stored to enable synchronisation.
A Case (incident) can be related to more than 1 Organisation and /or Individual (so the customer field is irrelevant).