Custom Entity versus Out of the Box Entity

MSCRM is great in that it gives administrators the ability to add custom entites to track anything and everything they want. MSCRM really gives a good solid backbone to not just a CRM system but an XRM system. But making too many entities can become VERY combersome for end users. At the same time an administrator has to decide what should be tracked and where the best place to track it really is. There certainly are plenty of times where an out of the box Order doesn't fit the needs of a client but they still need to user Orders. So, creating a custom object called Order isn't something unheard of. However, by choosing to go this route I lose a lot of out of the box functionality. That may be ok, and it may even be the reason the out of the box entity wasn't used. My hope is to help lay out some of the factors that play into choosing to use a custom entity or an out of the box entity.

1. Accounts and Contacts - Typically everyone uses these, but I've seen cases where one or the other didn't fit the companies business model. The more a system moves to XRM the less important a contact may become. But know this if you opt to use something in place of one of these two objects you lose sync with Outlook Contacts, which is a sync to your phone. Mailings and email blasts have been built around these objects where you can't do the same thing with a custom object. And if you are going to use Marketing Lists you had better use one of these because you can't have a Marketing List against a custom object.

2. Leads - The main thing lost here is the automatic push to Accounts, Contacts and Opportunities. This definitely can be reproduced and done whatever way necessary through custom code, but essentially you are having to redo something that you already had. Marketing Lists and email functionality also are special around this object in that custom objects don't get to do what you could with a Lead.

3. Opportunities - Opportunities have special statuses, and SDK triggers, around the winning or losing of a given Opportunity. You can mimic the same functionality, you just have to build in extra logic that MS already put in. If you are using Opportunity Products they automatically have math done for you that rolls up to the Opportunity record (total revenue based off of product pricing). Not to mention the pricing that's built into the Opportunity Products. One pro for the custom object is that there are fields on here that you can remove or tweak and you won't have any idea that you are effecting background code. Have you ever set the Topic to not be required? If you do then you'll definitely see Opportunities without a Topic appear, and when someone tries to set the Opportunity to Won or Lost, you won't be able to because background code needs something there. Sometimes the Opportunity is overkill but you just have to know what you're getting into.

4. Quotes, Orders, Invoices - I put all of these together because they are so close in everything they do. If you want to integrate to an accounting system any out of the box integration is going to integrate these objects with the accounting system. So, going custom means custom integration. The products under each object is exactly the same as Opportunities, so be aware of that. And the other thing lost is the out of the box flow from Opportunity to Quote, to Order, to Invoice.

5. Products - There is a very robust and complex Product Catalog that is built into CRM that handles pricing, UoM, Discounts, etc. If it's overkill for your company then custom is the way to go. But you lose a lot of pricing capabilities that have to be redone if you don't use the Product.

6. Cases - You lose the use of Queues if you replace Cases. There is also the code that closes the Case and makes the Close Case activity, but there are other ways to accomplish the same thing.

7. Contracts - If you need detailed product itemized Contracts you're missing out. Contracts do a lot at a very granular level to help in managing whether things are under contract or not. However, if you don't care about having a Contract that could have 8 items that could all have their warranty/contract end on a different date, then I'd almost suggest using a custom object, it's just cleaner. The other thing you lose with not using Contracts is the automatic daily check to see if something is expired. CRM automatically moves Contract statuses according to dates, that would have to be rebuilt if a custom object were used.

8. Custom Objects - The pro about custom objects is that they are vanilla for you and ready for you to do whatever you want to them. The downside is that you have to manually build out each process, flow, or custom action. But that can be seen as an upside just as well. Custom Objects don't get the same kind of email and marketing capabilities but out side of these things, Custom Objects work really well and can easily replace out of the box objects if necessary.

I think that's good for now. Let me know your thoughts and if there's any object I missed that you're debating between either using out of the box or custom, let me know and I'll add it to the list.

David Fronk
Dynamic Methods Inc.