A simple note on Microsoft CRM or Dynamics CRM.

Date : 26 October, 2018.
Version: 1.2
By: Albert van der Sel.
Status: Ready. However, subjects might be added occasionally.
Remark: Please refresh the page to see any updates.

This is a simple, technical oriented note, on Microsoft CRM.
CRM is short for "Customer Relations Management".

It's business software which targets mostly the maintenance of Sales, Products, Customers, Relations, and Marketing.
Apart from this, often some nifty services are implemented too, like Workflows, Agenda/Mail/Office365 integrations etc..

There exists many parties which offer CRM software, and Microsoft (MS) is one of them.
However, MS CRM is indeed quite popular, and it's one of the major players in this arena.

It's certainly a fact that MS CRM can be highly customized. You can, for example, create Forms
with Javascript (JScript) "event handlers", or create customized ASP.NET (crm integrated) websites,
and create Plugins programmed in C# or VB.NET.

Some even call it an "XRM" platform, meaning an "eXtentable Relation Management" environment, where users
are (sort of) encouraged to extend it, using .NET tools (like creating PlugIns, ASP.NET etc..).

Or, you extent it with less programming effort, by creating/extending Forms, possibly with JScript (MS javascript).
The forms you may define or extend, provide webbased "windows" (or views) on the database tables with data.
Custom JScript code is often implemented, which define the actions to be performed with "OnLoad", "OnChange" (etc..) events.

In practice, if you go to a company where CRM is implemented, you can bet that a lot of scripts, custom forms,
and sometimes C#, VB.NET plugins are around.

I did a project of upgrading CRM 2013 (on premises) to 2016 (on premises).
Once that was all settled, the step to Microsoft Dynamics 365 online (the cloud) was taken.

Here, I really learned a lot "the hard way". Some conversions were quite difficult, and it took a lot of effort.
But I must say that this particular system, was indeed highly customized.
Usually, there will be much and much less effort needed, when upgrading CRM. Indeed, one determining factor here is,
how much customized code is involved, and how that was programmed.

There are two major streams on where CRM runs:

(1). You can run CRM "on premises", where all components reside at your shop (or datacenter).
Thus here, all hardware, Servers, and software like CRM, SQL Server etc.. are your responsibility.

(2). Or, you can run it "online", that is in the Microsoft cloud, where all resources (hardware),
and tasks like backups, updates etc.. (system management tasks), are taken care of, for you.

But going from an existing customized "on premises" system, to a system in "the cloud", is a daunting task, and must
never be underestimated.

-It's probably fair to say that, up to now, a highly customized system, works better in an on premises setup.
-Also, it's probably fair to say that, if an Organization is about to start using CRM, then online is probably the better choice.

About this note:
If you are very experienced in MS CRM, this note is of no relevance to you.
However, if you are relatively "new", this note might give some nice pointers (I hope).


1. Major CRM Infra components and Architecture.
  1.1 Birdseye view of the infrastructure components.
  1.2 Quick overview versions and product lines.
  1.3 Birdseye view Architecture MS CRM.

2. How CRM "works".
  2.1 Introduction on how MS CRM works.
  2.2 A few words on Storage of objects in SQL Server.
  2.3 A few words on the middle tier: CRM Application Server.

3. Overview developing in CRM.
  3.1 Test environment and Sandboxes.
  3.2 Managed vs Unmanaged code, or, Managed vs Unmanaged solutions.
  3.3 Overview Customizations/Developing.
  3.4 Developing PlugIn's.
  3.5 Developing with JScript (MS Javascript) for CRM.

4. Some other stuff in CRM.
  4.1 Integrating CRM with email.
  4.2 CRM and the Report Server SSRS.


1. Major CRM Infra components and Architecture.

1.1 Birdseye view of the infrastructure components.

The following is certainly true for a "on premises" implementation. For a cloud based system, similar items exists as well,
but those are governed by the Provider.

  1. CRM App Server: First, we have the CRM services, implemented as services on a Windows Server system.
    It provides all business logic, and it interfaces to a Backend Database, and it also interfaces to a Website (web services) in IIS.

  2. CRM Database Server: Here we have a SQL Server Instance, using two main databases. One database contains
    all data (like customers, products) etc.., but also object definitions like JScript code and other similar resources (called "webresources").
    Another database contains configuration data (metadata).

  3. IIS: And we have Internet Information Server (IIS), which runs the CRM Website. This is the primary interface to the users.

  4. Reporting Server: This is SQL Server Reporting Services. The reporting server allows to create all sorts of reports
    from the business data. Even if you would never use it, it still is a mandatory component in the CRM stack.

On a "process level", CRM is quite complex, but very interresting. In a later section, we will see
stuff like "the event execution pipeline", and synchronously or asynchronously events.

For now, the components listed above, are representing "the infrastructure" of a MS CRM installation.

Users primarily interfaces to CRM, with a browser to the CRM Website. From there, they can view and enter data
for all area's where they are permitted to (security in CRM will be discussed later).
Using certain extensions, you can interface to CRM, using Outlook, and other client software as well.

The infrastructure components above (CRM, SQL Server etc..), can all be installed onto one machine. Ofcourse, that
might be done for a test/play environment.

Ofcourse, in most production setups, the "tiers" are distributed over several machines.
So, a certain setup might use SQL Server on a dedicated machine, while CRM App Server and IIS are living on another machine.
So you might view such a system as the "middle tier" to be the IIS/CRM Application services, while the "Backend tier"
is the SQL Server Instance.

1.2 Quick overview versions and product lines.


Microsoft has it's CRM software productline, but used to have a seperate ERP productline as well.
CRM and ERP are different, but there are certainly some overlaps. ERP also encompasses financials and logistics.

Since 2016, and "Dynamics 365", the CRM and ERP lines are integrated in Dynamics 365.
It simply depends now on which modules you buy or rent.

Before Dynamics 365, it seems that we had the following seperate productlines:

-CRM line: Dynamics CRM (up to and including CRM 2016)
-ERP line: Dynamics AX (up to and including AX 7)
-lighter variant of ERP: Dynamics NAV
-Resource Planning lijn: Dynamics SL

Highlevel view on CRM versions:

Fossile versions like CRM 1.2, 3.x → CRM 4 → CRM 2011 → CRM 2013 → CRM 2015 → CRM 2016 → CRM Dynamics 365.

As of version 2011, the name "Dynamics" appeared in the name of the product.

As of version 2011, you can have the "on premises" version, or the "online" (cloud) version.

Highlevel view on Upgrades:

If you have an early version like CRM 2013, but you want to upgrade to "Dynamics 365",
the Microsoft recommended path seems to be:

CRM 2013 -> CRM 2015 -> CRM 2016 ->CRM Dynamics 365

-You cannot upgrade "directly" from CRM 2013 (or earlier) to CRM 2016.
-Before you can upgrade to CRM Dynamics 365, you need to be on the CRM 2016 level.

All the above, is information gathered from MS docs. However, I have seen usercomments who have
deviated from such paths, and for example, have gone from CRM 2013 directly to Dynamics 365.
That's always a rather complex multi-step operation, like exporting/importing data, exporting/importing solutions etc..

1.3 Birdseye view Architecture MS CRM.

On an Operating system level, without any advanced tools, you can explore the services "a bit".

-On the (dedicated) SQL macine, you ofcourse would see the "SQL Server services", and if the Report service (SSRS)
is also running on that machine, you should see that as well.

Only two databases are important for CRM:

-MSCRM_CONFIG, which is a smaller database containing metadata for your system.
-ORGANIZATION_MSCRM, which contains your actual data, plus objectmetadata (webresources).

If your organization name was choosen to be "MyFirm", then this databasename would be "MyFirm_MSCRM".

It's possible to create more than 1 Oragnizations under the same CRM instance. Suppose you would have created
a second Organization called "TEST", then in SQL Server a database called "TEST_MSCRM" can be observed.
However, for the CRM instance, there will exist only one MSCRM_CONFIG database.

Most often, Domain service accounts are used as the credentials for the services, like e.g. "MyDomain\svc_reporting"
for the Report service.

-On the CRM Application Server, you should see something like (from a cmd prompt):

C:\TEMP> net start | find /I "CRM"

Microsoft CRM Email Router
Microsoft Dynamics CRM Monitoring Service
Microsoft Dynamics CRM VSS Writer
Microsoft Dynamics CRM-service voor asynchrone verwerking
Microsoft Dynamics CRM-service voor asynchrone verwerking (maintenance)
Microsoft Dynamics CRM-service voor sandboxverwerking
Microsoft Dynamics CRM-service voor uitpakken

Since I use the Dutch (NL) version (CRM 2016 on premises), you see some Dutch in the listing above. However, you should see
similar services on your system.

Using a default setup, the CRM services run under the "Network Service" credentials.
I have seen an ongoing discussion on the Net, if not a Domain service account would have been a better choice.
It seems to me better too, but I have not further explored that path.

As an overall (simple) architecture, the following figure might serve:

Fig. 1: "Jip and Janneke" figure, showing the Overall architecture:

Source: My own "Jip and Janneke" figure.

The figure above, is extremely "high level". Ofcourse, I hope this short note will deliver some "substance",
once you have read it completely.

2. How CRM "works".

One could talk about this subject, in at least two modes: a functional one and a technical one.
I will combine both, with emphasis on the technical side.

2.1 Introduction on how MS CRM works.

The primary interface to the users of MS CRM (on premises), will be via the Microsoft CRM Website,
using a url in their browsers like, for example:


Or using explicitly the Organization Name in the url:


There are some great tutorials on the Web. The following one is great and gives a good overview
on what MS CRM is, and how it works. You will see the functional modules, entities, fields, forms,
the basic on Webresource programming, and assigning those to objects.

I would never have done a better job than this tutorial.
Please go to:

CRM tutorial (www.tutorialspoint.com/microsoft_crm/)

and take a look at the following chapters:

Microsoft CRM - Home
Microsoft CRM - Overview
Microsoft CRM - Environment
Microsoft CRM - Functional Modules
Microsoft CRM - Entities & Records
Microsoft CRM - Fields
Microsoft CRM - Forms
Microsoft CRM - Searching Microsoft CRM - Web Resources
JScript Web Resources
HTML Web Resources
Microsoft CRM - Workflow Processes

Those chapters are enough, and then return to my note. (or you can read that entire tutorial ofcourse).

I really rely on the fact that you have given those chapters a serious look, and it saves me an enormous amount of work.
I already said it before: I would never have done a better job than this tutorial.

2.2 A few words on Storage of objects in SQL Server.

Returning to my own stuff now...

When you install CRM, at some point, it will ask you for your Organization.
Suppose you enter "XYZCompany", then the database "XYZCompany_MSCRM" will be created.

This database is often referred to as the "Organization" database, or simply "Org" database.

It will contain all data that your users will enter, like data in the tables Accounts, Contacts etc..
From the CRM interface, tables are referred to as "entities".

In SQL Server Management Studio (SSMS), or using queries, you can obtain all sorts of characteristics
from your Databases in this Instance. For example, just query on some fields of the
(global) systemview "sys.databases":

select substring(name,1,25) as "Name", database_id, substring(collation_name,1,30),
compatibility_level from sys.databases

msdb..................4 ...........Latin1_General_CI_AS.....110

Using the graphical SSMS, or using queries, you can see all tables and their properties, and other objects
in the XYZCompany_MSCRM database.
As just an example of how usefull the (standard) SQL Server system view "sys.databases" is, you might try
SELECT * FROM sys.databases, and see for yourself how much info it has.

By the way, as another example, note how the compatibility_level of XYZCompany_MSCRM deviates
from the other databases. With just a new CRM install, it will not deviate.
However, in this example output, it seems likely that the Org database was "imported"
from an earlier CRM version, hence the earlier compatibility_level of the database.

⇒ Showing Webresources:

When you have indeed studied the chapters from the tutorial as suggested in section 2.1,
you know about the term "Webresources". These are the client additions you have created yourself,
like .png (graphical) files, or additional HTML, or Javascript (JScript) which are registered on Forms.
They are stored in the database as well.

One thing though, is that "objects" (like webresources, users etc...) are identified by CRM, throughout the database,
by their "Globally Unique" ID (GUID). These are strings like "5030BEBE-27A4-DE11-B992-00155D02432A".
So, if you browse through tables, you will see those GUID's quite often (everywhere, actually).

Ofcourse "true" data like sales, products, contact names etc.., is simply human readable data.

However, the objects as webresources, solutions etc.. are identified (by CRM) by their GUID's, but
they have a readable name is well. If you create a Jscript named "Account_main_libary.js" and save it
in CRM, then it will have it's own GUID in some tables, but that readble name is stored as well.

The users of CRM, are known to the system as "systemusers". There indeed exists a table called "systemuser",
containing records of the users with their GUID but their readable name as well. You can easily browse through that table
and see for yourself.

Suppose "Mary" and "Anna" are developer of forms and Jscripts. Then you will find those records in the table "systemuser".

Most webresources are stored in the table "WebResourceBase".
Suppose Mary has a GUID which is "5030BEBE-27A4-DE11-B992-00155D02432A". Anna has her own GUID.
Then you can find the webresources created by Mary and Anna by using:

select substring(a.name,1,50) as "ObjectName", substring(b.DefaultMailboxName,1,30),
b.CreatedOn, b.ModifiedOn, a.WebResourceType
from WebResourceBase a, systemuser b
and b.systemuserid in
order by b.DefaultMailboxName

On purpose a created such query using GUIDs. Indeed, not always are you able to use common names.

⇒ Showing "Solutions":

We have not talked on "solutions" yet, but in the next chapter, "programmatic objects" are the subjects indeed.

In short, a "solution" is a whole package of additional objects that you have uploaded or created in CRM.

Those descriptions are in the database as well. You might try:

select substring(CreatedByName,1,20) as "Name", SolutionID,
substring(FriendlyName,1,40) as "Name" from Solution

in order to see the names of all solutions and the creators thereof.

⇒ Showing "Plugins":

select substring(ModifiedByname,1,25) as "By", substring(CreatedByname,1,25) as "CreatedByName",
solutionID, substring(name, 1,35) as "Name", ModifiedOn
from PluginAssembly

Or narrowing down the list by requiring a certain author (Mary):

select substring(ModifiedByname,1,25) as "By", substring(CreatedByname,1,25) as "CreatedByName",
solutionID, substring(name, 1,35) as "Name", ModifiedOn
from PluginAssembly
where CreatedByName like '%Mary%'

You might say: "I can find this all, from the CRM interface as well. Just use 'Settings' -> 'Customizations'."
True, but I like to show how it's registered in the ORG database.

Ofcourse, such stuff as shown above is not difficult in itself, but it's actually not for "ordinary" users.
So, I assume that you are a CRM manager, or SysAdmin, or are with the Technical Application Support Team, or something.

⇒ Showing Tables ordered by number of rows:

SELECT distinct substring(sysobjects.name,1,50) AS TABLENAME,
FROM sysobjects, sysindexes
WHERE sysobjects.id=sysindexes.id
and sysindexes.rows > 0
ORDER BY sysindexes.rows desc

In the listing, you might see the entities (tables) which you ofcourse also can view from the CRM interface.
The listing can be useful to get an idea of the most heavily used tables in your system.

It's possible that an "audit table", namely AuditBase, is very large, since auditing is switched on per default in CRM.
You might not need that data, and using the CRM interface, you can delete partitions from that audit table.
Make sure that you really are allowed to delete rows, and (optionally) check this with the security officer
if indeed such an entity exists in your Organization.
If it's OK to cleanup this logging table, then use the CRM interface, and do not use a SQL statement to delete rows.

If you like small notes in how to further view internal systemviews (of SQL Server), you might like
to try the following notes:

  • Some SQL Server TSQL queries
  • Small note on how to Keep SQL Server "Up and Running"

    Further, the CRM middletier has all "knowledge" of the CRM metadata in the Org database, and knows
    exactly on how to handle it (DML: update, insert, delete, select, plus DDL: create, drop statements etc..)

    The forementioned two databases are critical for the operation of CRM.
    Backup and Restore of databases is usually the task of the DBA. You might want to know how the databases
    are backupped. Best is to ask the DBA.
    Also, before any update or rollup is applied to CRM, make sure you have recent backups of the databases.

    2.3 A few words on the middle tier: CRM Application Server.

    Fig. 2: "Jip and Janneke" figure, showing some of the Internal components of CRM and their relation.

    Source: My own "Jip and Janneke" figure.

    A few keywords here, will "type" CRM to a certain measure:

    To large extent, CRM is "message" based, for exchange of data, or for calling "methods" (functions of other objects).

    Since messages are central, a "event execution pipeline" makes sure that the messages are handled,
    and the requests "in" those messages, are executed by the webservices.

    Thus, a Core component are "webservices". Other code, like custom PlugIn's (or standard PlugIn's), "consume"
    certain functionality of those webservices. Or, in other words, the PlugIn's call the methods of such services.

    Such a call results in an "event" and a corresponding "message". Sometimes, the words event and message
    are used interchangebly, is my impression.

    It's important to understand that the "webservices" are indeed those services as in the SOA specifications.

    Ofcourse, the stack is layered, so the webservices with the underlying business logic, need to use data access services,
    for example to access the metadata and Org databases. This then holds for the "Organization Data service".

    Depending on the CRM version, some core webservices are implemented. As of 365, the service "Web Api" will
    take over much functionality from other services, most notably the "Organization service".
    However, still for 365 (in august 2018), 2016, and lower versions down to 2011, we have the webservices:

    -The "Organization service" which would communicate with .Net additional code (additional customized code, like PlugIns).
    To access it, the SOAP protocol was/is used.

    -The "Organization Data service" is more geared towards CRUD operations, which means in SQL language
    SELECT, INSERT, UPDATE, DELETE (DML) and DDL, whereas CRUD means Create, Read/Retrieve, Update and Delete.
    These are implemented as methods in the "Organization Data service".
    It's compatible with the OData or REST protocol to access it's functionality.

    -The "Discovery Service".

    Each of those services have a URL, to which you can connect to, like for example:

    Organization Service URL (on premises): http[s]://hostname[:port]/XRMServices/2011/Organization.svc

    It's just an example, for CRM 2011 up to CRM 2016.
    You can check your URL's by using the CRM webinterface and check: Settings/Customizations/Developer Resources.

    As said before, the 365 "Web Api" will (eventually) fully replace the "Organization service", and if I understood it correctly,
    the "Organization Data service" as well.

    Since some time, the "Windows Communication Foundation (WCF)" is used for the implementation of the Webservices,
    and thus lowering the dependency on e.g. http.

    A good idea of the Server components, or Server "roles", in CRM can be obtained by simply inspecting
    one of the CRM 2015/2016 (on premises) setup screens, like the one shown below:

    Fig. 5: A CRM 2015/2016 setup screen, showing the different Server components:

    3. Overview developing in CRM.

    3.1 Test environment and Sandboxes.

    CRM is multi-tenant, meaning that you can have more than 1 Organization under the same CRM install.
    You even can create an Organization for the purpose of a Test environment.
    In many articles, you will see such an arrangement.

    If you would have one or more of such additional Organizations, then they are also often called "sandboxes".

    So, you can have an additional seperate and isolated "organization" (including it's own database), in the same
    CRM installation. The CRM documentation often speaks of the Produktion "instance", and possibly
    additional "sandbox" instances. Since they are all isolated from each other, the CRM docs speaks of "sandboxes",
    which is a generic term for isolated environments (isolated "organizations").

    But they all reside under the same one CRM installation.

    Since a sandbox is isolated, you can use it for Test/Developing purposes. It seems that many folks
    indeed follow such practice. Usually, I recommend a seperate Test environment, but such undertaking
    is by no means an easy task.
    To create a seperate Test environment on different machines, is not an easy task. CRM is namely integrated in "active directory",
    and if you would try to create a true seperate Test network, then you need a DC with Active Directory as well, which might present
    it's own challenges.
    Then you would need to have copies of the machines (or VM's) having SQL Server, and the application Server running CRM and IIS.
    And indeed, if it's truly seperate, an AD instance as well.

    Personally, I would recommend a seperate environment, over the use of Sandboxes.

    Managing Instances, or managing Organizations:

    You can manage Organizations using the "Deployment Manager" (Microsoft.Crm.DeploymentManager.exe).
    Using this tool, you can create, delete, and import Organizations.
    In a default "on premises" install, you may find the "Deployment Manager" in:

    [drive:]\Program Files\Microsoft Dynamics CRM\tools

    Such a discussion as above, is probably part of a dicussion on the "release process", or the way
    you would handle custom software releases. So, this also relates to "source control".
    If you will manage CRM, or you are part of such a team, you need to invest quite some time to find the best solution
    for your organization. Interesting stuff for sure, but unfortunately not so very trivial either.

    3.2 Managed vs Unmanaged code, or, Managed vs Unmanaged solutions .

    As you will see below, you can develop a single PlugIn, or a Javascript, and register it into CRM.

    So, you are not forced to use "solutions" as shown below. However, the "default solution" will always be the collection
    of objects you will work with. It's possible to solely work with components in the "default solution" only.

    However, using other solutions have some advantages.
    A solution is a group of such components, which can be managed "together", or in other words, can be managed "as a whole".
    This especially is then relevant in exporting and importing (or deploying) the solution.

    Using solutions, you can create, and manage, a "deployment strategy". Note that this is related to section 3.1 as well.
    Indeed, it is possible to import or export a solution. If you export it, you will indeed have a series of files (in a .zip).

    Note that the idea of solutions is an administative convienience. The default solution will still contain everything.

    However, your particular objects in a particular solution, is "as if" it was being "tagged", and may operate "as if" it is an
    independent collection. It can also be tagged as managed or unmanaged.
    It looks like it is "outside" the default solution. As such, you can export that solution, and do other operations.

    It takes a while to get used to the "CRM way of doing stuff...".

    This way, we can have other solutions (collections) which all look independently.

    A "managed solution" ("inside" CRM) cannot be overwritten, so it is protected from any modifications.
    However, it is possible to set the property of a certain component "to allow customization".

    A solution can have more items than just programmatic entities. For example, CRM, "just out of the box", delivers you
    the "default solution" which is about everyting in CRM, like entities, reports, forms, roles, webresources etc.. etc..

    However, you can create another solution, which is just an additional package of certain objects. Indeed, very often these
    will be programmatic entities like JScripts or PlugIns.

    If you want to take a look at the entities in the default solution, or view other solutions, from the CRM interface, use:

    Settings → Customizations → Customize the System
    Settings → Customizations → Solutions

    Following is the screen you might see if you would go to the default solution using Settings → Customizations → Customize the System

    Fig. 3: Showing the components in the "default solution":

    Source: Simply a CRM screenshot (in browser), after choosen the menu option "Customize the System".

    At least the following components might be part of a solution (and is part of the default solution):

    Application Ribbon, Article Template, Business Rule, Chart
    Connection Role, Contract Template, Dashboard, Email Template
    Entity (a table in SQL Server), Entity Relationship
    Field (column in a table, also might show up on certain "forms")
    Field Security Profile, Form, Mail Merge Template, Message
    Option Set, Plug-in Assembly, Process, Report
    Sdk Message Processing Step, Security Role, Service Endpoint, Site Map
    Web Resource (like a JScript)

    Note that an external ASP.NET construct, with aspx files and Website, does not seem to be part of a "solution"
    in the context we have seen above. That's not so strange, since these are IIS deployments and are external to CRM.
    Ofcourse, such aspx entities can connect to the CRM system, and thus appears to be "integrated".

    It's probably best to review a Microsoft MSDN article on solutions, which you will find here.

    All of the above in this section, still is no more than a rather high-level view on solutions.

    Especially the "in and outs" of managed vs unmanaged solutions, could have been done better.

    Fortunately, good articles are on the Web. If you are interrested in more information on "managed vs unmanaged" solutions,
    in combination with deployments on Dev/Test/UAT/Prod, and lifecycles etc.., then take a look at the following article:

    Managed Vs Unmanaged Solutions (www.crmconsultants.co.uk)

    3.3 Overview Customizations/Developing.

    There are several ways, with various levels of effort, in how you can customize CRM to fit you business needs.

    However, CRM is CRM. That's rather trivial ofcourse, but if you go way out of that scope, one can wonder
    how benificial that is, and will remain to stay so. I have seen a system where financials plus invoicing
    plus lots more, was added to CRM, using inhouse programmers. That might be fine, but that also depends on how clever this
    all was set up, which determines how easy or how difficult it is, to maintain and support the system.

    In customizing CRM, (at least) the following area's can be distinguished. The following is my "interpretation":

    (1): Relatively easy: Creating "webresources" as HTML files.
    (2): Relatively easy: Creating standard Workflows.
    (3): Relatively spicy: Adjusting Ribbons (menu bars).
    (4): More elaborate activities: Programming Jscript (javascript) webresources, and associate them with Forms.
    (5): More elaborate activities: Creating Plugins, using Visual Studio (C#, VB.NET).
    (6): More elaborate activities: Creating aspx, and new websites, for specialized tasks, integrated in CRM.

    Note on Workflows: standard workflows can be created using configuration dialogboxes.
    which are available in the CRM interface. However, advanced "custom" workflows must be developed
    using Visual Studio and in fact closely resemble PlugIns.

    About (1) and (2):

    In section 2.1, I referred to another site which has published a tutorial on CRM.
    They indeed managed to illustrate the subjects (1) and (2) from my listing above, in a really nice way.
    So, for those subjects, please read the corresponding chapters from that tutorial, which are:

    HTML Web Resources
    Microsoft CRM - Workflow Processes

    About (3):

    Although altering the Ribbon (e.g. adding "buttons", shorcuts, Yes/No for showing options etc..) certainly can
    be useful, I leave it out from this note.

    About (4), (5), and (6):

    Yes, I like to present a high-level overview on these subjects, with their scope in CRM, their usual purposes,
    and some basic sample code.

    3.4 Developing PlugIn's.

    Here is some basic information on PlugIn's. It should be sufficient to understand it's scope
    and basic functionality.

    Typically, a PlugIn is a somewhat smaller code unit, created for DOT NET, with a very specific functionality.
    Since it's created for DOT NET, it is an "assembly", which physically is a .exe or .dll file.
    In CRM, library assemblies (.dll) are implemented.

    A PlugIn is "server-side" code, meaning it runs om the App Server, and it's integrated into
    the CRM business logic. Or, maybe it's better to say that a PlugIn extents the business logic.

    This is contrary to JScript (MS Javascript), which runs on the client.

    Typically, a PlugIn does not have a "face", and does not interact with the user. It simply does the task
    it was designed for.

    Most often, a PlugIn is like a handler for a certain event. Again, most often, such an event (the trigger)
    is a modification of some field of a certain table. Or, it's triggered by an insert, update, delete
    event on a certain table.
    The action of the PlugIn then might be an update on another table. Very often, the PlugIn is needed
    because custom tables (entities) were added to the system, and modifications on one table then implies
    certain modifications on other entities.

    However, PlugIns are not only usable for the sort of functionalities sketched above.
    For example, it might perform a financial calculation of some sort.

    A new PlugIn must be registered into CRM, before it can be used. Often, the "Plugin Registration Tool"
    from the SDK is used.

    The main purpose of registering a Plugin, is to let "CRM know", that a handler (the Plugin) for a certain event
    is available, and which must be fired when that event occurs.

    ⇒ The main actions you perform in "Registering" are:

    -registering the .dll (the assembly) and specify where it is located.
    -next specify where you want it stored: in the Database, or Global Assembly Cache, or disk.
    -next specify if the PlugIn is associated with an "entity" (that's a table), and specify that table.

    If that is indeed so, then the code in the PlugIn has ofcouse the statement(s) to "do something" with
    that table or another table.

    -next, specify the "pipeline stage of execution", which can be Post operation or Pre operation.

    If indeed a table transaction is involved, then should the PlugIn act before, or after the transaction?

    -next, specify if the PlugIn should work Synchronously, or Asynchronously.

    ⇒ Synchronous, or Asynchronous execution mode:

    -If code should work in Async mode, it will be placed in a queue and will be executed when the queue Manager
    has handled any other actions which were already placed in the Queue previously.

    Async is great for any code which does not need to be executed "right now", and such mode can significantly
    reduce the load on the system, where many users (and many PlugIns, workflows etc..) are involved.

    -If code should go to work "right now", then it should be defined to work in Synchronous execution mode.

    Obviously, since PlugIns often are bound to tables, and do an update/insert/delete on another table,
    the execution mode is often Synchronous.

    However, if the PlugIn is only designed to send an email (classical example of a PlugIn), then "there is no hurry",
    and it's best to specify the Async mode.

    You might like to review figure 2 again, to see the relation of PlugIns and the execution pipeline queue.

    The process of Registering a PlugIn is completely graphical if you would indeed use the "Plugin Registration Tool" from the SDK.
    It's not very difficult, although the corresponding dialogboxes require a lot of information to fill in.

    Ofcourse, writing the PlugIn (the coding process itself), requires a little understanding of C# or VB.NET.

    ⇒ The namespaces, or classes, you need:

    Java, DOT NET, and other OO developing environments, have large hierarchical trees of classes,
    containing reusable code, which you can "import" (or register, or extent) in your own new code.
    So, you do not need to "invent the wheel" all the time, since so much classes are already available.
    Therefore, before you start any typing of code, you select the classes you need for the job you want done.

    The class "Microsoft.Xrm.Sdk.IPlugin" contains almost everything you need to let your code interface to the right
    execution context in CRM.
    It's called the "Iplugin Interface". It exposes the "Execute(IserviceProvider)" method which is the basic code
    to respond to CRM events.

    As you see from it's name, it comes from the SDK. By the way, if you really start coding for CRM,
    you need the SDK anyway, so it's best to download the SDK for your CRM version.

    A little info on .Net namespaces:

    The dot Net framework also consists of a large library of classes (say: code of objects with methods and properties).
    These are organized into hierarchical "namespaces".

    We might have a certain namespace, and another namespace which looks like something like
    a child namespace "below it", like for example:


    The first one only includes the types and names declared for Sockets. It does not bring in or contain
    the full classes with the exact code and declarations and methods etc.., contained inside Sockets.

    That's why at the top of a Dot Net source code, most often a number of "using" directives are listed.
    So you might see for example:

    using A
    using A.B

    where the latter means that you want to use the namespace "B" under "A", and not another "B" namespace.
    So, you must use "using" for a certain namespace (classes), to bring it into the scope of your application.
    That's why a developer also carefully selects what he/she needs for a certain application.

    ⇒ Simple PlugIn example in pseudocode:

    I think that PlugIn's are not really the most easy ones (of the family of DOT NET codes)
    to understand, or write. One reason is, that they use quite specialized objects/methods
    for performing their task, and it does not look very intuitive, if you would ask me.

    In any plugin, you must set the "execution context" and get it from the execution pipeline.
    Thanks to have registered the PlugIn, CRM knows the enviroment to hand over to the PlugIn.
    That's why most PlugIn's have statements, high-up in the source code, like:

    IPluginExecutionContext context = (IPluginExecutionContext)

    One very important parameter, is the entity that the PlugIn uses for it's business logic.
    As you know, an entity is actually the table in SQL Server, and here, in this code, this specific property
    is called "Target".
    Don't forget that most PlugIns are designed to "fire" when certain tables are modified.

    if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is EntityReference)

    Usually, more intial code is needed, but this text is more about pseudo code than a real PlugIn.
    Once the Target is know, and other parameters as well, like the values of certain fields of the entity,
    the actual business code gets to work.
    Below you see an example of a certain calculation based on some table fields:

    if (context.InputParameters != null)
       Entity entity = context.PostEntityImages["PostImage"];
       List_price = (Float)entity.Attributes["price"];
       units = (int)entity.Attributes["units"];
       Total_P = new Float(price * units);

    "PostImage" means that we have retrieved the data after the database transaction was done.
    That is, the database transaction occurred anyway, whether or not a PlugIn is around.
    So, we used the "image" of values "afterwards or post event".

    Now something useful has to followup, like lowering the "in_stock" field
    of some table, or any other useful action.

    Ofcourse, some sort of Exception Handling should be there as well. That's why the business code
    often is written inside the "try ... catch" block.

    Section 3.4 is nothing more than the absolute minimum of information on PlugIns, but I hope
    that it helped to establish the general idea on PlugIn's.

    3.5 Developing using JScript (MS Javascript) for CRM.

    I think this is more common in CRM, compared to developing PlugIns.
    It's certainly less difficult to pick it up, and get Up and Running in Jscript.

    MS Jscript is around for many years now. The original Jscript looks a lot like Javascript.
    It's OO, meaning that classes and instantiated objects, methods, properties are to be used, alongside
    the usual constructs like variables, arrays, decision logic (e.g. if..then.. else) etc..
    You could use it on your PC, or on a Server, or any place where an interpreter/engine is present.

    However, Jscript for CRM seems a bit different, which becomes increasingly clearer as the
    CRM version gets more recent. The later JScript implementations for CRM, are pretty much tied
    to the CRM objectmodel (XRM.Page).

    That's why JScript in CRM, is a bit "different" from the general JScript implementation (I think).
    In the following I will exclusively refer to "JScript in CRM", and not the "general" JScript implementation.

    Javascript and Jscript are (originally) both "client side", meaning that it's executed on the client,
    and is downloaded from a Server to that client.
    However, in principle, wherever a Javascript "Engine" runs, it can run Javascript.
    So, where javascript actually runs might be any device. But usually, typically, it runs on clients.

    By the way, other Java variants like "servlets", runs on a Server and create the documents
    which are send to the client browsers.
    Or in the MS realm, you might think of Javascript in ASP.NET, or node.js implementations.

    Original Javascript, is a little different from the Microsoft JScript implementation.
    There is much in common in both worlds, but there are quite a few essential differences as well.
    Maybe they both look quite similar in syntax and scope, but remember that MS Jscript is not Java or Javascript.

    => Javascript is mainly tied to HTML programming, that is, to get, read, create, or manipulate HTML
    document objects, and properties of those objects.
    At some point, the W3.org produced a standard of the namespace, describing the objects,
    and hierarchy of the objects, and properties of those objects, which are present "in" the HTML document.
    As such, Javascript is able to access all objects and properties.
    The model was called the "DOM" (document object model), and represents the document as a hierarchy of nodes (objects).
    The model is "constructed" by the browser, and as a consequence, a programming language as Javascript
    can access the objects and properties.

    => MS Jscript often deals with CRM Webresources like Forms. To get, read, create, or manipulate
    the corresponding objects and properties, the XRM.Page namespace (or objectmodel) was implemented.
    Also, for example elements as table fields (entity fields) can be accessed and modified.

    So the area's where JScript operates on, is actually a bit different from Javascript.

    Depending on your view on matters, fortunately or unfortunately, the model where JScript operates on,
    have varied slightly among CRM versions as well. So there are some differences when you are going from CRM4 to CRM 2011.
    Then there are some differences from CRM 2011 to CRM 2013. And there are some differences from CRM 2013 to CRM 2015/2016.
    In general you may also say that support for DOM objects and methods, declined as the CRM version
    went more recent.

    In good tutorials you will find many recommendations and good practices for writing Jscript.
    One recommendation is not using DOM, but to try to adhere to the XRM.Page model as much as possible.

    A few notes on Jscript development:

    You can apply JScript in many area's of CRM, but the three most prominent ones are:
    1. Via OData or SOAP endpoints, scripts can interact with web services.
    2. Ribbon customazation (working at the "ribbon menu system", like activating buttons).
    3. Interacting with forms, and form "event handlers".

    Typically, a .js script contains one or more "functions" like:

    function myfunction()

    If the script has two or more functions, it is often called a function library.
    Ofcourse, such functions in the one same script should be related to the same subject, like
    a library dealing with the account entity, and the related forms, in CRM.

    The usual programming techniques can be used, like declaring "global" variables which are
    defined outside the functions (at the top of the script).
    And ofcourse "descision logic" can be used like if.. then.. else.. blocks.
    All in all, it looks pretty much like most common programming environments.

    However, the objects (classes), methods, and properties that you will use in your statements,
    must be from the XRM.Page namespace (or objectmodel).

    But, since JScript was quite heavily used in e.g. CRM4 or earlier, and CRM 2011, the DOM objects
    are almost inevitable if you are dealing with a system originating from CRM 2011 or earlier.

    Once, I needed to upgrade a CRM 2013 system to CRM 2016 (via CRM 2015). That system was even migrated
    a long time ago from 2011 to 2013. So, the Jscripts used a lot of DOM objects, and were full of unsupported objects and properties.
    Indeed, once on 2016, quite a few produced errors, or simply did not worked anymore.

    Amazingly, by replacing the statements as shown below, it was possible to get many of them
    in a runnable state in 2016. (There were many exceptions to the rule, and required more effort).

    -document.getElementById(); replace by: parent.document.getElementById();
    -context.getServerUrl; replace by: Xrm.Page.context.getClientUrl();
    -disableViewPicker; replace by: Xrm.Page.ui.controls.get("").setDisabled(true);
    -crmForm.FormType(); replace by: Xrm.Page.ui.getFormType()

    Other statements were problematic too. So, I still had not a fully functioning system. Those statements were like:

    -Certain Statements using "attachEvent()"
    -Certain properties or methods related to "padding".
    -Amazingly, also statements like "field".style.fontStyle = 'italic'; /or other font.

    For about the latter three: I could not always replace them, and had to write other code,
    to get the same functionality.

    Then there were quite some errors which turned out to be related to JQuery.
    I had a hard time figuring this out, and I never completed to find the real source of errors,
    and how to correct it. In my case, lots of JQuery parts still worked, but others did not, like for example
    AJAX routines. I did not solved it, but simply took another road. So, I cannot tell you how to handle
    a migration CRM 2011/2013 to CRM 2016 with respect to JQuery.
    However, Microsoft states that JQuery for usage in forms, is unsupported. This is certainly observable
    as of CRM 2015 SP1.

    But, although I found other ways to more or less achieve the same results, maybe in your case, if migrating
    from CRM 2011 / 2013 to 2016, you might try to use a newer JQuery library.
    I observed some good results in upgrading JQuery_1.9.1 to version 2.xx or 3.xx.
    But, on a whole, I still had too much errors and I migrated as much as possible to using "XMLHttpRequest".
    But if you are migrating as well, you might simply also try a newer JQuery library.

    A lot of original Javascript DOM statements still remained present in the scripts. Not all statements
    adhered to the Xrm model, and there still remained plenty of usage of the DOM model.

    But, as you can see above, there were about 8 types of statements which absolutely needed to be converted
    to the Xrm model, to make it work. At least, that's my experience.

    In my case, in CRM 2016, I also tried the legacy form rendering emulation (like in CRM 2011/2013) which
    you can set in CRM 2015/2016. I believe that this option temporarily might help some shops.

    See also Appendix 5 for more tips with respect to reverting to the 2011/2013 "legacy form rendering".
    Ofcourse, this is certainly not a solution, and must be regarded as a temporary workaround.

    Note: To make a system "runnable" is quite different ofcourse from making it really compatible with future
    versions of CRM. The best thing ofcourse is to make the scripts fully compliant to the latest object model.

    4. Some other stuff in CRM.

    4.1 Integrating CRM with email.

    Instead of a bunch of local email stores, calendars, appointments etc.., the important business info
    should be centrally stored, and be accessable by users, as it should be in real collaboration.
    This is a very important feature of CRM.

    CRM itself does not have the capabilities of a true email Server. That's why additional components are required.
    However, it gives the impression that it does have the functions of an email Server:

    -From the webinterface, there are options where you can send mail.
    -An customized PlugIn, which is serverside code, may send mail.
    -A Workflow, Campaigns, may result in sending mail.

    However, a component "in the middle" with email Forwarding capabilities (to the mail Server) is required.
    But, indeed, in the most simple setup, the CRM Outlook clients itself can act as the component that takes care
    of all the inbound and outbound emails for CRM. But this scenario has drawbacks.
    For example, for emails and appointments etc.., the client has controls to enable "Track in CRM".

    There are in fact 3 options which make mail possible:

    (1). Using Outlook, with the additional "CRM for Outlook" (Outlook client) software.
    (2). The traditional "email Router" component which sits between CRM and the email Server (like Exchange).
    (3). Using "Server Side Sync" (SSS) available as of CRM 2013, but more common as of CRM 2015.

    (2) and (3) have a central server component, handling email to, and from, CRM.
    Note that this also equates to the statement that (2) and (3) enables CRM to communicate
    to the ouside world, and not being dependend on Outlook clients.

    ⇒ SSS:
    As of CRM 2015, Server-Side sync (SSS) is a server-side process, in the CRM instance, for synchronizing appointments,
    contacts, tasks (ACTs), and email messages between Exchange Server and Microsoft Dynamics CRM Server.
    SSS is a module in the Asynchronous Processing Service, and runs on the same Server as the other modules
    of CRM does.

    ⇒ Outlook + CRM for Outlook:
    Traditionally, SSS, or also the "email Router", can be omitted. This time, the Outlook clients configured
    with a CRM add on (CRM for Outlook), will be the middle component for messages between CRM and Exchange.

    ⇒ The traditional "email Router":
    This module sits between CRM and Exchange (or other pop3/SMTP mail server).
    It's a seperate component, which must be downloaded (or run from the Web), and installed on
    any suitable machine in your domain, or on the CRM Server itself.
    The "email router" will be installed as a windows service, and a GUI will also be installed.

    Microsoft claims that this module is depreciated as of the December 2016 update for Dynamics 365.

    From the download, run the SetupEmailRouter.exe file ( from ..\EmailRouter\amd64 for 64-bit or ..\EmailRouter\i386 for 32-bit),
    under administrative privileges.

    Setup will install the CRM Email Router Service. It also installs the Email Router Configuration Manager.

    Using this Configuration Manager, you need to create an Incoming- and Outgoing email profile at this router.
    This also must specify the location of the Echange Server and how to access the mailboxes.

    Impression of configuring the "Email Router" or "SSS" or CRM:

    Let's study a few nice articles/blogs:

    Config Email Router or SSS:

    Configure email router with Exchange Online (1)
    Configure email router with Exchange Online (2)


    If you use the email Router, or SSS, also in CRM itself you must configure that.
    Using "Settings->Email configuration->Email Server Profiles" and click "New".
    This gives you the option to create an Email Server profile.

    Then, you can configure each mailbox with information like:

    -Server Profile: Select the server profile which you just created.
    -Incoming Email: Set this option to "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".
    -Outgoing Email: Set this option to Server Side Synchronization or Email Router.
    -Appointments, Contacts and Tasks: "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".

    4.2 CRM and the Report Server SSRS.

    You need to have the "SQL Server Report Server" (SSRS) around, if you want to use CRM (on premises).
    Usually, SSRS is installed on the same machine where SQL Server itself is installed.
    I cleary say "usually", since SSRS can be installed on any suitable Server. Ofcourse SSRS needs
    access to it's own report databases on some SQL Server instance.

    CRM is a rather large application, and this note, simply just scratches a few, from a large number of topics.
    But SSRS is interesting, and it's "not so very trivial" to troubleshoot if errors occurs.

    (1). Microsoft Dynamics CRM Reporting Extensions:

    During the setup of CRM (like CRM 2016) you also need to install the "Microsoft Dynamics CRM Reporting Extensions"
    on the Server which runs the SQL Server Reporting Services.
    Again, it is essential to know that this needs to be installed on the server where the SSRS is installed.
    It is mainly used at authenticating CRM to SSRS, so that "delegation" and that sort of stuff, can be avoided.
    It's effectively a data processing extension which attaches itself to the SSRS server and accepts
    the authentications from the CRM server and passes it to the SSRS server.
    In former CRM versions, there were authentication problem when trying to access and run reports
    due to Kerberos or other authentication issues.

    (2). SRS Data Connector:

    This is effectively the same as (1). That is, formerly, folks called it the "SSRS Data Connector",
    but in later CRM versions it is called "Microsoft Dynamics CRM Reporting Extensions".
    So, it's basically the same sort of thing.

    (3). Setting the SQL Server Report Server URL in CRM:

    There might be multiple ways to do that, but the following one works too. It uses the "Deployment Manager".
    If you want to use it, you must go to the CRM Application Server itself (thus where CRM runs on),
    and browse for the executable file. It's probably in a location similar to:

    C:\Program Files\Microsoft Dynamics CRM\tools\Microsoft.Crm.DeploymentManager

    Select your Organization database (there could be more than one), and check the "properties".
    Note that there exists an option to change the URL.

    The URL should be of the form: "http://computername/reportserver".

    This concludes my simple note on CRM.

    I must say that I started to like the MS CRM system. I had some previous exposure to other CRM systems,
    but MS CRM is generally quite OK. However, it's also a bit freaky here and there, and I am sure that
    folks who manage it at a system level, will agree that there are quite a few odd things in that system.
    That even holds for CRM 2016, or Dynamics 365.
    But, I have to say: it really works...


    Sometimes, items will be added in this Appendix.

    1. Error reporting dialog box in CRM 2016.

    Especially in CRM 2016, you cannot disable the "error reporting" DialogBox in a intuitive manner,
    using the interface. Here I mean the following dreaded dialog box:

    Fig. 4: General Error Dialog box which may pop up all the time:

    In former versions, like CRM 2015 and lower, you could disable it on a Global level,
    thus for all users.

    The point is that this dialogbox may show at non critical issues, for example with a functional Java script,
    but where the methods are not in line with the Microsoft XRM model.
    Although repairing the source of the error is the best practice, but since CRM still works OK, you might
    consider disabling the error reporting on a global level (for all users).

    For jscript and form related errors: see appendix 5.

    If the errors bother you users to a level where they are seriously hindered in their work, you may
    try the following methods:

    1. Xrmtoolbox.

    From "https://www.xrmtoolbox.com/" you can download the Xrmtoolbox, which provides you many
    easy configuration tasks for CRM.
    It also includes disabling the error dialogs on a system level.
    Xrmtoolbox provides many options, and its best to try it and see it's capabilities in a Test environment.

    2. Calling the hidden preferences/configuration page in CRM 2016.

    From the site:


    You will find an alternative for the Xrmtoolbox, and some further explanation.

    In essence, Paste the following in your CRM webinterface:

    javascript:var frame = document.getElementById("InlineDialog_Iframe");
    if (frame == null) { alert("Click Privacy Preferences before executing this code."); } else
    { frame.contentWindow.document.getElementById("privacy").style.display = ""; }void(0);

    Credits for this method must go to user "Magnetism", on "community.dynamics.com".

    This will then show you the preferences Page, as it used to show in CRM 2015 / CRM 2013.

    2. CRM 2013/2015/2016/365 error codes.

    CRM 2013:


    CRM 2015/2016:


    CRM 365:


    An error which may appear in a Dialog box, or logfile, may have to be converted to Hex first, before you can
    look it up in the above links.

    If you have a certain code, then paste in into calculator, and let it be represented in Hex.
    Then, if needed, ignore all F's which might be present in front of the code, and then you will have codes
    as listed in the links above.

    3. Listing of CRM build numbers and service packs, rollups's etc...

    The following site, presents a good overview on CRM builds, service packs etc..

    CRM builds, service packs etc.. (buildnumbers.wordpress.com/crm/)

    4. Some links describing errors and how to resolve them.

    Nice link 1: from "dynamicsessentials.net"
    Nice link 2: from "cloudfronts.com"

    5. Under CRM 2015 or 2016: use "Legacy form rendering" again, instead of turbo forms.

    In CRM 2015 and later, the rendering of "forms" has been changed, compared to CRM 2013 / 2011.
    It could happen that you have customized the CRM 2013 / 2011 system in a large extend, including event handlers
    using javascript, using objects and methods which are (partly) not supported anymore in CRM 2015 and later.
    It might be to such an extend, that you users are severly hindered in their work.
    The errors shown are often javascript errors (like on load events), form error messages etc..

    The following is not a solution, but might be seen as a temporary fix. Under CRM 2015 or 2016, and later,
    it's possible to revert to the older (or legacy) rendering of CRM 2013 / 2011.
    Ofcourse, you should always invest time to adjust your customized forms and scripts, to make them compliant again.
    However, you might try the "fix" to see if it helps you.

    From the CRM webinterface in CRM 2015/2016/365, use the menu system:

    Settings -> Administration -> System settings.

    Fig. 6: Setup Legacy Form Rendering (the 2013/2011 model) in CRM 2015/2016: