Microsoft Dynamics Platform is often referred to as xRM (where “x” in xRM can represent “anything”) because it enables us as business analysts and developers to customize the standard CRM solution to build custom line of business solutions to address specific business requirements.
When building a custom solution, you often face the question: whether to use a standard entity or to create a custom entity. Making this design decision is partly art and partly science. Also, your experience (both good and bad) from the past projects plays an important role.
In this article, I will discuss a few basic guidelines that I have used. Note that the following guidelines are based on Dynamics CRM 2015.
Native features and functionality associated with the standard entity
Are there any features and functionality associated with the standard CRM entity that you would like to leverage and that cannot be replicated without significant effort and custom development? If so, it will be in your best interest to use the standard entity. It will save you much effort in terms of development and maintenance in the long run. Also, you will be able to take advantage of future feature improvements and enhancements released by Microsoft.
Example 1: Only Accounts, Contacts and Leads can be included in a marketing list. If you plan to create marketing campaigns for companies or people in your custom solution, your best bet is to use one of these entities rather than creating a custom entity.
Example 2: If you need the standard CRM functionality of qualifying a lead and automatically creating account, contact and opportunity while onboarding a job or a project, you should consider using the Lead entity. Creating a custom entity is likely to require significant custom development and future maintenance to achieve the same results.
Example 3: Opportunities and Cases have a Customer field which can store both Accounts and Contacts. If you need this capability, you should consider using these entities in your solution. Otherwise, you will need to build this feature yourself.
Security
Are there any restrictions in terms of who can view and edit the data stored in this entity? For example, if in a solution for the insurance company, only the claims department employees can view and edit the claims data, it would make sense to create a custom entity to store claims rather than repurposing a standard entity like Case (incident). If you store claims in the Case entity and decide to use CRM for managing customer service cases either now or in the future, all users who have a “Read” permission to the Case entity can view Claims as well. You may be able to use Field Level Security to restrict certain fields from non-Claims department employees. However, this is likely to require more effort in terms of configuration, maintenance and administration.
Here’s another side note specific to custom “activities”. When you create a custom Activity entity, permissions defined for standard CRM Activities (such as email and task) would apply to this custom entity as well. If you have special security requirements for this entity, you may not want to define this as “activity”. You will have to weigh the pros and cons of each approach.
Contact entity to store “People” data
Typically you would want to use the Contact entity to store “people” or “persons” data. For example, if you are creating a solution for schools, you should first consider using the Contact entity to store profiles of parents, teachers and students. You can use Relationship Type or Contact Type field to identify the person’s role and either use separate forms or separate tabs on the same form that you can show or hide depending on the Contact Type. However, if the requirements and processes related to these Contact Types are fundamentally different, it may make sense to create separate entities to store respective profiles. One advantage of using one (Contact) entity to store all “people” is that search results within the Contacts view would include everyone matching the search criteria. Alternatively, you can train your users to use the global search feature that can include multiple entities including custom entities.
Another approach is to use the Contact entity as the base entity, create custom entities for specific Contact Types and create pseudo 1:1 relationship between the Contact entity and custom entity. Dynamics CRM does not natively support 1:1 relationship. However, you can simulate this by creating 1:N and N:1 relationships between Contact and custom entity. In our example, you will use the Contact entity to store common data such as name, address, email and phone number and create custom entities for Parent, Teacher and Student to store data specific to these Contact Types with 1:N and N:1 relationships to the Contact entity. Because CRM does not natively support 1:1 relationship, it will be your responsibility as a customizer to enforce data integrity. This approach will also enable you to configure permissions specific to Contact Type. For example, Student Administration users will be able to view and edit Student data but not Teacher data. I will write in more detail about how you can implement this solution in a later post.
Account entity to store “Company” data
On the same lines, you should consider using the Account entity to store company data including customers, vendors and business partners. This also enables you to use a lot of built-in functionality as well as standard relationships including contacts, opportunities and cases without customization. However, the same principles described earlier apply when making a decision.
Email Templates
You can create entity specific Email Templates only for certain standard entities including account, contact, lead, opportunity, quote, order, invoice, case, contract and service activity. You will have to use global templates for all other entities including custom entities you create. However, you would be able to use workflows and dialogs to create/send emails that include fields from custom entities. See the following post for details: Workaround for Email Template Limitations.
Repurposing Opportunity, Quote, Order and Case entities
If you are using Dynamics CRM to build a line of business solution that is unrelated to sales or service, it may make sense to repurpose Opportunity, Quote, Order and Case entities to take advantage of some built in features that come standard with these entities. This may save you time required for customizations and custom development. For example, you may use the Order entity to track Projects if you need to add line items to track time and material (products) used for the project. CRM also calculates the total of line items automatically.
Useful Common CRM features
There are many useful common features that you may want to leverage in your xRM solution. These features are available for both standard and custom entities. Therefore, they should not have any bearing on your decision to use one or the other. These features include:
- Business Process Flows
- Workflows and Dialogs
- Notes and Attachments
- Activities
- Connections
- Sending Email (including Direct Mail)
- Mail Merge
- Document Management
- Access Teams
- Queues
- Allow Quick Create
- Duplicate Detection
- Auditing
- CRM for Phones
- CRM for Tablets
- Reading pane in Dynamics CRM for Outlook
- Offline capability for Dynamics CRM for Outlook
- Timer control on entity form
I welcome your ideas and lessons you have learned from your experience on this topic from your projects.
No comments:
Post a Comment