A simple note on Microsoft CRM or Dynamics CRM.

Date : 30 August, 2018.
Version: 1.1
By: Albert van der Sel.
Status: Ready. However, subjects will 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.

In the summer of 2018, 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 brutal, 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.

So, there are two major streams:

(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.

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.

Productlines:

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:

https://crm.mycomp.nl

Or using explicitly the Organization Name in the url:

https://crm.mycomp.nl/MyComp

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

Name..................database_id..Collation................compatibility_level
master................1............Latin1_General_CI_AS.....110
tempdb................2............Latin1_General_CI_AS.....110
model.................3............Latin1_General_CI_AS.....110
msdb..................4 ...........Latin1_General_CI_AS.....110
XYZCompany_MSCRM......5............Latin1_General_CI_AS.....100
MSCRM_CONFIG..........6............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
where
b.systemuserid=a.CreatedBy
and b.systemuserid in
(
'5030BEBE-27A4-DE11-B992-00155D02432A',
'9EF40CE9-3DE7-DA11-85E3-000BCD8349C7'
)
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,
sysindexes.rows
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.

    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 PlugIn assembly.

    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:

    System.Net
    System.Net.Sockets

    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)
    serviceProvider.GetService(typeof(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).

    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.







    Parts:

    (1):
    Jscript conversion from DOM to XRM.Page:

    Most important statements to replace:

    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);