Why retrofit system entities?

One of my biggest pet peeves working with CRM is and has been since version 1.2 (since I myself didn't know any better in version 1.0) the failed logic in retrofitting or repurposing system entities.  

Simply because CRM is flexible and customizable doesn't mean an architect is allowed to be lazy!  Just because it has a codeless customization interface doesn't mean there isn't code behind the WYSIWYG interface.  The negative repercussions associated with repurposing system entities can be enormous, and the effort it can potentially take to retrofit them back to planned use can also be fairly large.

For this reason it is imperative that successful deployments follow the Surestep flow to first gather requirements in the FRD, then put together the Fit/Gap analysis, then compile the Functional Design Document, and LASTLY jump into the Technical Design Document.  This is one of the ways partners and clients can benefit from the Surestep methodology and mentality.  If your team or partner has the right talent in place, they'll ponder the right questions before repurposing system entities and will be able to architect your solution properly the first time based on the core principles of functionality that ship out of the box with Dynamics CRM!

Just imagine if you repurpose an entity like the Account entity.  A good design team would look to all the system functions that would be altered, deprecated, or very simply broken by doing such a thing.

1. Leads converting to Accounts might break,
2. Opportunities and pipeline reporting would break,
3. Price Levels and all QOI pricing would break,
4. Contract invoicing would break
5. Relationship Roles would break
6. ...and so on...

Wouldn't it be better to consider the data normalization factor and use custom attributes and/or entities to fit the requesters' needs? Imagine if you were following someone else's deployment and got tasked with "fixing" a scenario like the example given...oy vey...no thanks!

The next time someone tells you to repurpose a system entity, tell them "NO" until you get a good chance to fully analyze the situation and future scenarios.

Cheers!