crm-cat / dynamics365-community-schema Goto Github PK

In Government CRM is used for official records. At the moment data needs to be copied from the CRM to an approved record keeping system.
CRM records consequently need fields related to record keeping (retention period, record type, etc)
CRM records also need fields related to security classification e.g. In-Confidence.
CRM records also need to be able to be restricted to specific groups of people for records deemed "sensitive" e.g. in general Cases are viewable by all users but some Cases (perhaps of a politically sensitive nature) should only be viewed by a designated team.
PS I like the idea that an entity can be made up from a group of "sub-entities"

Belgium addresses can have both Dutch and French names.
Swiss address can have both German, French and Italian names
Canadian addresses can have both English and French names

It is quite common to use accounts to represent the legal aspect of an individual. Contacts are then used to provide correspondence contacts, executors, next of kin etc.
How are these accounts recorded along side other organisation accounts such as companies?

A customisation I often do is to add an extra test field to Account entity for "Also Known As" or "Trading As". Name might be some combination of these eg "Trading As / AKA". This field is added to the Quick Find fields for searching. Intent:

• encourage (or require) users to put full legal name as the Account name (OOB field). Especially important if Accounts are also used for ERP / financials and synchronised there.
• at the same time enable users to search based on another name or abbreviation the company is known as publicly or colloquially.
• enable users to enter any name in this field that they think someone might type in when trying to search for this record in future
• Avoid having to use wildcards to avoid typing high-frequency or longer words (eg "University of...", or even just "The...") as this can lead to many false positives in search results eg "*Manchester"

Use cases:

• website branding or abbreviated names are often different from actual incorporated name but might come to mind first when searching
• public sector and education in particular often use abbreviations or acronyms when names are very long, and especially when many start with the same words (prisons, universities). Examples: HMP Dartmoor, DEFRA, UMIST, UWE etc
• organisations known colloquially by a name which is the "wrong way round" from their official title eg Oxford University cf The University of Oxford
• companies formed by mergers where they might still be known in one country or another more by one name than another. Daimler-Chrysler cf Daimler cf Chrysler
• company names which are commonly mis-spelled or wrongly abbreviated. Does "Sainsbury's" have an apostrophe? Coca Cola? or Coca-Cola? IBM or I.B.M. or International Business Machines?

This simple field can give users a lot of control over future search terms, keep actual Account names more accurate, and improve search results at the same time.
Is this the sort of thing that would make sense to offer as a schema extension? Or ami I barking up the wrong tree here?

It is common for contact addresses to be marked as being the same as the account address. What is the schema for this so that logic can be provided to automatically update the contact address when the account address changes.

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).

Hi,

I was wondering what will happen with other languages in the Common data model?

E.g. I live in Belgium and set O365 and or CRM online organisation up in Dutch or in English (whatever the customer preferres). If it is setup in Dutch, all the field names in the online database will probably also be in Dutch.

I'm wondering whether or not this will cause issues, as I would love to contribute to the CRM365 Schema Project, but a lot of our customizations are not in English.

e.g.

• Managed/Is managed by
• Replaced by/Replaces
• Team member with

Would anyone be interested in being the champion for their 'areas' of expertise?

Initially you would simply need to comment on this issue important area-specific information you feel is important to include in the schema

Things to note:

Standard OOB CRM includes the functionality which will be checked when sending marketing campaigns out of inclusive of the standard fields

Third party Marketing Applications often add to/customise to this

Marketing information can also include social media information e.g. Twitter IDs and LinkedIn accounts

The address1 and address2 fields can be used for so many different purposes. Can we standardise their use?

Following CRMUG.

My idea would be to have various templates of schema's to choose from when initially starting a CRM environment. This would act in a similar way to the templates you have when you start a visio / publisher / powerpoint or other office file.
These templates would give the common generic entities needed for a particular business sector.
Some examples below;
Council
Lettings & Sales (Homes)
Club Membership
Retail
Business To Customer
Business To Business
Insurance & Finance
Banking
Holiday & Travel
This would move away from trying to create a one size fits all approach, and could take the key common attributes of a particular area. It would also allow quicker and easier development, as once a scheme is built the project could work on a second and so forth. Any template could be revisited and added to without impacting other business industries.

This was discussed at CRMUG UK Nov 23rd Session

The main points are summarised below:

• Sub-classes are a clean approach of allowing extensions to the main Account and Contact
• It allows for easy separation of concerns in relation to the schema
• Maintains out of the box functionality for the Account and Contact
• Provides no disruption for other solutions utilising the Account and Contact