Wednesday, 25 December 2019

How to add a TinyMCE editor for description fields in Dynamics 365

Microsoft Dynamics CRM, although has support for various kinds of fields to be placed on its forms, it does not provide a rich text editor natively. There are several use cases where a rich text editor would be very useful. One such case is when content from CRM needs to be displayed on web pages.

TinyMCE is an awesome HTML editor freely available and extensively used in web applications. So, why not use that and embed in a CRM form? you will have the ability to include the editor on any form for any entity and it will allow our users to add some proper formatting and some extra goodies such as tables and source code without issue.

OOB Email Editor:



TinyMCE Email Editor:






Solution

Getting an API Key for TinyMCE

First step is, we need an API Key which is provided for free by TinyMCE Go to the link below and ‘Sign up for a free API key’ and sign up as required.


It will ask you for the domain, be sure to enter the primary domain your CRM instance uses. For cloud implementations of CRM this will be along the lines of *company*.crm.dynamics.com
Copy and API Key and save it in notepad.

Adding TinyMCE to Dynamics 365 Form

First, we need to create a Web Resource(.html) file as image below.


2. Now copy the code into the above resource and replace the *APIKEY* placeholder on line 15 with your own API Key which we have obtained from the previous step..
<html><head>
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js"></script>
<meta charset="utf-8">
<title>Email Editor</title>
<script>
$.ajaxSetup({
cache: true
});
function updateEmailForm() {
window.parent.Xrm.Page.getAttribute("description").setValue(tinymce.get("editbox").getContent());
}

$(document).ready(function() {
var emailBody = parent.Xrm.Page.getAttribute("description").getValue();
var tinymcesource = 'https://cloud.tinymce.com/stable/tinymce.min.js?apiKey=*APIKEY*'
if (typeof tinymce == "undefined") {
$.getScript(tinymcesource, function() {
window.tinymce.dom.Event.domLoaded = true;
tinymce.init({
selector: 'textarea#editbox',
init_instance_callback: function (editor) {
editor.on('NodeChange', function (e) {
updateEmailForm();
});
},
plugins: [
'advlist autolink lists link image charmap print preview anchor',
'searchreplace visualblocks code fullscreen',
'insertdatetime media table contextmenu paste'
],
toolbar: 'undo redo | styleselect | bold italic | alignleft aligncenter alignright alignjustify | bullist numlist outdent indent | link image preview'
});
});
$('#editbox').html(emailBody);
}
});
</script>
<meta></head>
<body style="margin:0px 0px 0px 0px;">
<div id="editdiv">
<textarea id="editbox" style="width: 800px; height: 240px;; "></textarea>
</div>
</body></html>
REPORT THIS A
3. Now go to the email form customization window, select the ‘INSERT’ tab at the top left then click ‘Web Resource’ on the right-hand side.

4. You should now be seeing a dialogue window with several required fields. Type the web resource name and Select the .html file you saved earlier in the above step.



5. Now you will be seeing the ‘Web Resource Properties’ window and fill in the Name and label like the image below.



6. Click Ok. And then now the new Web Resource will appear on the form.

7. Now double-clock the newly created web resource and navigate to the formatting tab and change the ‘Number of Rows’ to be from 6 to 15.

8. Click Save and then Publish the CRM Form

Now refresh the email form you will see be something similar to the image below.


Monday, 23 December 2019

How To Disable Unified Interface in Dynamics 365

All current version Microsoft Dynamics 365 trials and environments are defaulted to the “Unified Interface Only” setting.  This is a good thing since Microsoft Dynamics 365 Unified Interface is here to stay and the previous “Legacy Web Client” interface is deprecated as of September 2019. 
image
For certain situations where we need to run “Legacy Web Client” such as for testing existing setups – how do we enable our “Legacy Web Client” interface?
Firstly – the setting “Use Unified Interface only” is no longer listed under the Dynamics 365 Client’s Advanced Settings >> Administration >> System Settings >> General area
image
So where did it go?
The “Use Unified Interface only” setting is now found in the Power Platform Admin center!
Here are the steps to navigate to this setting:
Open Power Platform Admin center >> click Environments >> select the Dynamics 365 environment >> click the Settings button >> click the Behavior setting >> disable or enable the “Use Unified Interface only” setting
image
image
image

Wednesday, 11 December 2019

How to Filter Lookup Fields in Microsoft Dynamics 365 CRM

In Dynamics 365, we can filter lookup fields without writing code. In this post, we will look at an out of the box field example and a custom example.
The common out of the box example is filtering a contact based on an account. If we create a new Opportunity, we can see if we look at the Contacts field, we see all contacts in the system:
And the same with Accounts:
If we were to select an Account or a Contact, it won’t filter the corresponding field. E.g. if we selected 3M as the account, it would be useful if the system only showed us contacts for 3M, but this is not the case. Likewise, selecting a contact that belongs to A Datum Corporation does not filter the account to A Datum Corporation.
In order to achieve this, we can use the Related Records Filtering property on the Contact field. Open the form in design view, and select the Contact field, then click Change Properties:
You will see Related Records Filtering:
Click the checkbox, and select to only show records where Account (Opportunities) Contains Accounts (Primary Contact).
Note you may see multiple occurrences of Account (Opportunities), as there are multiple relationships defined between Accounts and Contacts. You will need to select the right one that contains Accounts (Primary Contact):
It should then look like below:
Now, create a new opportunity, and select an Account:
Now use the drop down to select a contact. You will see the contacts have been filtered to only show the primary contact for this account, as selected on the account record:
Note the related records filtering is based on the relationships. In the above example, we can see the following options:
  • Accounts (Contacts)
  • Accounts (Created by Portal Contact)
  • Accounts (Primary Contact)
  • Company Name (Accounts) (Contacts)
  • Managing Partner (Managed Contacts)
These are based on the Account-Contact relationships.
If we look at the 1:N relationships for Accounts, we can see the following for Contacts:
If we look at the N:1 relationships for Accounts, we can see the following for Contacts:
Now for the custom example. Let’s say we have 2 custom entities, Country and City. We would like to filter the city based on the country selected.
Our Countries list looks like:
We will add a lookup field to the City entity called Country:
This will create a N:1 relationship:
Our cities now look like this, with the associated country filled in:
Now on the Account form, add the 2 new fields, save and publish. If we were to select a country and then a city, we would not yet get the filter:
The final step is to add the Related Record Filter on the City field on the Accounts form:
Now, when we select a country on the Account form, it will be filtered to only show cities relating to that country:


Other Usefull Links
 Dynamics 365: Lookup Field Filtering / FILTERING LOOKUP FIELDS IN DYNAMICS 365

How to disable Auto-Save in Dynamics 365 for Specfic form

How to disable auto-save for a form

If you wish to disable auto-save for specific entity forms, you can do this by adding code to the OnSave event in the entity form.
1. Create a JavaScript web resource and add it to the form
  • Enter the following information in the web resource form:
    • Name: preventAutoSave
    • Display Name: Prevent Auto Save
    • Type: Script (JScript)
  • Next to the Type field, choose Text Editor.
  • In the Source field, paste the following code (see code box below to copy):
auto-save
function preventAutoSave(econtext) {
    var eventArgs = econtext.getEventArgs();
    if (eventArgs.getSaveMode() == 70 || 
eventArgs.getSaveMode() == 2) {
        eventArgs.preventDefault();
    }
}
  • Add the web resource to the Form
2. Configure the OnSave event
  • In the Form Properties window, in the Event Handlers section, set Event to OnSave.
  • Enter the following in the Handler Properties:
    • Type ‘preventAutoSave’ in the Function field. This is case sensitive. Do not include quotation marks.
    • Make sure that Enabled is checked.
    • Check Pass execution context as first parameter.
  • If there are any other event handlers for the OnSave event, use the green arrows to move this one to the top
Auto-save will now be disabled for the form, but data can still be saved by clicking the Auto save button in the lower-right corner. If users attempt to navigate away from a form or close a form where data has been changed, they will get a prompt to save their changes before they can navigate away or close the form.

Friday, 9 August 2019

Filtering attributes in dynamics 365 plugin

Dynamics 365 view error: To use this saved view, you must remove criteria and columns that refer to deleted or non-searchable items

Tip #747: If your view is broken

Closed binocularsIf you followed our yesterday’s tip and tried to set up a workflow automatically adding a user to a team, you may have seen the error message: “To use this saved view, you must remove criteria and columns that refer to deleted or non-searchable items.”
Broken view message
The fix is fairly straightforward: find the lookup view in customizations, remove the offending column and add back the proper one (Name).
Broken view
If you think that it will never happen to your views then wait until someone pulls out Xrmtoolbox and uses View Replicator to create a view referring to non-existing attributes.

Sunday, 28 July 2019

Solutions in Dynamics 365

A solution is a bucket where all the customization components of a particular project are stored. Creating a solution helps in moving these components from one environment to another. There are three different types of solutions: default, managed and unmanaged.
  • Default Solution. The out-of-the-box Microsoft Dynamics CRM software as well as the pre-deployment customizations are part of the default solution. You can access a default solution by navigating to SettingsCustomizations, and Customize the system:solutions img1
  • Unmanaged Solution. The beginning state of solution is the unmanaged solution state. During this phase, you can add, edit, update, remove, delete, and test any of the components of the solution. You also have the ability to create restrictions on the components within the solution. Any number of these unmanaged customized solution components can be associated with any number of unmanaged solutions.
  • Managed Solution. A managed solution is a finalized solution that can be distributed and installed. They are created by exporting an unmanaged solution by setting restrictions to prevent any further customizations. They are installed in addition to the system solution. They can also be layered on top of other managed solutions as well. The unrestricted components of the solution are still customizable.

Solution Components

(http://msdn.microsoft.com/en-us/library/gg334576.aspx)

Schema:

  • Entities
  • Attributes
  • Relationships
  • Global Option Sets

Analytics:

  • Dashboards
  • Reports
  • Visualizations

User Interface:

  • Application Ribbon
  • SiteMap
  • Forms
  • Entity Ribbons
  • Web Resources

Process/Code:

  • Processes – Dialogs and Workflows
  • Plug-ins – Assemblies and Processing Steps

Templates:

  • Mail-merge
  • E-mail
  • Contract
  • Article

Security:

  • Security Roles
  • Field Level Security Profiles

Microsoft Dynamics 365 CRM Troubleshooting Solution Import Errors

Remember when CRM life was so much simpler that solutions did not yet exist? If you had separate development and production environments and you wanted to move your customizations, you simply clicked Export Customizations and voila! It was done. Those were the days.
Nostalgia Warning – in case you’ve forgotten, here’s a screenshot to jog your memory:
With CRM 2011, the concept of solutions was introduced, giving us a new set of powers – by picking individual entities, workflows, etc., we now had the ability to group together and move only those customizations we wanted to include in our solution. The next great solutions advancement came with CRM 2016: we can now select specific components within each individual entity – so instead of moving the entire contact entity, for example, we have the option of moving only a certain view or field within the entity. And we can do this without having to hack the xml in the zip file.
(By the way, if you want to learn more about solutions, please have a look at our CRM Book: https://crmbook.powerobjects.com/system-administration/customization/solutions/)
But as wonderfully advanced as the CRM solutions concept is, it also has the potential to cause some serious headaches – failed imports, error messages, etc. – when certain things are even slightly amiss. With that in mind, in today’s blog, we will try to ease those headaches by providing you a what-to-do guide for when things don’t go so smoothly. We hope this helps ensure that you will always be able to successfully import your solution into an environment.
But hey, one quick warning: while we strived to make this guide as helpful as possible, dealing with CRM solution import issues can sometimes become quite time-consuming, especially when it requires you to look at XML code. We’ll try our best to guide everyone in this blog, but if you ever feel like you’re in over your head, please contact us – we’re here to help!

Dependency Issues caused by Managed Solutions

The solution import process is quite simple. Under “Settings” / “Solutions,” click Import, as shown below.
Select the zip file of your Solution, and click Import. At this point, Microsoft Dynamics will calculate the solution.xml file and check that all dependent components are included for the import process. If a missing dependency is found, the next screen will display a dependency error, and you will not be able to import your solution until the missing components are addressed.
Often, if you are importing a solution that came from a different CRM org, a dependency error is caused by a Managed Solution that exists in the source CRM but not in the target. For example, let’s say you have two environments: development (dev) and production (prod). You create a solution in dev called “Email,” add the email entity, and export it. But when you try to import it in prod, you receive the following error during the dependency check:
At first glance, it may seem daunting to fix a laundry list of dependency errors for a successful import. However, when we take a closer look at the “Managed Solution” column, we see that all the error rows indicate either PowerEmail or PowerSurveyPlus. In this example, it’s because both PowerEmail and PowerSurveyPlus are Managed Solutions that exist in dev but not in prod. To resolve this issue, we need to simply import both PowerEmail and PowerSurveyPlus into prod before importing our “Email” Solution.
So, as far as Managed Solution components go, always remember that they cannot be exported via an Unmanaged Solution. And to export from one CRM org or environment into another, we always recommend that the same Managed Solutions that exist in your source also exist in your target.

Other Dependency Issues

Looking at the same example above, let’s say we imported both necessary PowerPacks into our prod environment and then tried to import the “Email” Solution one more time. Again we failed the dependency check, though this time, the error screen contains just one item:
What does this mean? Here, we begin by looking at the last column, “Required by,” which is formatted as follows: “Component (Entity).” In our example, it’s telling us that the “Email” component within the email entity requires a component that does not exist. Next, we look at the “Type” field – since it is Web Resource, we can deduce that the “E-mail” refers to our form called E-mail, which contains a reference to a web resource called new_email_js_lib (from the “Name/Id” field) that has not been included in our solution.
To successfully import this solution, we will need to add the web resource mentioned in the error screen (new_email_js_lib), export it again, and then try another import.
There are lots of other types of dependency errors that could occur when you don’t include the necessary components in the solutions, including:
  • A field that uses a global option set.
  • A system view that references newly-added fields.
  • Forms that contains newly-added fields.
  • A form that contains a non-existent quick view form.
  • A site map that contains newly-added components.
  • Forms or Business Process Flows that include missing security roles.
Thankfully, the message displayed is usually very helpful in telling us what is missing, as well as why it is needed. Back to the E-mail example above: we fixed our problem by including the missing web resource. But what would be another way for us to import the solution if we didn’t want to move that web resource? Well, since the only dependency in our example is required by the E-mail form, we can simply exclude that form from the solution.

Invalid XML

Another error you may receive after selecting the zip file of your solution and clicking Import is: “This solution package cannot be imported because it contains invalid XML.”
The most likely reason for this error is that someone previously edited the customization.xml file incorrectly, resulting in bad XML code. Often, it is as simple as an error in the capitalization of an identifier, a basic typo, or having a missing or invalid tag. To find out where the error is, look at the error screen and hover your mouse over “Technical Details.” This is actually a link that takes you to a page showing more detailed information. Clicking on the link will reveal something similar to this:
In this example, we have a typo when specifying our cascade relationships: “NoCas1cade.” This is the result of someone manually editing an XML file and mistyping something. This can be easily corrected by opening the customization.xml file within the zip file (covered below), searching for the typo, and correcting it. Of course, not all fixes are as easily identifiable as this example.

The Log File

Note: inside the solution zip file, there exist several files. One is “solution.xml,” which contains a list of dependencies required before the import can be attempted. However, this file isn’t foolproof, as there is still a possibility that a dependency is missing but is not listed in the solution.xml file. When this is the case, it results in the initial dependency check succeeding, allowing you to attempt to import the file. However, it will then fail the import, and an error log will be generated.
Besides dependencies, additional errors can occur during an import. When you first select your zip file and click Import, a progress indicator will appear. In the event of an error, the changes included in the solution file to that progress point will not be applied, and you will have the option to download the log file.
Click on Download Log File, which will result in an XML file – be sure to open it in Microsoft Excel.
WARNING! Any time you deal with XML (or any other code, for that matter), always tread carefully and always make a backup copy before doing any edits. Simply right-click the zip file and copy it. That way, you will have a backup ready to be re-imported if any problems arise during your editing process.
The Excel file will contain two tabs. The first tab, called Solution, will contain some basic information:
The second tab, called Components, will contain detailed information about each individual item being processed for import. 
This is what we will use to identify issues and determine necessary fixes. The “Status” column will list the components successfully processed before the error occurred. Subsequent components after the failure will remain unprocessed, since the first failure causes CRM to stop processing. In this way, it is easy to identify the source of the error, though there is also a downside: there may still be more issues, but we can only catch one at a time.
Our troubleshooting process will involve looking at the “ErrorCode” column. Based on the message from the screenshot above, the message received in our example is:
“An item with the same key has already been added.”
Some of the error codes are straightforward and to the point, while others require more digging. And on occasion, you will need to make edits to the XML files inside the zip file. Don’t worry: you don’t necessarily need to be an XML expert to work through some of these issues, though for a non-developer, simply looking at code can often be challenging work. However, if you are a CRM administrator, once you get the hang of looking at CRM XML, it will become increasingly familiar each subsequent time. Oh, and one quick and super-important tip: remember that XML is always case-sensitive!
Let’s have a look at different error codes you can receive in this log file, beginning with the example above.

An item with the same key has already been added.

Stated simply, with this error CRM is telling you that you’re trying to create an item that already exists. Unfortunately, this is one of the more generic error messages, so it isn’t always super helpful. However, the good news is that often, this happens for one of two reasons: the field already exists in CRM but is a different type, or it is the same type but the schema is capitalized differently. Let’s look at two examples that show how each issue can happen.
Example 1: there exists a field (type = text) in your contact entity called “new_ShoeSize.” You then attempt to import a solution that includes a field (type = whole number) with the exact name, “new_ShoeSize.” CRM will attempt to create a new field, but will error out because this name – or key, as referenced in the error code – is already taken.
Example 2: let’s say you have the same text field, “new_ShoeSize,” and this time you are importing a solution where the field is also of type text, but the schema of that field is all lower case: “new_shoesize.” This will result in the same error occurring. CRM will recognize that you have a new field called “new_shoesize,” but when it tries to create it, it will find that the name already exists.
Something to keep in mind is that similar types of problems may ultimately result in different ErrorCode readings. For example, capitalization differences in the schema (as described in Example 2 above) may, depending on your CRM version among other things, actually result in different error codes! Argh, right? Well, we hope to cover all of them in this guide. Remember that as long as you are able to start with an error code – any error code, you can usually identify your problem and possible fix.

The ‘XX’ attribute is not declared.

This error message refers to something in the customizations.xml file that CRM does not recognize as valid. For example, an import could error out with the message, “The ‘Label’ attribute is not declared,” followed by “validation failed at …” and then a sample of the XML file where the error occurs.
This means that when the solution file was created, something CRM can’t process (an undeclared variable) was inadvertently included. To fix it, we will need to examine the customization.xml file to remove the offending part of code. Let’s say you downloaded the log file and saw this message:
The import file is invalid. XSD validation failed with the following error: ‘The ‘label’ attribute is not declared.’. The validation failed at: ‘…ition></filter></filter></filter><attribute name=”scheduledend” /></link-entity><attribute name=”po_duedate” /><attribute name=”objectid” /></entity></fetch></fetchxml><IntroducedVersion>5.0.0.0</IntroducedVersion><LocalizedNames><LocalizedName description=”(Activities) Available to Work On” languagecode=”1033″ /></LocalizedNames></savedquery><savedquery><isquickfindquery>0</isquickfindquery><isprivate>0</isprivate><isdefault>0</isdefault><returnedtypecode>2029</returnedtypecode><savedqueryid>{3e3ca60a-9732-48bd-b16f-f4682eff6f67}</savedqueryid><queryapi></queryapi><layoutxml><grid name=”queueitems” object=”2029″ jump=”title” select=”1″ icon=”1″ preview=”1″><row name=”queueitem” id=”objectid” multiobjectidfield=”objecttypecode”><cell name=”title” width=”300″ /><cell name=”enteredon” width=”140″ /><cell name=”queueid” width=”150″ /><cell name=”workerid” width=”150″ /><cell name=”casealias.prioritycode” width=”150″ LabelId=”query.7F554701-0D30-413B-8B21-555C58DB2C32.cell.Priority.label” <<<<<ERROR LOCATION>>>>> label=”Priority (Case)” /><cell name=”casealias.po_duedate” width=”100″ disableSorting=”1″ /><cell name=”casealias.responseby” width=”150″ LabelId=”query.487576AC-2E92-4E0E-B29D-AD1028F05A4F.cell.ResponseBy.label” label=”Response By (Case)” /><cell name=”casealias.resolveby” width=”150″ LabelId=”query.8657D594-2737-448E-961C-08A7ABB71AD9.cell.ResolveBy.label” label=”Resolve By (Case)” /><cell name=”casealias.new_bpstage” width=”200″ disableSorting=”1″ /><cell name=”casealias.po_dateofservice” width=”100″ disableSorting=”1″ /><cell name=”queueitemid” ishidden=”1″ width=”100″ /></row></grid></layoutxml><querytype>0</querytype><fetchxml><fetch distinct=”false” mapping=”logical”><entity name=”queueitem”><attribute name=”title” /><attribute name=”enteredon” /><attribute name=”objecttypecode” /><attribute name=”queueid” /><attribute name=”workerid” /><filter type=”and”><condition attribute=”statecode” operator=”eq” value=”0″ /><condition attribute=”objecttypecode” operator=”eq” value=”112″ /…’.”
Look at the error location, which identifies the spot just before the error. Since the error message states that “label” attribute is not declared, we know the error being generated is due to the very next statement:
label” <<<<<ERROR LOCATION>>>>> label=”Priority (Case)” /><cell name
But wait, if it’s bad code, why is it there in the first place? Possibly your CRM was upgraded from a previous version and there is deprecated code, though it could really be for any number of reasons. The bottom line is that we need to remove it:
  1. Extract customizations.xml from the zip file.
  2. Open it with your favorite text editor, such as notepad. 
  3. Search for the error you received. In this example, you would search for label=”Priority (Case)” and then delete it.
  4. Save the file.
  5. Copy it back to the zip file and it will be ready for another import attempt.
Now, don’t get mad, but here’s where it gets even trickier. If you look at the entire error message shown above, you may notice that there are further recurrences of “label=.” Recall that we stated earlier that CRM will fail on the first error and not attempt to process it further, potentially masking additional errors? Well, this is one of those times. In our case, each of the highlighted references will eventually error out during import attempts:
label=”Priority (Case)” /><cell name=”casealias.po_duedate” width=”100″ disableSorting=”1″ /><cell name=”casealias.responseby” width=”150″ LabelId=”query.487576AC-2E92-4E0E-B29D-AD1028F05A4F.cell.ResponseBy.label” label=”Response By (Case)” /><cell name=”casealias.resolveby” width=”150″ LabelId=”query.8657D594-2737-448E-961C-08A7ABB71AD9.cell.ResolveBy.label” label=”Resolve By (Case)” /><cell name=”casealias.new_bpstage” width=”200″ disableSorting=”1″ /><cell name=”casealias.po_dateofservice” width=”100″ disableSorting=”1″ /><cell name=”queueitemid” ishidden=”1″ width=”100″ /></row></grid></layoutxml><querytype>0</querytype><fetchxml><fetch distinct=”false” mapping=”logical”><entity name=”queueitem”><attribute name=”title” /><attribute name=”enteredon” /><attribute name=”objecttypecode” /><attribute name=”queueid”
Further complicating matters is that this error message is only a snippet of the entire customization.xml file, so this error may have several more occurrences, as well. Your options are twofold: fix each error one at a time and try to import after every fix, or review the entire customization.xml file, doing a one-time clean-up of anything that matches the errors shown above. While the second option is definitely faster, please be absolutely certain that you are editing the correct things – don’t inadvertently remove or change something you shouldn’t have! So, if you are still new to this, our recommendation is to do the first method, and just change one piece at a time, until you are sufficiently familiar with solutions content to take a stab at the second option.

Cannot import security role. The role with specified role id is not updatable or role name is not unique.

This message states CRM found a security role name that already exists. You cannot have a duplicate security role name, so if you receive this message, simply find the duplicate security role name(s) that already exist(s) in the target environment.
When you locate the duplicates, if they have different GUIDs (meaning they were created manually in both environments), then you will not be able to import the solution until one of the security roles has been uniquely renamed.

The dependent component XX does not exist.

During the initial import, it is possible that a dependency will not be caught, allowing you to begin the import. If so, you may receive a message similar to the one below:
The dependent component EntityRelationship (Id=po_campaign_po_satisfactionsurvey) does not exist. Failure trying to associate it with SystemForm (Id=5c2404c5-69ed-4633-a193-0852d38f732a) as a dependency. Missing dependency lookup type = PrimaryNameLookup.
To fix this this issue, you will need to examine the error message in more detail. Our example above shows that a relationship is needed for a form that we are importing – likely, it is referenced in the related items, but does not exist in the target system. So, we would just need to add it to our solution if we want the form to be imported.

The label XX already exists. Supply unique labelid values.

There is likely a duplicated ID on the customization.xml file, and we will need to remove it. Let’s say our error message was as follows:
The label ‘Summary’, id: ‘c706accd-f53f-46f5-a254-b64766269216’ already exists. Supply unique labelid values.
We will need to search the customization.xml file for this id, and we will likely see it twice in the same section. However it was created, it will not be possible to import until one of them is removed.
Please exercise caution when removing this, so that you only remove the necessary part. This seems like a good time to reiterate the importance of making a backup copy of your customization.xml file before you begin editing. Please do it!

Transaction (Process ID #) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

This is an infrastructure-related issue, likely the cause of another process acting on CRM that resulted in a conflict – for example, when multiple users attempt an import at once, or when other integrations/backups are running that result in a conflict for back-end resources.
Fortunately, this issue is typically resolved by just trying it again. However, for an on-premises environment, if you receive this message, we recommend checking with a systems administrator first to determine whether there are any other jobs impacting the SQL environment. It may be in your best interest to delay the import until a time where any running jobs have completed, instead of immediately trying the import again.

The import file is invalid. XSD validation failed with the following error:

You will see this error code if the customization.xml file was edited and contains errors. There could be many causes and variations of this error code. Here is one we saw not too long ago:
The import file is invalid. XSD validation failed with the following error: ‘The ‘labelid’ attribute is invalid – The value ‘{ddcee403-c32b-459f-a4f5- 20e23fb32eb0}’ is invalid according to its datatype ‘FormGuidType’ – The Pattern constraint failed.’. The validation failed at:
As you can see, the GUID shown above is an incorrect format because it contains a space. The obvious lesson here is to always be careful when editing code!

Plug-in assembly does not contain the required types or assembly content cannot be updated.

There are two general causes for this error – either the solution file includes a plugin that is missing some additional items, or something is preventing the target CRM plugin from being updated. If it is the first issue, then the solution file will need to be recreated with the correct components, since the plugin is malformed.
If the plugin is fine, but you are still getting this message, then the problem is that it is failing to update/overwrite the existing plugin. Some options are:
  • Change the existing plugin to “isolation mode = none,” in case it is a security issue.
  • Delete the existing plugin, since you will be reimporting it with the solution file.

Error occurred while fetching the report.

This essentially means CRM is not able to find a place to add the report, so you may have to do some troubleshooting on the report server for an on-premises environment. Some things to check are:
  • Is the report server running?
  • Do other reports work? Be sure to try standard and custom reports.
  • Can the report server URL be accessed from the CRM server?
An alternate solution is to just exclude the report from the solution file.

The ribbon item XX is dependent on ribbon control id=YY

This is another dependency-related error, although this one is specific to the ribbon, and it likely means you have a corrupted form. So, the problem itself is not the solution being imported, but rather the forms/entities the solution touches. In order to fix this, you will need to either edit the ribbon XML or use a ribbon editor, and examine the ribbon control in question.
For this problem, we advise seeking help from a developer (or PowerObjects!) since it may take quite a bit of troubleshooting.
Here’s one example of this error: you have a button with a hide function. Then, somehow, the hide function gets removed, but the button is still there, and it still contains a reference to your function. One possible fix is to recreate the same function, which will enable you to make changes to your button – to either remove it or fix it.
Once this is done, you will be able to make changes to your form (and import your solution).

Required parameter XX is not found for control YY.

This means that within one of the control tags, CRM is expecting another tag, but does not find it. The fix will involve looking further at the message, and adding the necessary tag. Here is one example:
Required parameter QuickForms is not found for control <control id=”Interests” classid=”{5C5600E0-1D6E-4205-A272-BE80DA87FD42}” datafieldname=”po_postedform” disabled=”false”><parameters><ControlMode>Edit</ControlMode></parameters></control>.
Within the “Interests” definition, it is expecting a tag for <QuickForms> but does not find it, and your fix will be to add an additional tag for QuickForms.

The wait operation timed out.

This error indicates that the import took too long and exceeded the time-out value allowed by Dynamics 365. This is performance-related, and may occur when you are importing processes – components that rely on the Microsoft Dynamics CRM Asynchronous service. You may want to simply try the solution import again to see if it works.
Otherwise, for a CRM Online environment, our recommendation is for you to open a ticket with Microsoft.
For an on-premises environment, there are two suggestions:
You may also simply retry the same import at a later time. Note: CRM performance is a separate discussion altogether. Please spend some time researching this before attempting any changes. The following MS blog will provide some background on different time-out values that you can set:

Column names in each table must be unique. Column name X in table Y is specified more than once.

This error is nearly identical to “An item with the same key has already been added,” which we covered earlier. It involves a field that already exists in the target environment but with different capitalization.
A previous blog covered exactly how to solve this particular error:

EntityMap XX – Import: failure. This entity map does not exist on the target system.

This is simply a fancy way of saying you forgot to add a relationship to your solution. To find out more about this error, examine the customization.xml file once more. Let’s say this is the error message you received:
EntityMap po_employment -> incident – Import: FAILURE. This entity map does not exist on the target system.
In the customization.xml file, scroll down until you reach the <entitymap> section, where you may see something like this:
<EntityMap>
<EntitySource>po_employment</EntitySource>
<EntityTarget>incident</EntityTarget>
<AttributeMaps />
</EntityMap>
This is the piece of the file that CRM reads and does not like, because the relationship itself does not exist in the target environment. The fix is simple: go back to your original solution, and add the missing relationship, as shown below:

Cannot add a Root Component X of type Y because it is not in the target system.

This is also a dependency-related problem. To investigate, you will need to know to what component it is referring. First, let’s figure out the type. The “type” in this error points to the entity code, which you can learn about here:
So if your message says it can’t find a root component of type 24, for example, it is referring to a Form; if it is 20, then it’s a Role, and so forth, as described in the linked-to page above.
The root component will be a GUID, which you will need to look for in the customization.xml file. Once you find it, it will take a deeper review of the file to determine how to either remove the component block from the file to re-import it, or to get the missing component into the solution or environment. Sorry, but for this issue, you will need some amount of proficiency in reading XML, since there is no clear-cut solution without doing some investigating.

Should be exactly 1 MessageProcessingStep registered for workflow.

We’ve seen this problem occur a few times, and it is the result of a process activation record that has been duplicated.
To better understand this error, here is a brief overview of how CRM processes (workflows) work:
You create a new workflow, and add some steps. This creates a new record of type process, where category = workflow, and type = definition. Have you ever done an advanced find, and looked at the view called “Activated Processes”?
This view filters out the other “types” so you only see the actual workflows that have been created. A process can also be of type “template,” which is simply a workflow template. It can also be of type “activation.”
What is a process of type “activation”? Let’s go back to the workflow you created, currently sitting in draft mode. Once you decide to activate it, your workflow will be active. By doing this, you have just created a new process record, where the type = activation. And it is this record that CRM triggers the events defined in the workflow. When you deactivate your process, it also deactivates the other process (type = activation). Umm, yeah, it can be a bit confusing.
Getting back to the error and how it can be fixed – this error may have happened as a result of a bug or glitch that, when a workflow was activated, created more than one process of type “activation.” And it will not allow you to reimport a workflow if there are two or more activation records. In order to fix it, you will have to manually delete the activation records for this workflow so that you have no more than one.
For those in on-premises environments, we have had successful results with a SQL delete command for the activation records. Please note that this is not a Microsoft-supported method, so please take a database backup before doing this, and do it only after work hours.
For CRM online customers, we recommend working with Microsoft to remove the duplicate record, as it cannot be done from the UI.

Invalid link type for system entity cascading actions.

This is an error we saw after an update of CRM 2013, though we have not run into it since. The error refers to the cascade definitions of a relationship, and there exists a nice blog with more information about this specific error, which is caused by a system relationship that changed behavior after an update:

No ErrorCode Listed!

We’ve gone through a lot of different Error Codes that can be generated for different issues during solution imports, but there is one more scenario we have yet to cover. Imagine you are doing an import, you receive an error, and you download the log file. When you open it, you see something like this:
In the “Status” column, you just see Processed, Processed, Processed, and then suddenly Unprocessed. No Failure, nothing to help you. Yikes! What do you do?
Well, the likely cause is the same problem we have covered a few times in the past – when a component you are importing already exists in the target environment, but there is a capitalization mismatch.
The problem with finding out which component is leading to the problem is that you won’t be able to tell by the downloaded log file in Excel. As you can see in Row 16 above, the last ItemType processed was “Chart” from the Incident entity. But that is of no help whatsoever! The only way to find the culprit is to examine each component, one at a time. Ugh.
Trust us, we feel your pain. But one suggestion to make your job easier is to create a new solution in your source CRM, add just one entity, and try to import it. If it succeeds, keep adding additional entities until you receive the error, and then you’ll discover the entity that likely contains a field that is causing the issue. Once you narrow it down to one entity, you will have to do a comparison of all custom fields, looking for any fields that exist in both environments but with mismatched capitalization of the schema.

General Customization Tips

Most of the problems presented in our examples can be avoided by following some best practices for customizing CRM. For any production CRM environment, our recommendation is to have a separate development/uat environment where you perform your customizations. Once things have been tested, those same customizations should be moved to your production environment via solutions.
This holds true even for small changes, such as increasing a column width of a specific system view or creating a new field. While it may be tempting to create the same change directly in your other environments, which is probably faster than moving it via solutions, we do not recommend this. Doing it this way has the potential for typos and mismatches, especially related to schema capitalization, that will cause problems for future imports. Additionally, other components, such as security roles and connection roles, will have mismatched GUIDs and will also fail your future imports.
Sometimes, editing the customization.xml file is either necessary or is the best approach compared to other methods. This is ok to do – as long as you do it carefully and knowingly. And take backups! It’s so quick to do and takes up very little storage space. Just copy your zip file and save it – now you’re ready to edit!
Most of the problems mentioned in this blog can be avoided by following this process. But if all else fails, feel free to contact our support team – we are ALWAYS happy to help you.

How to use Form Component Control to Edit Related Entity Information in Dynamics 365 CRM

In the recent release of the Dynamics 365 CRM, new features have been added. One of the most important and useful features among these is th...