CRM 2013 introduced light-boxes for most popups to make the UI look cleaner with less browser alerts and popups. However, these internal functions were not included in the SDK, so as developers we couldn’t access them for our custom code. Instead, we’ve been forced to use alertDialog and confirmDialog which under the hood just calls the browsers alert and confirm functions.

The main problems with this is that we cannot customize the buttons, and the alerts look ugly.

What I’ve done is created a custom JavaScript library to allow us to create our own light-box popups which look natural and part of CRM. We can now create our own seamless alerts and popups using custom buttons and custom callback functions for each button. We can also specify different types of icons to display in the alerts, instead of being forced to use the alert ‘exclamation mark’ or confirm ‘question mark’.

While technically unsupported, this code is manageable if it ever does break in future CRM releases, so it will be as simple as updating the solution files and everything will just work. In the event that the CRM Lightbox doesn’t work or isn’t supported (like in outlook), a modalDialog will be displayed.

How it Works

Download and install the unmanaged solution from CodePlex: https://alertjs.codeplex.com/, then simply add a reference to mag_/js/alert.js wherever you want to use the custom alerts. This will work from forms, views, command bars, and pretty much anywhere in CRM that supports JavaScript.

Next simply call the Alert.show function. All other dependent web resources will be loaded automatically.

Parameters: Title (main message), Subtitle (smaller message), Buttons (array), Icon, Width (px), Height (px), CRM Base URL

All the parameters are technically optional. If no buttons are specified, a default ‘OK’ button with no callback will be added. If no icon is specified, then no icon will be displayed. If height is not specified, it will default to 225. If width is not specified it will default to 450. The URL only needs to be specified if the alert is being called from somewhere that doesn’t have Xrm.Page access (e.g. web resource).

Each button object in the buttons array needs to have a ‘label’ (text displayed on the button), and optionally a ‘callback’ (function called if the button is clicked).

The following icons are supported: “INFO”, “WARNING”, “ERROR”, “SUCCESS”, “QUESTION”.

Alert.show("Would you like to create a new Sale?", null,
    [{
        label: "Create Sale",
        callback: function () {
            Alert.show("Sale created successfully!", null, null, "SUCCESS", 500, 200);
        }
    },
    {
        label: "Not now"
    }], "QUESTION", 500, 200);

 

To download this package, check out the solution on CodePlex: https://alertjs.codeplex.com/

In Dynamics CRM every now and then users may encounter errors like the one below. These are typically random errors with Microsoft scripts that usually do not affect any functionality.

We’re prompted with the option to ‘Send Error Report’ to Microsoft so they can fix the bug if enough reports of the same issue come through, or we can click ‘Don’t Send’ and it will just close the dialog box and ignore the error. This dialog can be useful for customizers, but it is unnecessary to show to general users.

Each user can define their preferences for displaying these error messages in their Personal Options under the Privacy tab. By default it is set to ask us every time whether to send an error report or not. We can also select to automatically send the errors, or to never send the errors. Usually this is changed for everyone to automatically send or never send so that the dialog boxes do not show up.

What some people don’t know, is that we can define these preferences at a global level, so that each user doesn’t need to go into their personal options to make this change, and new users won’t need to see those popups by default.

To change this setting globally, go into System Settings, Administration, and click on Privacy Preferences.

On the Error Reporting tab, we can tick the box to specify the error preferences for all users, and then select whether to automatically send, never send, or prompt every time.

Once this change has been made, users will no longer see the Privacy tab in their personal options, and they will not be able to change this setting. Any new users that get created, as well as all existing users, will have these preferences automatically.

One thing to note is that as this is not a part of System Settings, you cannot deploy these preferences in a solution, so you’ll need to configure this in each CRM system.

If you’re seeing an error similar to the one above, you’ve probably done a database backup and restore from a CRM 2013 instance into a new CRM 2013 or 2015 instance. This error will pop up when you try and modify a user’s email address, or open personal options from outlook, as well as when performing some other tasks around CRM that include sensitive data.

The Data Encryption error states: “There are encrypted fields in the organization database, but the data encryption feature isn’t activated. Contact your Microsoft Dynamics CRM system administrator to activate data encryption. To activate, go to System Settings > Data Management > Data Encryption…”

The reason this error occurs is because when we restore/import a database, data encryption is disabled by default, even if it was enabled in the system we took a backup from. This is because the encryption settings are stored in the config database, so the .bak file does not contain these settings.

According to the error, to enable encryption we need to go into Data Encryption under Data Management. However, we can only enable Data Encryption if CRM is using the https protocol, and usually the reason we’ve done a backup/restore is because we’re setting up a Dev or UAT copy of Prod, which may not need to be https.

This error states that “The HTTPS protocol is required for this type of request. Enable the HTTPS protocol and try again.” However, enabling https may not be ideal, and we still need to be able use the system.

Fortunately, there is a SQL script we can run on the config database which will allow us to use data encryption without using the https protocol:

UPDATE [MSCRM_CONFIG].[dbo].[DeploymentProperties]
SET [BitColumn]=1
WHERE ColumnName=’DisableSSLCheckForEncryption’

You shouldn’t do this on a production instance, but for Dev or UAT instances this is necessary.

Once that’s updated you need to do an IISRESET on the CRM server for the changes to take effect.

If we try opening that Data Encryption window again, we should see that encryption is disabled, and we can create a new key and activate it.

You should be able to get the encryption key from the original CRM system you backed up from. If not, then you can simply create a new encryption key.

When you activate, you might be faced with another error which states “Please select an account that is a member of the PrivUserGroup security group and try again”.

This is because although we might be a system admin in CRM, we cannot update the encryption key unless we are a member of the PrivUserGroup in Active Directory. We can either log into CRM as the user who installed CRM, or we can get our user added to that security group.

Once that’s done we should now be able to activate the encryption key.

You should now be able to edit user email addresses, and perform any other operations that require data encryption without any errors.

NOTE: This encryption error only happens when we restore from a CRM 2013 or 2015 backup. If we create a new org through Deployment Manager, or if we upgrade a CRM 2011 database, encryption will still be enabled by default. We can see when creating a new org the wizard informs us that encryption will be enabled.

If you’ve recently upgraded to CRM 2013 SP1 and you’ve applied the product update for cases, you might be experiencing an issue where outlook users are unable to track certain emails in CRM. They receive an error: You do not have permissions to access these records. Contact your Microsoft Dynamics CRM administrator. Item Name = <email subject>.

After a bit of digging, we found that the missing privilege was Read access to the Case Creation Rule entity, which is a new entity added with the latest product updates. Because we already had existing security roles, these did not include any access to this new entity.

If we give User level Read access to the Case Creation Rule entity through our security roles, this error will no longer appear.

This error only seems to occur when the email being tracked is from an unresolved sender, which doesn’t match any existing CRM records.

Recently we noticed a problem where some users were not seeing that a field was required in Dynamics CRM 2013. The field still behaved the same, and would display a notification if the field was left blank, however it simply would not show the red asterisk beside the field letting the user know the field is required.

There were also some other unusual looking things, such as boxes showing up around the social pane headings etc. This was happening on all browsers, but only for certain users.

As it turns out, there is a setting in Personal Options to ‘Enable high contrast’ which was doing this. It appears that the setting was on by default for certain users, possibly as a result of their browser or OS settings. The solution was to simply uncheck this option for each user.

You may have to clear the user’s browser cache to see the changes. Once that’s done though you should be able to refresh your form and see it normally again.

This issue occurs in both CRM 2013 and also CRM 2015.

Business Rules were introduced in CRM 2013, which allowed customizers to create simple conditions to manipulate the form without needing to write any JavaScript. The only limitation of this was that to create If-Then-Else style conditions we had to create multiple business rules to accommodate each possible scenario.

Dynamics CRM 2015 now introduces the ability to add additional conditions into a single business rule, allowing us to maintain all the logic for a single rule in one place, rather than across several business rules.

You can see we now have a button at the bottom ‘Add Else’. If we click this a new CONDITION/ACTION block will be added.

We can leave the CONDITION blank, and this will act as an ELSE, meaning if the first condition is not met, this action will fire no matter what. Otherwise if we specify a condition, this will become an ELSE IF, and we will have the option to add an additional ELSE below this.

We can repeat this as many times as we need to, creating as many ELSE IF’s as is required for this rule. I’ve added a few more conditions for if the Rating is ‘Cold’ to set Probability to 20, and finally an ‘ELSE’ which sets it to 0 if there is no Rating set for some reason.

Once we’re done we can activate the rule and test it out.

When creating a new Opportunity, straight away we can see the Probability is set to 60 since the Rating is Warm by default.

If we change the Rating to Hot or Cold the Probability will be updated based on our rules.

Dynamics CRM 2015 adds a new feature to Business Process Flows that were introduced in CRM 2013, which now allows us to branch the process in a different direction based on some condition. Similar to in a workflow or dialog where we might have several different paths that can be taken based on the type of record etc.

In CRM 2013 business process flows only had 1 branch that they could follow. If you wanted multiple branches you’d need to create multiple process flows and have the user switch between them. This has become much easier now, as we can simply select to add a branch into the process.

When we click to add a branch, we are able to specify a condition which would take a user down this branch.

We can also add additional Add/Or conditions to this branch by clicking the ‘plus’ button just below the condition. For example we could do: Industry = Accounting AND No. of Employees > 100.

At the time of writing this blog (which is based on the beta release) it seems like we can only specify one type of grouping for each branch, e.g. ‘this OR this OR this’, or ‘this AND this AND this’, but not this AND this OR this. If we have 3 or more conditions and change one of them from AND to OR or vice versa it will change all the other conditions for this branch as well.

Once the condition is created, we can add a stage within the branch by clicking ‘Insert Stage’ below the condition.

We can add additional branches to our existing branch by clicking ‘Add branch’ above the entire condition (the same way we added the first branch), which will by default add an ‘Else’ condition, meaning if the first branch’s condition isn’t met it will always fall back onto the ‘Else’ branch. We can also convert the ‘Else’ to an ‘Else If’ which allows us to specify another condition if the first condition isn’t met. We can add as many ‘Else If’ conditions as we need to which will create multiple possible branches from the same point.

Once we’ve completed our process flow with branches it’s time to test it out. The process flow I’ve created runs on Account, and has 2 branches. It starts with identifying the industry, number of employees, and annual revenue. Depending on these values, the process should either go into the ‘Develop’ and ‘Propose’ stages, or into the ‘Research’ stage.

When we create a new Account, since there are no values entered yet, the process is shown with the Research stage.

If we enter in some values the process flow will update automatically.

When we go to the ‘Next Stage’, we will be moved down the branch that meets our conditions. Once moved into the next stage, changing the values that took us down this branch will not change the process. For example, once in the Develop phase, if the Annual Revenue is changed we will remain on the current branch.