A simple note on Microsoft CRM / Microsoft Dynamics CRM.

Date : 6 November 2019.
Version: 1.7
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".

I wrote this note about a year ago. Recently I did a few additions and revisions.
Hopefully, the text provides for a helicoper view on CRM, but with some emphasis on
the technical implementations. I think it's usable for CRM 2011/2013/2015/2016/Dynamics 365, up to v. 8.xx.

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


For me too: CRM poses sometimes quite a few challenges, especially at coding, and not all is christal clear,
but I am on my way...

CRM is 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. 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.


Contents:

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 Overview Developing with JScript (MS Javascript) for CRM.
  3.6 World's smallest and incomplete JScript tutorial (MS Javascript) for CRM.
  3.7 A few words on iFrames, JQuery, REST, oData and stuff like that.

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

Appendices.
  1. How to get rid of the Error reporting dialogboxes in 2016.
  2. Links to CRM 2013/2015/2016/365 error codes.
  3. Links to CRM buildnumbers/updates.
  4. Some Links to CRM errors and how to resolve.
  5. CRM 2015/2016 How to enable "Legacy Form Rendering".
  6. Link to CRM 2013 Api cheatsheet.
  7. A few pointers for replacing JScript DOM to Xrm.Page.
  8. How to enable Tracing in CRM 2013/2015/2016/365.


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.

Today, CRM Dynamics 365 v. 8.xx and v. 9.xx, can be regarded as current versions.

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.
I don't think you should change the default, 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.

    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. 3: 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. 4: 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 quite a bit of 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 Overview 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 a function call associated with a button).
    3. The most used category: Interacting with forms, and form "event handlers".

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

    function myfunction()
    {
    ..
    statements
    ..
    }

    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 quite a few 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()

    But the replacement of "document.getElementById();" by "parent.document.getElementById();",
    was probably only helpful up to CRM 2015 (from CRM 2011/2013).

    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.

    Note: Since Dynamics 365, it might be fair to ask in how much XRM.Page will still be fully
    supported in later versions.
    Sure, it will be supported for a long time from now, but a newer objectmodel might get preference
    in the not too far away future.


    See Appendix 6 for an overview of converting DOM to XRM models.

    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.

    As I understood at a later moment, JQuery "should be better", since it wraps pure XMLHttpRequest
    into a more generic call. Strangely, that is not what I observed. However, every customized CRM system
    has it own quirks, and it might be so that JQuery works better in general.
    So, XMLHttpRequest is what the browser wants to see to make the request. JQuery is just a library,
    and the $.ajax method is used to make the raw XMLHttpRequest.

    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 only 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.
    But that's not to say that workarounds (like "legacy form rendering") are not helpful.

    3.6 World's smallest and incomplete tutorial on JScript (MS Javascript) for CRM.

    This section is not a full tutorial on JScript programming. It only shows you some basic idea's.

    It deals on CRM 2013 up to 2016, and the early Dynamics 365 versions, which all are using the Xrm.Page model.
    For later Dynamics 365 versions, it seems that MS urges us to use the FormContext model,
    as of Dynamics 365 v. 9, thereby (more or less) leaving the Xrm.Page model.


    A form generally also displays database data (from tables/entities like "Account").
    The data is displayed in fields on the form, and this data is generally called "Attributes".

    "Controls" exists too, associated with "attributes", for example whether an attribute should be visible or not.
    In such a case, the corresponding field on the form is visible or is not visible.
    Generally, multiple controls may be associated with an attribute (data element/field).
    Controls generally are forms, tabs, and fields on those forms/tabs. When it is about fields, then
    it will contain data (attributes), where controls may affect how it is displayed.

    Most js programming probably involves about event handling, that is, responses on actions
    of the user on form data and elements.

    Any form has three major events: OnLoad, OnSave, OnChange.
    You "tie" a js library function to such an event.

    If you want to do that, or create javascript, to "tie" that js to a form related to an entity,
    you might want to navigate within the CRM userinterface, to the following path:

    Settings → Customizations → Customize the System → select the Entity (like Contact) →
    select the Form (like Main Form) → Select "Form Properties"

    You can try that, with any entity. Ofcourse, not all will be associated with Jscripts.
    In my case, there are additional entities in CRM, for example associated with invoicing. So, when I navigate
    using a path as shown above, I might see the following Form Properties:

    Fig. 5: Example "Form Properties" in CRM 2011/2013/2015/2016/365:




    I am working with a Dutch version of CRM 2016, so that's why you see dutch in the figure above.
    But in your language, you should see a similar figure.

    Note that in my case, the javascript "Invoice_main_library.js" is associated with this form.
    Furthermore, all that Jscript code, is available when the Form loads.

    Since JScript is OO, the object's methods and properties, have a "object_name.method_name()" or "class_name.method_name()"
    way of calling them in your code. It's all about a hierarchical namespace, so statements go in
    the form "Xrm.Page.class.method()" way of writing it down.

    There are three main classes under Xrm.Page:

    Xrm.Page.context
    Xrm.Page.data
    Xrm.Page.ui

    Officially, those three are called namespaces. Below that, are "objects". We are not going to be
    very formal in this text.

    So, you might think that any call to a function (method) will always use such a path as a start.
    But the "root", that is Xrm.Page, has callable methods as well, like e.g. "Xrm.Page.getAttribute()",
    if the the context of the data already is obvious.
    As it turns out, Xrm.Page.getAttribute() and Xrm.Page.getControl(), are indeed important means to access
    data and controls.

    -For example, If you want to access Data (an attribute), then you might formulate a statement like:

    "Xrm.Page.data.entity.attributes.some method()" or for example "Xrm.Page.some method()".

    -For example, If you want to a User interface element, then you might formulate a statement like:

    "Xrm.Page.ui.controls.some method()" or "Xrm.Page.some method()".

    However, there are more "paths" to Controls, and it takes a bit of experience to get along with them.

    Since this is World's smallest tutorial, I will now show some (hopefully) representative examples.
    But remember that JScript is a full language. You can go about and declare variables and arrays etc..,
    much like the old style in doing things, and program the traditional way.
    Here I only show some examples using the classes, objects, and methods in the Xrm.Page model.

    (1). Connect to the "context": Xrm.Page.Context

    "Context" should contain info on "where you are in CRM", or about your logged-on credentials,
    and much more other stuff. The following code should illustrate it:

    if (Xrm.Page.context.getUserId() == "{3EF40CE1-3DE4-CA91-45E3-100BCD8149C4}")
    {
      alert(msg);   //This is comment, using the two slashes. Msg is defined elsewhere.
    }

    The getUserId() function has determined that I am working, and that my ID is represented
    by that long GUI string. So, if the code runs while I am working with the form, the "msg" is printed,
    but not for other users when they are working with that form.
    Also note that "=" (is, isequal), is represented by "==".

    Note: the equaltity determination in Javascript, is a tiny bit complicated, like what exactly means
    "==" or "===" etc.., but that is not relevant for this text at all.

    (2). Connect to an "attribute" and connect to a "control":

    There are multiple ways here.

    (2.1) Xrm.Page.getAttribute() and Xrm.Page.getControl().

    Let's first see about Xrm.Page.getAttribute() and Xrm.Page.getControl().
    Those methods provides for getting a handle to data or control objects.
    To indeed use it, you must provide the "logical name", or string, or qualifier,
    which represents that attribute or control.

    Take a look at this:

    var lookupItem = new Array;
    lookupItem = Xrm.Page.getAttribute("CustomerID").getValue();

    Here you first declare a variable (var lookupItem), which is about to store real CustomerID's.
    Those will be placed in an array (sort of row of values), called "lookupItem".
    The whole point here is that you see how "Xrm.Page.getAttribute("CustomerID").getValue()" is used.

    Ok, using "Xrm.Page.getAttribute("CustomerID")" will provide access to the CustomerID, but
    using the method "getValue()" actually retrieves the data.

    As another example:

    var firstName=Xrm.Page.getAttribute("firstname").getValue();

    The above also demonstrates the getValue() method.
    The "setValue()" method ofcourse "sets" or assigns a value to an attribute, like some
    field in a database table (an entity).

    We need to illustrate that as well. Here is an example. Suppose the Order table
    has the numberordered, price, and totalprice columns. Suppose the first two are known.
    Then we can construct the "totalprice", like so:

    var numberOrdered=Xrm.Page.getAttribute("numberordered").getValue();
    var itemPrice=Xrm.Page.getAttribute("price").getValue();
    var totalPrice= numberOrdered * itemPrice;
    Xrm.Page.getAttribute("totalprice").setValue(totalPrice);

    (2.2) Xrm.Page.data.entity

    As an example of such a path, take a look at this:

    var InvoiceId = Xrm.Page.data.entity.getId();

    Or as another example of using the "extended path":

    if (Xrm.Page.data.entity.attributes.get("item").getValue() == "bike")
    {
      if (Xrm.Page.data.entity.attributes.get("price").getValue() == null)
        {
        Xrm.Page.data.entity.attributes.get("price").setValue(100);
        Xrm.Page.data.entity.save();
        }
    }

    Note: many folks say that Xrm.Page.getAttribute() is actually a "shortcut" for
    Xrm.Page.data.entity.attributes.get().
    The same is true for Xrm.Page.ui.controls.get() and it's shortcut version Xrm.Page.getControl().

    3.7 A few words on iFrames, JQuery, Ajax, REST, oData and stuff.

    1. What is an iFrame?:

    An iframe is used to display, sort of, a web page within a web page. Like an advertisement
    within your page, or used as an "area" from another source.

    -Within pure HTML, you may use the "iframe" tags to define the other source.

    -With JScript, you might use code which resembles something like listed below.
    However, I often have difficulties in using "specials" in JScript. But something like
    sketched below, should provide a pointer in how to approach this.

    if (Xrm.Page.ui.getFormType() != CRM_FORM_TYPE_CREATE) //note that != means "not equal".
      {
      //There is no creation, no new invoice, so we must be dealing with a known invoiceid.
      Xrm.Page.getControl("IFRAME_ListingInvoices"). //continue the statement below.
      setSrc('https://antapex.org/administration/overview_invoice.aspx?id=' + Xrm.Page.data.entity.getId());
    }

    Note that with an iFrame, you can have a sort of "independent" piece of information
    (autonomous) on your main page. But it could also be a listing of articles, or invoices etc..

    2. What is JQuery (within JScript for CRM)?:

    It seems that Microsoft does not recommend using jQuery in form scripts and ribbon commands.
    But, for accessing/manipulation in HTML resources, it is fine.

    The upper statement "seems" indeed true. This almost seems to suggest to abandon JQuery
    with CRM Form programming. But it's very good to use it with HTML and such webresources.

    So, it's OK with HTML webresources, but not with a Form and it associated JScripts.

    Wait a bit, it's too soon for conclusions. Even with more recent versions of CRM,
    form programming with JScript, and JQuery, and Ajax, may produces good results.
    (We have to wait a bit, until more theory has been covered in the next sections.)

    I do not want to put you on the wrong legs, but MS always says that with Jscript development
    with "Forms", JQuery is not supported.


    I have seen JQuery (associated with forms) to work in CRM 2011/2013, and 2015.
    However, it almost "seems" (?) as if 2015 Update 1, had a large impact on the fact
    whether JQuery was still usable in Form scripts.
    Indeed, quite a bit of code, like DOM based, and JQuery, seems not to work anymore
    as of CRM 2015 Update 1.
    It's likely to do with the "new form rendering", as of 2015 Update 1.
    But, there exists code in JScript, using JQuery, which "works" when doing Form programming,
    so please do not consider this issue from a strickt black/white perspective.

    Note: in CRM 2015/2016 you might always try "Legacy Form Rendering". See one of the appendices
    for more information. Ofcourse "Legacy Form Rendering" is a step backwards, but if it helps
    to get code running again, it might be worth it.

    Whether we use it, or not, what is JQuery anyway?

    - What is JQuery?:

    JQuery is a javascript library. The whole idea behind it, is that for many tasks,
    it already has code available (in that library), that acts as a "wrapper" for
    more elaborate javascript code. So, you simply "call" the wrapper functions in your code,
    to make life a bit easier.

    The "Query" part in the name, may have put you on the wrong legs, by thinking that it was especially
    for database access.

    -A main objective for JQuery is that it might help to minimise efforts in selecting (query)
    HTML/DOM/CSS elements and perform all sorts of "actions" on these elemenrs.

    -Another main objective, is that you can use it for AJAX, asynchronous routines, that
    update element(s) on your webbased form, without needing a full refresh.

    You thus might say that JQuery is not a programming language, but rather a toolbox which makes JavaScript
    easier to use for accessing all sorts of objects, since that code is already in the library.
    But "to put JQuery to work", needs a special syntax, so, in that respect, it's looks like programming again.
    Or, maybe better, in your code, you need to use the syntax for the JQuery API, before it can do useful work.
    Thus is it actually programming? Yes, I think.

    There are slight differences in the usage (syntax) when comparing the Web World (HTML/DOM/CSS), and JScript
    for use in CRM.

    - To register it for use in your Form JScript code:

    - download the latest prod version (or recent version), like "jquery-3.1.1.min.js"
    - Open your Solution or open the Default Solution, and upload the library, and publish it.
    To use it:
    - Go to form properties, en register it in the form, just like an ordinary Jscript.
    - Now it's ready for use, in your JScripts, associated with that Form.

    Before you publish anything, or a Solution, make sure you understand that process,
    because e.g. the difference between "managed" and "unmanaged" solutions are important to understand.

    - A JQuery example in JScript (or javascript, actually):

    jQuery is called with the $(selector).action() syntax.
    The "selector" identifies the object or class, and "action" is indeed the function or method
    which we want to execute.

    In HTML, or webresource, you might have the statement $("#test").hide() which makes the object
    identified by "test", invisible. Note that if it is an object, you need the "#" symbol, to prefix the ID.

    It is good use, to start the JQuery code by $(document).ready which makes sure (more so if we deal with HTML),
    that the document is fully loaded, before JQuery starts. So, here we have an example:

    $(document).ready(function ()
    {
      $('#TimeSheetButton').hide();
    });

    You can use such code, anywhere in your JScript. As long as you understand, it is not supported.
    It's likely not to work anyway in JScript, but in 2015/2016 you can try "Legacy Form Rendering" (see appendices).

    3. What is AJAX (within JScript using JQuery, for CRM)?:

    The nice feature of AJAX is, that it allows for asynchrounsly retrieving data, and updating just parts of a web page,
    or a part of a Form. So, the page does not need to be fully refreshed.
    AJAX is short for "Asynchronous JavaScript and XML".

    It's a technique, that at it's core uses the raw XMLHttpRequest. You may call Ajax a protocol, or technique, or something,
    but you need to use it within an environment like Javascript (Web, DOM), or JScript (Xrm.Page, CRM).

    In most cases, the Ajax protocol runs in your Browser, and get's data from a Server. The exchange of data,
    goes using the JSON or XML representation of data (the application data is "packaged", or formatted, according
    to the JSON or XML standards).

    As said before, you can use Ajax in Javascript, or Jscript, and many other platforms.

    If you use JScript, then JQuery provides the library function. So indeed, it's a part of JQuery.
    It's in effect (per default) an asynchronous HTTP (Ajax) request.

    In it's most condensed form, it looks like:

    $.ajax(url[, options])   //Call to Ajax routine from JQuery.

    Where "url" specifies the Server application, and [,options] consists of a series of options like for example
    the formatting of the data (like JSON, XML) etc..

    - An example (partial) Ajax call from JScript (using JQuery):

    $.ajax({
      type: "GET",
      async: false,
      contentType: "application/json; charset=utf-8",
      datatype: "json",
      url: oDataSelect,
      beforeSend: function (XMLHttpRequest)
    ...more options are needed here..., just mentioned a few basic ones...

    Note that in this example, the async option is put to "false", so in this case we want a synchroneous request,
    the formatting is "json", and the Server app is oDataSelect, which may seem as a strange url.
    However, in this case, it is the designation of an endpoint to a webservice, like CRM's internal "OrganizationData.svc".

    However, we know that JQuery is not supported in Form programming. Since Ajax is part of the library,
    it seems to follow that Ajax is not supported too, in Form programming using JScript.
    It's indeed somewhat confusing, considering the whole lot of options. But....:

    However, the use of Ajax and the oData service endpoint, works. Is sounds strange maybe, but
    it flows without errors, as I have seen in a few occasions in CRM 2015/2016/365.

    A nice illustration of JQuery and Ajax, is the following article:

    query dynamics 365 using Jquery+Ajax (carldesouza.com)

    4. Some other noteworthy subjects, like REST, JSON, oData etc..:

    SOAP:

    SOAP (Simple Object Access Protocol) is a protocol used to "envelope" XML data, which resulting format then can
    be send to a destination, using a high-level protocol as "http".
    It's indeed highly oriented on XML data, that is, the "envelope" with metadata, and the actual data,
    is structured in XML.

    SOAP nowadays is considered to be somewhat less usable compared to it's modern "rival", namely REST.

    It's not only a protocol to envelope data. It indeed enables a high-level message exchange, and passing,
    but it's also used at registering of services, and calling methods (functions) of webservices.
    But also the last few parts of the above sentence, can be seen as part of "message exchange".

    So, it's having a specific, strict, protocol and can be used for transferring messages (usually data,
    but might also be a payload as a Remote procedure call.

    Below you can find a simplyfied example of a data message:

    <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
    <env:Header>
    (some header stuff... Optional, might contain header blocks for intermediate nodes.)
    </env:Header>
    <env:Body>
      <p:itinerary xmlns:p="http://antapex.org/reservations">
      <p:article>Racing Bike</p:article>
      <p:numberof>5</p:numberof>
      <p:totalprice>5000</p:totalprice>
      </p:itinerary>
    </env:Body>
    </env:Envelope>

    While the text above, said something about the "format", (web)services also expose a SOAP API
    with a structured methodology, which client apps must use.

    REST:

    Here too, we may speak of the REST API, that is, how clients and server services
    are suppose to connect, and exchange messages.
    Ofcourse, just as with SOAP, we have rules on how formatting of data takes place.

    REST is an architecture that "de facto" is associated with webservices (like SOAP is too).
    Then we might as well say, that it is also often tied to HTTP, and in that case GET and POST
    (and other) methods are in use.
    So, HTTP is the most often transfer protocol.

    REST is thus about accessing webservices, and as a part of that, exchange of messages.
    Those message formats can be various, like an XML format, but absolutely most often in the JSON format.
    Since JSON format is so common, we will see about that in the next section.

    As with SOAP, and REST too, clients and Servers only need to adhere to the protocol (follow
    the corresponding rules), and the exchange of data is Universal, that is, the same everywhere.

    In weblanguage, it is also often said that the client uses the REST webservice's "endpoint".

    In a REST request, one identifier is the URI. Both URL and URI, are often heard terms.

    URI - Uniform Resource Identifier (URI) to identify the true resource on a server.
    URL - Uniform Resource Locator (URL) to identify the "location".

    The two are really quite close, but there is a difference. The URI should identify
    the service by it's name, or path, or possibly via "query" (or anything else that identifies the Instance).
    However, the terms are often used interchanginly.

    For example, one of the CRM URI's (for 2011/2013/2015/2016) could be:

    https://antapex.org/ICTSolutions/XRMServices/2011/Organization.svc

    CRM uses the "RESTful" API, using HTTP methods, and JSON format for messages requests/returns.

    If you would need to "build the whole REST stuff", then you would be involved in:
    define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats,
    how to address such media types, all posible formats, checks etc..., query options, etc.. etc..
    That's why a builder, or tool, can be put to use, which greatly simplyfies your code.

    For CRM, "oData" is heavily used. In such case, you only need to locate the service (URI),
    and specify a number of options (what you want to get done) in your JScript code.

    JSON:

    JSON is short for JavaScript Object Notation.
    It's a format for data, exchanged between clients and webservices.
    It can be viewed as an alternative for XML formatting.

    For example, the REST Api uses JSON messages.

    Ofcourse, the envelope and inner structure should be created according to the JSON specs.

    The main structure, looks like a "stack" of "key:value" pairs (or also often typed as
    "attribute:value" pairs), just like any "record" would show you.
    Such a "stack" of pairs, sits between "{" and "}" symbols. If an array is an element too,
    then it's values are between square brackets "[" and "]".

    Not only data might be the constituents, but function calls are possible too, making
    such message a JSON-RPC (remote procedure call) message.Mbr>
    Just for illustrational purposes, a simple example is shown below:

    {
      "$schema": "http://json-schema.org/schema#",
      "name": "Carla",
      "city": "Amsterdam",
      "sports": ["skating", "karate", "rugby"]
    }

    Attaching to a WebService like CRM:

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

    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)

    CRM:

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


    Appendices:

    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. 6: 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:

    https://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2017/11/14/how-to-globally-define-error-reporting-preferences-in-microsoft-dynamics-crm-2016

    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:

    https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2013/developers-guide/gg328182(v=crm.6)

    CRM 2015/2016:

    https://docs.microsoft.com/nl-nl/previous-versions/dynamicscrm-2016/developers-guide/gg328182(v=crm.8)

    CRM 365:

    https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/org-service/web-service-error-codes

    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. 7: Setup Legacy Form Rendering (the 2013/2011 model) in CRM 2015/2016:




    6. Rami's CRM 2013 API cheatsheet:

    It's really nice work, the following pdf's, which summarizes the Xrm.Page namespaces, objects,
    and methods.
    Please see the docs by Rami Mounla:

    Rami Mounla's summary of the CRM 2013 API


    7. A few pointers for Replacing Javascript DOM objects/methods
    to MS JScript XRM/Page objects/methods or D365 ExecutionContext methods.

    First, use a capital letter where required in any object-, or method-, or property name.
    That is for example, do not use "getelementbyid()", but instead use "getElementByID()".
    Maybe it sounds silly, but it helps.

    Following is a short list of incompatible DOM statements (or objects/methods) which
    will not work anymore as of CRM2015 Update 1.
    Maybe the suggestions in the right column of the table, can be helpful.

    DOM XRM or D365 ExecutionContext
    document.getElementById() parent.document.getElementById()
    or window.parent.document.getElementById()

    Remark: this is still DOM, and only "more qualified", or
    a call to the "parent" object (which might help).
    However, it's likely not going to work for versions above CRM 2015 Update 1.
    See the paragraph "more on document.getElementById()" below.

    Microsoft Dynamics has "disabled" this for > 2015 Update 1,
    meaning document.getElementById (and implmentations of it in jQuery)
    does not provide access to the "DOM element" in Forms (but in Web/HTML: yes).

    Use implementations of:
    Xrm.Page.getControl().appropriate_method()
    Xrm.Page.getAttribute().appropriate_method()
    context.getServerUrl Xrm.Page.context.getClientUrl()
    disableViewPicker Xrm.Page.ui.controls.get("").setDisabled(true)
    crmForm.FormType() Xrm.Page.ui.getFormType()
    control.attachEvent("onclick" , CallFunction ) formContext.getAttribute(arg).addOnChange(myFunction)
    padding no simple equivalent statement: fully rewrite (I think)
    field.style.fontStyle no simple equivalent statement: Amazingly, sometimes this produces an error in XRM.Page
    if(Xrm.Page.getAttribute("parentaccountid").getValue() != null) if(formContext.getAttribute("parentaccountid").getValue() != null) for D365 later versions

    More on the Javascript method (window.parent.document.)getElementById().

    This one in particular, can be very nasty in Upgrades from CRM 2011/2013 to CRM 2015/2016/365.
    What exactly is it in Javascript? It provides a "handle" to the object referred to
    in this function.

    Let's study it in some detail:

    How it is used in HTML DOM:

    At www.w3schools.com, you can find an example like shown in the figure below.

    Go to www.w3schools.com (https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_document_getelementbyid2):
    Go to that place, and try the button and see what happens. An explanation is given below.

    Fig. 8: HTML code plus the javascript method getElementById() :




    In the code above, you see that the paragraph (between the "p" and "/p" tags), is assigned
    the ID (or name) "demo", in that HTML document.
    From that moment on, in the DOM model, we can refer to that object with it's ID, namely "demo".

    Between the script and "/script" tags, we see the javascript code. As usual, it's a function.
    You can see that a variable "var x" is assigned with "document.getElementById("demo")", and that's
    exactly equal to the string in that paragraph: "Click the button to change the color of this paragraph.".

    The button control, when clicked, will call the function, and as a result the text will turn red,
    since the statement "x.style.color = "red"" will see to it, that the property "x.style.color = "black"
    will change into the property "red".

    As another illustration: you could also avoid the button, and simply used the statement "document.write(x);",
    which would print the string on your screen.

    This is a very simple, and adequate example of how getElementById("TheID_of_the_object"),
    is applied in HTML DOM.

    It's very useful, but it's a DOM method, and not Xrm.Page. It never was Xrm.Page.
    That it still worked in CRM 2013, is that MS not entirely killed it, in 2013 and earlier versions,
    and kept javascript code compatible in JScript. But in my

    How it is used in JScript (earlier versions and 2011/2013):

    Here are a few typical examples (I think):

    // 1. Get through a listing by using "getElementsByTagName("SomeInput")";

    var all = document.getElementsByTagName("SomeInput");
    var Element;

    for (var i = 0; i < all.length; i++)
    {
      Element = all[i];   //other statements
    }

    // 2. Get the handle to the object (field) identified by "to".
    parent.document.getElementById("to").setAttribute("defaulttype", "2");

    It seems that the code in (2) can be replaced by "Xrm.Page.getControl("to")".

    // 3. Get a handle to "customerid"
    parent.document.getElementById('customerid').title = 'This field is Inactive.'

    // 4. Get a value.
    var discountpercentage = parent.document.getElementById('discountpercentage');
    msgNotation = parent.document.getElementById('new_name').title;

    It seems that the code in (4) can be replaced by "Xrm.Page.getAttribute("discountamount").getValue()".

    Well, at least, we now have a reasonably good idea on what "getElementId()" is about.

    8. How to enable Tracing in CRM 2013/2015/2016/365 On Premises.

    1. Basic Tracing: App Server components

    On the CRM App Server:

    1. Create or reserve a suitable trace location (directory), like "C:\CRMtrace" or "F:\CRMtrace".
    2. Start "regedit".
    3. Navigate to:

    HKLM\Software\Microsoft\MSCRM

    -Add Key: TraceEnabled DWORD value:1
    -Add Key: TraceDirectory STRING value: C:\CRMTrace (or what you selected in step 1.).

    This type of tracing focusess on CRM services and webservices, and not as much on custom code.
    Tracing will slightly impact performance, and over time, consume diskspace, unless you clear out older logs.

    In certain cases, the above "seems" to be ignored. It can be worth while, if needed,
    to take a look in "Drive:\Program Files\Microsoft Dynamics CRM\Trace", if there a recent trace file
    would be present. Ofcourse "Drive" is the partition where you have installed CRM, like "C:" or "D:" etc..

    2. A way to trace PlugIns from within CRM:

    The PlugIn Trace facility as of 2015 Update 1, and later:
    Please see:

    1. Article at powerobjects.com (2016)
    2. Article at magnetismsolutions.com (2015))

    3. Basic Tracing: Audit table in SQL Server.

    Per default, a level of auditing is applied into a SQL Server table.
    In the "Organization_MSCRM" database, we have the table "AuditBase" which might
    give some additional information. However, it is focussed on "auditing".

    4. General code tracing, debugging:

    Preferably, you should perform any development using Visual Studio. It's a bit trivial to say ofcourse,
    but VS gives you pointers for tracing/debugging.

    5. JScript debugging:

    One way to debug JScripts, is placing the "debugger;" statement within your JScript code.
    As from that point, debugging begins.
    Since CRM is webbased, and Javascripts are download to your workstation, the debugging info
    can be traced from your browser, often activated by the F12 key.

    So, in your JScript, you would change it like in this example:

    function abc()
    {
    //statements

    debugger;

    //statements
    }