A Microsoft Dynamics CRM v4.0 build may consist of many different parts and each of these parts can potentially be their own partial build.

If we consider the variations of components within any given build, a new to xRM/CRM network administrator can quickly become overwhelmed and as such this article is to help break down these pieces into manageable tidbits. Helping the guru CRM/xRM infrastructure specialists to expand, simplify and offer choice to their wide variety of developers and users.

Tidbit One: The ORG or Database (set). In terms of Microsoft vocabulary the term ORG or ORGANZIATION is a key term to understand. This ORG is the container that holds not only future active data, but also key configuration settings and base data that might be needed with every rollout. The ORG contains the name of the organization which is using the software, the security and business unit hierarchy, the answers to the configuration questions, potentially custom entities and more. When you initially install Microsoft Dynamics CRM you install an organization. Another term for organization is “tenant” which applies when you might have multiple organizations sharing the same Microsoft Dynamics CRM code base. Many of the hosting companies have multi-tenant environments. You can create additional Orgs using the Microsoft Deployment Administration toolkit, but multiple tenants off the same code base is a little less common.

Tidbit Two:  The Customizations or customization.xml file. Microsoft Dynamics CRM gives a power user the option to create new entities (table sets), attributes, security roles, views, and forms. The Power user can also rename entities, attributes and views, as well as move attributes around on any given form. These customizations can be exported and are exported to a file called customizations.xml. This file can also be imported to a different Dynamics xRM/CRM Organization. Customizations are additive and as such when imported into any org they are layered on top of what exists. This is important to understand given that attributes will never be deleted during a customization import and as such if you need attributes deleted you need to take a different approach. Another option is to export partial customizations which might be a set of related entities. The trick to exporting and importing a partial set is to insure that you have bundled all the pieces. This includes not only the modified entities, but the entities that might have relationships to those.

Tidbit Three: Extending Microsoft Dynamics CRM with plug-ins. Plug-ins must be registered in the Windows Global Assembly Cache (GAC), put in a specific file on the right servers (developer debugging) or stored in the ORG (CRM database) . Once these are in the right place they also need to be provisioned or registered. Managing your plug-in builds correctly can definitely save you a lot of headaches. Using the ORG option is best when you have multiple tenants; although it can slow down the deploy process and limit the developers ability to quickly debug. Needless to say you will find many a developer choosing to stick with alternative approaches.

Tidbit Four: Custom workflows are very similar to plug-ins and yet they do not have to be deployed in the same style. The difference is the actual API call to register. “You can create custom workflow activities in Visual C# or Visual Basic .NET code by creating an assembly that contains a class derived from one of the Windows Workflow Foundation activities. This assembly is annotated with .NET attributes to provide the metadata that Microsoft Dynamics CRM uses at runtime to link your code to the workflow engine. After you have created an assembly that contains one or more workflow activities, you register this assembly with Microsoft Dynamics CRM. This process is the same as the process that is used to register a plug-in. The custom workflow activity can then be incorporated into a workflow by using the Workflow Designer found in the Microsoft Dynamics CRM Web application.” (Microsoft SDK, retrieved from http://msdn.microsoft.com/en-us/library/bb955349.aspx, retrieved April, 2011)

Tidbit five: ASP.Net applications are often associated with independent software vendors and as such purchased solution bundles are bundled and installed into the ISV Folder. They do not have to be third party applications. In fact many Dynamics xRM/CRM rollouts include custom ASP.NET web pages. If you plan to access your ASP.NET page from an IFrame within CRM there are a few more special considerations as opposed to your typical ASP.NET install. One key facthe same as the process that is used to register a plug-in. The custom workflow activity can then be incorporated into a workflow by using the Workflow Designer found in the Microsoft Dynamics CRM Web application.” (Microsoft SDK, retrieved from Tidbit Six:

Tidbit Seven:

 

(please feel free to add your own thoughts and build tidbits!)