Answered by:
Integration advice

Question
-
I’m looking for a bit of CRM integration guidance.
We have a successful .NET and SQL Server based XRM type product in the market that provides a platform for social agencies to do case management. The system has the following core components:
- client management module
- integrated communications for SMS/Chat/Email/Phone/Etc (all linked to the appropriate client)
- advanced forms engine supporting complex decision and validation logic
- integration API for 3rd party CMS and bespoke web applications to provide client self-registration, communication and engage in other self-help programmes
- reporting engine based Excel
- custom modules that provide specific business logic around self-help programmes
- Windows Forms based UI connecting via WCF to App server for managing all of the above
There are opportunities for us to take this to the next level if we could provide more substantial CRM capabilities by integrating our product with Dynamics CRM to substantially accelerate and enhance the CRM part of our offering around aspects like custom dashboard and reporting, capacity and forecast planning, market segmentation, integrated VOIP, donations, online booking, event management, configurable views, security, training, etc.
Some of the thoughts/questions we have:
- replace the client management component in our product with Dynamics CRM
- integrate our communications modules with Dynamics CRM (could these comms still live in our database?)
- Dynamics CRM already has built-in email – how would that work with our email channel?
- replace our UI with the web based Dynamics CRM UI
- adopt the Dynamics CRM forms engine or embed our forms engine (currently XAML based)?
- how do we handle the integration API for 3rd party CMS systems – do we just wrap that around the Dynamics CRM API?
I realise that this is a fairly large topic and I may not have provided enough specifics above, but if anyone has any advice to offer I would really appreciate that.
Thanks in advance
Xander
Wednesday, October 10, 2012 8:05 PM
Answers
-
Hi Xander,
This is a rather complex area yes - and obviously depends heavily on the details.
…that said…I’ll have a go:
Replace Client Management Component with Dynamics CRM
Microsoft Dynamics CRM is a fantastically flexible and extensible platform that allows you to quickly and easily extend to include your own functionality.
Provided you are ok with going 100% with the Microsoft Dynamics framework and to then extend that - this would be a very sound option. The rich user interface components (like the beautiful user interface, interactive dashboards, social features, user configurable views, integration with Excel, workflows and dialogs, to name but a few) are always available even for custom entities.
The key point to understand is that in order to benefit from this framework, the rules are considerably different to bespoke development. You must use Dynamics CRM User Interface, Security and database storage strategy, but good news is that there are many extension points to add your custom functionality, including:
- Adding new entities, fields and relationships between entities (1 to many or many to many). The big advantage of this is that the forms designer can be used to quickly build your user interface with no coding involved.
- Custom Client-Side form logic - written as JavaScript that interacts with the rich CRM Client SDK. Ribbon Buttons can be configured to call custom JavaScript or open new dialogs.
- Client-Side ‘web-resources’ that can be shown as dialog boxes or embedded in CRM Forms. These can be Silverlight or HTML AJAX style extensions.
- Server-Side plugin framework that allows custom logic to be placed in the CRUD pipeline. These are .net plugins that can be added to steps like Pre-Create, Post-Create, Pre-Update, Post-Update etc. These plugins can be synchronous or asynchronous.
- Call outs to externally hosted Services/User Interfaces that then make calls back to Dynamics CRM using the SDK Web services. There are many example of ISV’s doing this in the Dynamics CRM Marketplace: http://dynamics.pinpoint.microsoft.com/en-US/home
- Custom Reports, Dashboards, Views etc.
- Custom Workflows and Dialogs
More can be read at http://msdn.microsoft.com/en-us/library/gg309637.aspx
It is worth noting that the Dynamics CRM Database is effectively private. You must rely on CRMs own database object-mapping strategy where it will create new tables/fields/views when you configure them through its administration interface. It is not supported to add any other database objects to the Dynamics CRM database other than indexes for performance purposes. You can query the data using Views that Dynamics CRM creates for you – but any programmatically update/insert/delete operations must go through the SDK Web services. You can of course create a separate database and query back into the MSCRM database where needed.
Integrate our communications modules with Dynamics CRM
Using the extension points above – you can integrate to other systems by calling out from Server-Side plugin events. The communications would be a separate sub-system that could be invoked using webservices – meaning you have a good separation of concerns between your CRM and other functionality. A large portion of your custom business logic of course may sit 100% within Dynamics CRM.
Dynamics CRM already has built-in email – how would that work with our email channel
Dynamics CRM has two modes of Sending/Receiving Emails:
- Outlook – the outlook client for Dynamics CRM downloads and sends emails from CRM as though they were being sent straight from Outlook. Emails that are received into Outlook can be tracked in CRM- where a copy is created in CRM so that other CRM functionality can be applied (Such as converting to leads etc.). Outbound emails are then sent in the normal way, but make be tracked by the user - where a copy is created in CRM and associated with contacts/accounts/leads and set regarding any activity enabled email. In addition to emails, Outlook also syncs Tasks, Letters, Faxes and Contacts as well as other custom activities you create. You can also go offline, where a local SQL Express database is used as an offline copy of entities of your choice.
- Email Router – A Service that is installed on a Server that polls Exchange Server/POP3 for inbound emails and uses SMTP to send emails.
Server side plugins can be added to make changes to inbound/outbound emails when they are sent/received – but there are no built-in extension points for custom email channels. The usual route would be to create a custom email entity that is separate to the outlook style emails – and then sent via your own extension component. There are good examples of this with Online Email Marketing ISV add ons such as Click Dimensions (http://www.clickdimensions.com/).
Replace our UI with the web based Dynamics CRM UI
As above – if you are going to adopt Dynamics CRM, you must adopt its user interface as the primary top level entry point for users. You can then add your own custom components into the navigation structure and into Dynamics CRM Forms. Projects that try and fundamentally change the way that the Dynamics CRM UI works (rather than extend it using the supported extension points) always encounter significant challenges and increased costs.
It is worth noting that currently Dynamics CRM does not support being be placed inside an IFRAME of another application.
Adopt Dynamics CRM Engine or embed your own?
As above – the only viable route here would be to use the Dynamics CRM forms engine and extend where you need to. You can embed Silverlight – so if you have XAML based UI components, they might be re-usable to a certain extent.
One approach that has been taken by some of my clients is to effectively hide some of the fields on the Dynamics CRM Forms and replace them with a custom UI. The custom UI component sits inside the form – and when the fields are updated, the values are written to the hidden CRM fields. This way, when the form is saved, the values are treated as though the standard form was being saved. This is a viable option – but you do increase the total cost of ownership and lose the benefits of the XRM style configuration of fields and forms.
A consideration may be around cross-browser support. Dynamics CRM will be offering cross browser support later this yet – but currently only Internet Explorer is supported.
How do we handle the integration API for 3rd party CMS systems
If you want to effectively ‘package’ your solution to 3<sup>rd</sup> parties so that you have complete control over the interface contract – I would recommend that you ‘wrap’ up the Dynamics CRM webservices in your own webservices. This way, you can expose a composite of the Dynamics CRM CRUD type operations with your other sub-systems.
Conclusion
Dynamics CRM is an incredibly extensible product and its XRM framework allows you create complex applications with a much lower total cost of ownership compared to Bespoke solutions. You must trade these benefits off against the corresponding constraints – in that you must play by its rules as far as the User Interface, Security and Data Modelling strategy.
Although an On-Premises/Hosted deployment model may be your best option at the moment (where Dynamics CRM is installed on Servers owned and managed by you or your clients) - an opportunity for you might be to move to a ‘cloud based’ service model where you roll out your custom components to Azure and then use Dynamics CRM Online for the Client Management and User Interface extensions. Packaging solutions in this way would also allow you to sell to customers who already had a Dynamics CRM and easily provide a ‘trial’ using the Dynamics CRM Online 30 day trial mechanism.
If you would like to talk more about this, please don’t hesitate to contact me on the details below. hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by Scott Durow (MVP)MVP, Editor Thursday, October 11, 2012 10:17 AM
- Marked as answer by novascape Friday, October 12, 2012 1:09 AM
Thursday, October 11, 2012 10:11 AMAnswerer -
Hi Xander,
1) It depends - components that fit within the webresource/plugin model can sit within Dynamics CRM and do not need to be hosted by Azure. Reasons why you might need Azure (or other any other hosting for that matter) are:
- Custom Web Services
- Custom Database
- User Interface that requires ASP.NET server post backs
The Azure hosting ESB is designed to work with Dynamics CRM, so you can register plugin events that call out to an Azure ESB listener.
2) IP is not restricted by developing custom components in Dynamics CRM - you may retain the IP and still deploy to the Dynamics CRM online platform.
3) The normal is to have users license the base Dynamics CRM Online instance - and then charge an additional license fee separately for your additional component. You could also package up the two into a single license and re-sell the Dynamics CRM online licenses through a Microsoft Partner agreement - this is less common.
hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by Scott Durow (MVP)MVP, Editor Friday, October 12, 2012 7:36 PM
- Marked as answer by novascape Wednesday, October 17, 2012 8:43 PM
Friday, October 12, 2012 7:05 AMAnswerer -
Hi Xander,
1) Yes - each organisation has a separate MSCRM Database that does not share any data with other organisations - so it sounds like a good fit.
2) The 'Company' entity is actually the 'Account' entity - you might choose to create a custom entity here depending on if you need the Account entity for anything else. If a 'Service' is like a company, and can sit along side other company records you might have, then perhaps this would be ok.
3) Sounds right - contacts are general purpose and used to represent people. Contacts can be synced to Outlook.
4) Every Clinician would be a user of CRM then and would require a CAL (Client Access License) unless they are disabled
5) Custom Activity for Chats & SMS - but standard Appointment/Email/PhoneCall activities. A custom entity could be used for the chat session messages. You could then 'set regarding' the Case (which is a standard entity in CRM as well)
6) If you were to use the entity form designer, you would need a custom entity for each type of custom form. It really depends on what data you need to store. I suggest you model the data first, then look at the forms. There are dialogs in CRM2011 which allow you to construct question/answer multi-step forms which then can add data to one or more record. It sounds as though Dialogs would be a good fit for your Custom Forms.
We are really getting into requirements/solution space here - so it obviously all the caveats apply to the above!
hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by John Grace - North52 Wednesday, October 17, 2012 8:24 AM
- Marked as answer by novascape Wednesday, October 17, 2012 8:34 AM
Wednesday, October 17, 2012 7:41 AMAnswerer
All replies
-
Hi Xander,
This is a rather complex area yes - and obviously depends heavily on the details.
…that said…I’ll have a go:
Replace Client Management Component with Dynamics CRM
Microsoft Dynamics CRM is a fantastically flexible and extensible platform that allows you to quickly and easily extend to include your own functionality.
Provided you are ok with going 100% with the Microsoft Dynamics framework and to then extend that - this would be a very sound option. The rich user interface components (like the beautiful user interface, interactive dashboards, social features, user configurable views, integration with Excel, workflows and dialogs, to name but a few) are always available even for custom entities.
The key point to understand is that in order to benefit from this framework, the rules are considerably different to bespoke development. You must use Dynamics CRM User Interface, Security and database storage strategy, but good news is that there are many extension points to add your custom functionality, including:
- Adding new entities, fields and relationships between entities (1 to many or many to many). The big advantage of this is that the forms designer can be used to quickly build your user interface with no coding involved.
- Custom Client-Side form logic - written as JavaScript that interacts with the rich CRM Client SDK. Ribbon Buttons can be configured to call custom JavaScript or open new dialogs.
- Client-Side ‘web-resources’ that can be shown as dialog boxes or embedded in CRM Forms. These can be Silverlight or HTML AJAX style extensions.
- Server-Side plugin framework that allows custom logic to be placed in the CRUD pipeline. These are .net plugins that can be added to steps like Pre-Create, Post-Create, Pre-Update, Post-Update etc. These plugins can be synchronous or asynchronous.
- Call outs to externally hosted Services/User Interfaces that then make calls back to Dynamics CRM using the SDK Web services. There are many example of ISV’s doing this in the Dynamics CRM Marketplace: http://dynamics.pinpoint.microsoft.com/en-US/home
- Custom Reports, Dashboards, Views etc.
- Custom Workflows and Dialogs
More can be read at http://msdn.microsoft.com/en-us/library/gg309637.aspx
It is worth noting that the Dynamics CRM Database is effectively private. You must rely on CRMs own database object-mapping strategy where it will create new tables/fields/views when you configure them through its administration interface. It is not supported to add any other database objects to the Dynamics CRM database other than indexes for performance purposes. You can query the data using Views that Dynamics CRM creates for you – but any programmatically update/insert/delete operations must go through the SDK Web services. You can of course create a separate database and query back into the MSCRM database where needed.
Integrate our communications modules with Dynamics CRM
Using the extension points above – you can integrate to other systems by calling out from Server-Side plugin events. The communications would be a separate sub-system that could be invoked using webservices – meaning you have a good separation of concerns between your CRM and other functionality. A large portion of your custom business logic of course may sit 100% within Dynamics CRM.
Dynamics CRM already has built-in email – how would that work with our email channel
Dynamics CRM has two modes of Sending/Receiving Emails:
- Outlook – the outlook client for Dynamics CRM downloads and sends emails from CRM as though they were being sent straight from Outlook. Emails that are received into Outlook can be tracked in CRM- where a copy is created in CRM so that other CRM functionality can be applied (Such as converting to leads etc.). Outbound emails are then sent in the normal way, but make be tracked by the user - where a copy is created in CRM and associated with contacts/accounts/leads and set regarding any activity enabled email. In addition to emails, Outlook also syncs Tasks, Letters, Faxes and Contacts as well as other custom activities you create. You can also go offline, where a local SQL Express database is used as an offline copy of entities of your choice.
- Email Router – A Service that is installed on a Server that polls Exchange Server/POP3 for inbound emails and uses SMTP to send emails.
Server side plugins can be added to make changes to inbound/outbound emails when they are sent/received – but there are no built-in extension points for custom email channels. The usual route would be to create a custom email entity that is separate to the outlook style emails – and then sent via your own extension component. There are good examples of this with Online Email Marketing ISV add ons such as Click Dimensions (http://www.clickdimensions.com/).
Replace our UI with the web based Dynamics CRM UI
As above – if you are going to adopt Dynamics CRM, you must adopt its user interface as the primary top level entry point for users. You can then add your own custom components into the navigation structure and into Dynamics CRM Forms. Projects that try and fundamentally change the way that the Dynamics CRM UI works (rather than extend it using the supported extension points) always encounter significant challenges and increased costs.
It is worth noting that currently Dynamics CRM does not support being be placed inside an IFRAME of another application.
Adopt Dynamics CRM Engine or embed your own?
As above – the only viable route here would be to use the Dynamics CRM forms engine and extend where you need to. You can embed Silverlight – so if you have XAML based UI components, they might be re-usable to a certain extent.
One approach that has been taken by some of my clients is to effectively hide some of the fields on the Dynamics CRM Forms and replace them with a custom UI. The custom UI component sits inside the form – and when the fields are updated, the values are written to the hidden CRM fields. This way, when the form is saved, the values are treated as though the standard form was being saved. This is a viable option – but you do increase the total cost of ownership and lose the benefits of the XRM style configuration of fields and forms.
A consideration may be around cross-browser support. Dynamics CRM will be offering cross browser support later this yet – but currently only Internet Explorer is supported.
How do we handle the integration API for 3rd party CMS systems
If you want to effectively ‘package’ your solution to 3<sup>rd</sup> parties so that you have complete control over the interface contract – I would recommend that you ‘wrap’ up the Dynamics CRM webservices in your own webservices. This way, you can expose a composite of the Dynamics CRM CRUD type operations with your other sub-systems.
Conclusion
Dynamics CRM is an incredibly extensible product and its XRM framework allows you create complex applications with a much lower total cost of ownership compared to Bespoke solutions. You must trade these benefits off against the corresponding constraints – in that you must play by its rules as far as the User Interface, Security and Data Modelling strategy.
Although an On-Premises/Hosted deployment model may be your best option at the moment (where Dynamics CRM is installed on Servers owned and managed by you or your clients) - an opportunity for you might be to move to a ‘cloud based’ service model where you roll out your custom components to Azure and then use Dynamics CRM Online for the Client Management and User Interface extensions. Packaging solutions in this way would also allow you to sell to customers who already had a Dynamics CRM and easily provide a ‘trial’ using the Dynamics CRM Online 30 day trial mechanism.
If you would like to talk more about this, please don’t hesitate to contact me on the details below. hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by Scott Durow (MVP)MVP, Editor Thursday, October 11, 2012 10:17 AM
- Marked as answer by novascape Friday, October 12, 2012 1:09 AM
Thursday, October 11, 2012 10:11 AMAnswerer -
Hi Scott,
Thank you so much for the detailed and comprehensive reply, it is very much appreciated. I'm also busy reading the David Yack CRM as a Rapid Development Platform book and I'm finding it very informative, especially from a development perspective. I've contacted MS and they have set me up with a local MS CRM consultant that I will be meeting with at the end of next week.
A few more questions if I may:
1/ Am I correct in assuming that custom components must be installed into a separate Azure server environment, rather than being installed as part of the cloud based Dynamics CRM instance? Although it sounds a little bit cumbersome, I assume that it is a model that works well, given that you suggested it?
2/ How does IP work around developing custom components and custom configuration and set-up of entities, forms, views, reports, etc? Is it common practise to set those up and claim IP over those and license that part to CRM users?
3/ What sort of business model do software companies typically use that make use of Dynamics CRM as the platform? When using CRM in the cloud their would be a monthly license fee per user and when using a self-hosted instance I assume there is a once-off cost per user only. Do they just add a mark-up licensing & support cost over and above the CRM licensing costs for their custom development? I'm basically weighing up potential business models that would work to make this viable, given that a portion of what the end users ultimately pay, will now go towards the cost of CRM, which is fine as I save that development cost of course. Any examples of how software companies do this?
Thanks in advance
Xander
- Edited by novascape Friday, October 12, 2012 1:31 AM typos
Friday, October 12, 2012 1:29 AM -
Hi Xander,
1) It depends - components that fit within the webresource/plugin model can sit within Dynamics CRM and do not need to be hosted by Azure. Reasons why you might need Azure (or other any other hosting for that matter) are:
- Custom Web Services
- Custom Database
- User Interface that requires ASP.NET server post backs
The Azure hosting ESB is designed to work with Dynamics CRM, so you can register plugin events that call out to an Azure ESB listener.
2) IP is not restricted by developing custom components in Dynamics CRM - you may retain the IP and still deploy to the Dynamics CRM online platform.
3) The normal is to have users license the base Dynamics CRM Online instance - and then charge an additional license fee separately for your additional component. You could also package up the two into a single license and re-sell the Dynamics CRM online licenses through a Microsoft Partner agreement - this is less common.
hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by Scott Durow (MVP)MVP, Editor Friday, October 12, 2012 7:36 PM
- Marked as answer by novascape Wednesday, October 17, 2012 8:43 PM
Friday, October 12, 2012 7:05 AMAnswerer -
Thanks again Scott for your excellent answers. The next topic in my integration investigation is to see how I can model my existing application in CRM.
The existing application has the following:
1/ System installation (one system would be installed at one Social Agency)
2/ Service ( there may be multiple of these in one Social Agency, e.g. Gambling Help, Depression, Addiction, etc)
3/ Service User (each Service has a number of Service Users, currently Service Users are not shared across Services, but this may change in future)
4/ Clinicians (these are the operators/clinicians that do cases management, they belong to the Social Agency and have access to one or more Services)
5/ Engagement Sessions (these encapsulate a number of Email, Chats, SMS messages, Phone calls, Face to Face meetings, etc between a Clinician and Service User. One Chat Engagement Session would have numerous incoming and outgoing Chat messages for example)
6/ Custom Forms (attached to Service User and may or may not be part of Engagement Session)
Looking at CRM it looks like the best way to model the above would be:
1/ System -> Organisation
2/ Service -> Company
3/ Service User -> Contact
4/ Clinician -> User (should have access to Contacts in other Companies that the user has access to)
5/ Engagement Sessions -> not sure but maybe Activity?
6/ Custom Forms -> Custom Entity (with Custom Form) linked to either Contact or Activity (which in turn will be linked to Contact)
Any advice or hints on the above would be very welcome.
Thanks in advance
Xander
Wednesday, October 17, 2012 12:31 AM -
Hi Xander,
1) Yes - each organisation has a separate MSCRM Database that does not share any data with other organisations - so it sounds like a good fit.
2) The 'Company' entity is actually the 'Account' entity - you might choose to create a custom entity here depending on if you need the Account entity for anything else. If a 'Service' is like a company, and can sit along side other company records you might have, then perhaps this would be ok.
3) Sounds right - contacts are general purpose and used to represent people. Contacts can be synced to Outlook.
4) Every Clinician would be a user of CRM then and would require a CAL (Client Access License) unless they are disabled
5) Custom Activity for Chats & SMS - but standard Appointment/Email/PhoneCall activities. A custom entity could be used for the chat session messages. You could then 'set regarding' the Case (which is a standard entity in CRM as well)
6) If you were to use the entity form designer, you would need a custom entity for each type of custom form. It really depends on what data you need to store. I suggest you model the data first, then look at the forms. There are dialogs in CRM2011 which allow you to construct question/answer multi-step forms which then can add data to one or more record. It sounds as though Dialogs would be a good fit for your Custom Forms.
We are really getting into requirements/solution space here - so it obviously all the caveats apply to the above!
hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"- Proposed as answer by John Grace - North52 Wednesday, October 17, 2012 8:24 AM
- Marked as answer by novascape Wednesday, October 17, 2012 8:34 AM
Wednesday, October 17, 2012 7:41 AMAnswerer -
4) Every Clinician would be a user of CRM then and would require a CAL (Client Access License) unless they are disabled
Hi Scott,
Thanks again, does CRM support concurrent licensing in a) on-premise deployment and b) cloud hosting? This is important as social agencies often work with a bunch of volunteers that come and go and serve as clinicians, so there might be hundreds of clinicians set up in the database but only 30 might be concurrently active at any one time.
edit: Having to disable clinicians all the time does not sound practical as it would have to be done on a daily basis and be an admin nightmare.
ps. sorry about all the questions, but I think this entire post will be useful to a lot of ISVs in my position.
Thanks
Xander
- Edited by novascape Wednesday, October 17, 2012 8:43 AM
Wednesday, October 17, 2012 8:41 AM -
Hi Xander,
Dynamics Crm Online (Microsoft Cloud) licensing works slightly different to On-Prem or Partner Hosted.
With CRM Online, each user pays a monthly subscription. With On-Prem/Hosted you buy either a CAL for every user, or you buy a device license where you might have shift workers that all share the same PC in a Call Centre for instance. A device license is the closest there is to concurrent user licensing.
Hope you are getting there with your planning!
hth,
Scott
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"Wednesday, October 17, 2012 6:40 PMAnswerer -
Hi Scott,
Due to a number of external factors the above was put on hold but I now need to revisit this option again and have a simple question (I hope):
Is there any reason why I cannot model ALL my current application entities (i.e. Service/Service User/Session/Messages(chat/sms)) as custom entities in CRM? This would be as opposed to customizing some of the built-in entities like the Contact entity to become the Service User entity and only adding custom entities where required?
In other words, build my entire CRM solution based on custom entities and hide everything else that is not required?
That way I can easily model my existing system exactly the way it currently works and leave the built-in CRM entities (like Contact) to be used for other purposes like fund raising and whatever else is required within the organisation.
EDIT: I do now realize that there are some restrictions with only using custom entities, like not being able to easily use email templates.
Thanks in advance
Xander
- Edited by novascape Monday, April 15, 2013 9:46 AM
Monday, April 15, 2013 7:54 AM -
Hi Xander,
This certainly is an option apart from the functionality you loose from not using the system entities. Outlook sync is often the biggest one.
I often wish that the whole of the CRM was effectively custom entities - with the system functionality being delivered through use of a standard Xrm platform.
hth
Scott Durow
Read my blog: www.develop1.net/publicFollow Me on Twitter
If this post answers your question, please click "Mark As Answer" on the post and "Mark as Helpful"Monday, April 15, 2013 1:33 PMAnswerer