To CRM or not to CRM (MS)?

Answer 1

I'd use CRM to store the data. You can stick the new fields in a separate pane in the UI so that it won't clutter. You can even add some Javascript to the UI to hide pane/fields from users who are not part of the group that requires them. I know this sounds a little hacke-ty, but it's a lot less work than coming up with an entirely different app and users will get a consistent experience. Having the data in one place is also a boon for reporting and such.

I can't say for sure, but I don't think adding a few columns to an entity (which already has a bazzilion columns) will deteriorate performance much further. I'd go over the installation and check for the usual performance pitfalls.

Answer 2

I agree, you're better off going with 100% CRM.

If (and I stress if) you find the performance impact is significant, consider using a related entity to hold the additional fields.

CRM doesn't provide a 1-to-1 relationship type so you'll have to manage that yourself. Make your company entity the N side of the relationship so the related entity appears as a lookup.

Alternately, if the related entity lookup is too abstract for your users, add a tab with an iFrame to the company entity form. Use javascript to show/hide the tab and also to set the src of the iFrame to the url of the related entity.

Answer 3

I know that this doesn't fit your situation as you are deep in MS CRM, but there is a good article by Neal Ford that was recently posted to IBM Developer Works (http://www.ibm.com/developerworks/java/library/j-eaed10/) that discusses COTS vs home grown software. Here's a snippet.

One of the common questions that arise in big companies is the decision whether to build or buy: for the current requirements, should we buy COTS (Commercial Off-the-Shelf Software) or build it ourselves? The motivation for this decision is understandable — if the company can find some already written software that does exactly what's needed, it saves time and money. Unfortunately, lots of software vendors understand this desire and write packaged software that can be customized if it doesn't do exactly what the client needs. They are motivated to build the most generic software they can because it will potentially fit into more ecosystems. But the more general it is, the more customization is required. That's when an army of consultants shows up, sometimes taking years to get all the custom coding done.

Answer 4

Creating ASP.NET applications to create a complex UI in an iframe is a simple solution that I use frequently for MS CRM 4.0 applications.

Keeping all of the data in CRM makes a lot of sense, but make the UI however you want it.

The iframe calls your ASP.NET application with a Querystring containing the entity's Guid so that you can use webservices to pull any related information.

You can both modify the fields showing on the form with JavaScript, directly update the database or both for consistancy. Frequently it is easier just to hide the fields being updated in the ASP.NET app so there is no confusion.

An example from a long time ago was a loan morgage calculator that I built for an iframe of an opportunity that a Sale Rep would have up. It would find all of the customer's related loan balances and calculate different options that the sale rep could then turn into a quote. Click a few check boxes, and press a button and they were done without having to rekey a lot of information. Data was written to a number of CRM entities, emails were generated and the autodialer list would be modified not to call that customer again.

Learning to use MS CRM as a big development toolbox is the first step to being able to do some serious business process automation.

If you have any questions let me know.

Mark http://crmscape.blogspot.com