Microsoft CRM 3.0

If you are maintaining this today

CRM 3.0 is long out of support. This site has not found a Microsoft lifecycle page for it, so the support dates shown for this version are provisional.

Everything on this page comes from Microsoft’s own install media: the server CD’s readme, the application Help, and the Help files for the workflow tools. The 3.0 SDK wasn’t on the disc. The readme says it was published on MSDN and as a separate download, in three parts:

• a Server Programming Guide, covering server-side code, integration and workflow assemblies;
• a Client Programming Guide, covering scripting and custom web pages;
• a Report Writers Guide.

This page covers what a customizer could see and do in 3.0. The programming side has two pages of its own, written from the 3.0 SDK: callouts and the 3.0 web services.

The platform underneath, from the readme:

• .NET Framework 1.1 Service Pack 1 is required for the server and for the Outlook client.
• SQL Server 2000 Service Pack 4 is required. 3.0 also works with SQL Server 2005, with known reporting issues.
• Upgrades come only from CRM 1.2. The CRM 2005 alpha and TAP builds couldn’t be upgraded.
• After customizing, restart the laptop client for Outlook.

What changed for customizers

Area	CRM 3.0	Modern equivalent
Packaging	One exported XML file of entity customizations, templates, Site Map, isv.config and relationship roles	Solutions
Form script	crmForm, with onLoad, onSave and onChange scripts pasted into the form editor	formContext and JavaScript web resources
Server logic	Callouts: .NET assemblies registered in callout.config.xml	Plug-ins and custom APIs
Workflow	Workflow Manager, a Windows tool on the server, with rules and sales processes	Power Automate, or classic workflows
Navigation and buttons	Site Map and isv.config XML	App designer and command bar customization

The customization model

Source: the CRM 3.0 application Help.

• Entity and attribute, not table and column. The Help explains the terms by noting that CRM is based on XML. Each entity maps to one database table, and an attribute appears on a form as a field.
• Custom entities come with defaults. Creating one gives you default attributes, forms, views and relationships to system entities.
• Some things can’t be customized:
  • You can’t add new activity entities. Microsoft’s suggestion was to adapt an existing one.
  • You can’t customize Status (statecode) on any entity. You can customize Status Reason (statuscode) values for each status.
  • The Convert Lead and Resolve Case dialogs can’t be customized, though they show statuscode.
• No calculated or auto-numbered attributes. Calculations were done with onChange scripts. For auto-numbering, the suggested approach was a separate database and stored procedure called from a business logic extension on PostCreate.
• Drop-down lists aren’t conditional. One list controlling another needed an onChange script. The downloadable SDK had a sample for it.
• Deleting attributes or entities is dangerous. The Help warns it can break custom code, ISV add-ons, workflow rules, scripts, callouts and reports.

Form scripting with crmForm

Source: the CRM 3.0 application Help, “Automate data entry using scripts”.

Scripts were typed into the form editor against three events:

• onLoad runs after the form loads. It can’t stop the form loading.
• onSave can cancel the save before it reaches the server, by setting event.returnValue = false. event.Mode tells Save apart from Save and Close.
• onChange fires when a field’s value changes and focus leaves it, for text, picklist, Boolean, float, integer, money, date/time and status fields. The field is validated again after the script runs.

Fields were reached through crmForm.all.<fieldname>.DataValue, and crmForm.FormType told you whether the form was creating (1) or updating (2) a record. How that model evolved into Xrm.Page and formContext is on crmForm to Xrm.Page to formContext.

Two traps that caught people:

• Main-form scripts also run on the Quick Create form. That form existed for account, contact, lead, opportunity and list. A script that refers to a field that isn’t on Quick Create throws an error. Microsoft’s advice: make the field Business Required, which puts it on Quick Create, or check that the field exists first, as in if (crmForm.all.telephone1 != null).

• Set dependencies for fields your scripts use. The form editor’s Dependencies tab stops those fields from being removed from the form. Code outside the form’s events has its own Non-Event Dependencies tab.

Relationships and mappings

Source: the CRM 3.0 application Help, “Relationship Form”.

Relationships were 1-to-many or many-to-1, implemented as a lookup attribute. You couldn’t delete the existing system relationships, and could edit only some of them. Behaviour was one of four types:

• Parental: actions on the parent cascade to the children.
• Referential: no cascading.
• Referential, Restrict Delete: no cascading, and a parent with children can’t be deleted.
• Configurable Cascading: a separate choice for assign, share, unshare, reparent, delete and merge.

Two rules limited cascading. A custom entity couldn’t be the primary entity in a cascading relationship with a system entity. And no entity could have two cascading parents.

Attribute mappings copied values from parent to child, but only when the child was created from the parent’s side tab. Records created any other way got nothing. Picklists mapped correctly only if their values had been added in the same order.

Exporting and importing customizations

Sources: the CRM 3.0 application Help and the server readme.

• Imports overwrite. Importing an entity overwrites that entity’s earlier customizations in the target, including its customized relationships. A custom entity can’t be imported over one with the same name.
• Navigation lives in the Site Map, not in the entity. Export and import the Site Map as well, or a new entity has nowhere to appear. A bad Site Map can make Settings unreachable. The Help gives a direct URL to the import page for that case.
• Publish a custom entity before exporting it, or some fields in the file may be empty.
• Large files fail with “Maximum request length exceeded”. Over about 7.5 MB, the ASP.NET request limit stops the import, sometimes reported as “Invalid customization file” instead. The fix was to raise maxRequestLength to the same value in two web.config files: the web application’s and the MSCRMServices one.
• Export before you customize. The readme recommends exporting as a quick backup of forms and views, and backing up Active Directory, the database, the metabase and the web server before bigger changes.

Workflow Manager

Source: Microsoft’s Help for the CRM 3.0 Workflow Manager and Workflow Monitor.

Workflow wasn’t in the web application. Workflow Manager was a Windows program installed on the CRM server. It was available to deployments with at least one Professional Edition licence. With it you built:

• Workflow rules and rule templates;
• Sales processes and their templates, based on the opportunity entity.

How rules behaved:

• Four trigger events: Create, Assign, Change Status and Manual. Sales processes could use only Create or Manual. Manual rules served as reusable subprocesses.
• Automatic rules run with the rule owner’s credentials. They apply only to the owner’s business unit and its children. A rule applied by hand runs with the credentials of the user who applied it.
• Loops are easy to create. A rule on Change Status that itself changes status can loop indefinitely. That drives SQL Server CPU up and floods the workflow system. Microsoft’s test was to watch Workflow Monitor for a fast-growing number of instances, and deactivate the rule causing it.
• Workflow Monitor listed running processes, which could be paused, resumed or cancelled, and kept a log.
• New in 3.0: rules on activities; rules on user-owned custom entities and across custom relationships; dynamic data fields in e-mails, activities and notes; and date and time functions for the Call Assembly action.

What happened to this model at upgrade is on the CRM 4.0 page: workflow rules became workflows owned by users, and several things did not carry over cleanly.

Upgrading from CRM 1.2

Source: the CRM 3.0 server readme.

• Upgraded custom roles don’t get the new privileges. This covers custom roles and modified system roles. Add Go Offline, Print, Bulk Import, Export to Excel, Quick Create, ISV Extensions, and all List and Campaign privileges by hand. Otherwise users lose features they had before.
• Blank Boolean and picklist values now show as blank. 1.2 displayed the system default when the database held null; 3.0 shows what’s actually stored. Setup offered a tool to fill the nulls with defaults.
• Marketing collateral picklist values were not upgraded.
• Don’t upgrade 1.2 integrated with Great Plains until the 3.0 integration product was available.

What this page still needs

Written from Microsoft’s CRM 3.0 install media, with the callout and web service pages written from the 3.0 SDK. Not covered, and not guessed at: a Microsoft source for the lifecycle dates.