Share via

Add / Entity scenario in CRM 2005

  • Article

I’m trying to get a feel for how ISVs and VARs might use custom tables and custom entities in MS-CRM. The canonical example around building 110 is that someone would add a BankAccount child entity to a customer (likely an Account). But that sure doesn’t seem like a valid solution.

I mocked up a student management system using some of the custom entities features that are in the V2 alpha when we where doing some of the original design work around relationships. For the most part things fit into place pretty well, but the solution seems a little forced (I have a background in survey and assessment systems so the concepts all work correctly, it’s just that I went out of my way to get all the relationship “rules” in the model).

Those "rules control how various relationships behave. The way we went about this was to devise a relationship type taxonomy and the rules that surround those types. The rules are pretty simple:

· Cascade – broadcast the action ‘down’ the link to any related entity. The receiving entity will perform the operation for any related instances. This is a "code" thing that the platform manages on the caller's behalf.

· Do not cascade – do not broadcast the operation at all. This action is useful for MERGE and security operations in many relationship models. It really means STOP the current traversal action for this relationship graph.

· Remove link – we’ve traditionally called this ‘cut link’. The action disconnects the relationship based on the relationship type (a 1:M relationship will set the relating attribute to NULL by sending a message to the ‘far’ entity, an M:M relationship will delete the specified rows from the association table but no broadcast will occur).

· Restrict operation – if an instance exists on the far end of a ‘restrict’ relationship then the whole operation is canceled. This is most useful for DELETE, but can apply to other operations.

Keep in mind that in many cases there’s an overlap between ‘remove link’ and ‘do not cascade’ and we’ve been overloading their meaning based on the model.

Note that operations only traverse in one direction. That is an operation will always start at the 1-side of a relationship and terminate at the m-side. Reverse traversals are undefined.

The following scenario shows one possible extension to MS-CRM. This extension models a student management subsystem. The system tracks Accounts and Contacts as customers and students. Those students can attend seminars to receive necessary training. Those training requirements are determined based on an assessment exam. Courses can have pre- and post-requisites. Exams can be created for pre- and post-assessment (to determine training needs and to assess learning after the course has been completed).

Many of the preceding models are represented in the scenario. There are several entity graph loops present. The loops are terminated by defining traversal rules on the following relationships: primary_contact, preferred_location, held_at, and held_for. The numbers throughout the model refer to the model numbers from an internal design document (they’re not too important).

Note that activities are represented by a fictitious entity called ‘Generic Activity’. Activity and Annotation relationships are not shown in the model but can be inferred from the associated model metadata. Assume for purposes of this example that Course, Exam, Seminar, Location, and Instructor have relationships to Annotation. Also assume that Attendance Record and Examination have associated scheduling activities.

Ideally “Add Entity” in V2 will have sufficient infrastructure to build a subsystem like the one below. A few modifications would make the model even more powerful such as defining Instructor and Location as Resources, and defining Examination, Seminar, and Attendance Record as Activity types.

Now, does this seem like the kind of solution that you’d want to build on top of MS-CRM, or is this way too deep? Is the core scenario like the one above, or more like “I need to add a simple 1:M relationship to hold some ‘extra’ stuff”. Just wondering.

 

Comments

  • Anonymous
    December 03, 2004
    Hi,

    We at Melbourne IT have been running MS CRM since V1.0 (and now V2.0) for over 12 months (we started about 16 months ago doing work). We have probably also invested $100K+ of our own time developing extensions for the platform.

    I am sure we will use this feature, but not sure exactly when and why. At the moment we have a supplimental table in SQL Server we use to hold about 40 colums of extra sales lead data that we didn't want to add to the core lead entity (we just reference a CRM id within our SQL table) - so maybe we could move that kind of data into CRM directly.

    I think by far our biggest problem is that of synching data between CRM and our home grown cutomer account system. Many internet based companies will already have a database holding customer login and profile data; and of course CRM requires that to be in its own Account database.

    It is such a pitty CRM didn't follow a model like ASP.NET Whidbey's provider model. It would just be amazing if you could have the option to use CRM to store Account data, but impelement your own provider to call out to an external account store.

    I realize it is probably too late to ever do this with CRM; but for the next CRM type of product MS build, please look at doing this as it would make the solution 100% better.

    Right now we are stuck with a situation where we have 1 million+ records in our core account database, but only create them in CRM when a case is created...and the data gets out of date really easy.
  • Anonymous
    December 05, 2004
    Spot on, this is exactly how I envisaged working with the custom entities in v2. Most examples of ISV add-ons I have seen for 1.x are industry vertical solutions with complex schemasrelationshipsview which sit outside in supplimental databases.

    However, I completely agree with David Taylor that an extensible provider model would be ideal.
  • Anonymous
    December 09, 2004
    From all the projects that I have done at my client site, custom entities would have cut my time(and my pay) :) into almost a half. I definitely think the M:M feature is a need-to-have. It would great if you could shed some light on how the custom entities are used with on the SDK.
  • Anonymous
    December 28, 2004
    We are thinking about Purchase Orders, vendors, and additional Enties like projects.

    Just a thought.