What’s up with CRM not working in latest version of Chrome?

You might have noticed that some features of CRM are no longer working after updating to Chrome 37. This posts provides some insight into work-arounds and possible solutions

All of the sudden seems like the CRM 2011 application is broken for Chrome for some features such as editing workflow send email steps. This is because CRM relies on a web API called showModalDialog() which Google Chrome is no longer supporting as of version 37, you can read more about it here. Note that it was deprecated since version 35 and Firefox has also deprecated that API.

So what can we do about it? Well, the easiest work around for now is to use Internet Explorer while you can find a more permanent solution. Microsoft has also published another temporary work-around so that you can continue to use Chrome: KB3000002. However, there are three bad news with that workaround. The first is that it requires each user to apply the work-around. The second is that users must have a highly privileged account on their work station in order to be able to apply the workaround, and we know that in the enterprise world, very few users will be given enough privileges or access to make the changes suggested by Microsoft. Finally the third bad news is that the work-around is only valid until May 2015!

Microsoft had quite a job to do in order to fix the entire CRM application to remove all the usage of showModalDialog(). This will probably take some time before we are able to apply a patch at the server level which will automatically fix the problem for all users. Perhaps before that happens there will be an easier work-around solution that Microsoft can come up with but don’t get your hopes up.

I guess this article is no good news for those who refuse to give IE a try, it’s one of the consequences of multi-browser support and Microsoft having little control on when other browsers drop support for API's that CRM relies on.

Should I use CRM personal views or system views?

When customizing Dynamics CRM the question often arises on whether to use System Views or Personal Views. They both have pros and cons that I will explore in this post.

Let’s first look at what is different. I had previously posted an article about the differences between personal and system views, here is a summary:

	Personal	System
Ownership	Can be owned by a user or team	Owned by the organization
Visibility	By default it is only visible to the user who creates it and users/teams with whom it was shared	By default it is visible to all users.
Privileges	Can be protected using the standard privilege depths for the entity (none, user, BU, BU and child BU, Organization). This can allow you to make a chart/dashboard accessible to some users but not all and be able to select which users can see which charts/dashboards.	User access can only be configured to all or none (if a user has access to a system chart/view then the user will have access to ALL system charts/views.
Sharing	Can be shared with a specific user or team. For example the CEO might want to share a chart only with a VP.	Cannot share or unshare system views/dashboards/charts since they are all visible at the organization level (by everyone).
Solutions	Cannot be included in a solution. This is a show stopper if you need to move personal views/dashboards/charts across deployments and organizations. You would need to copy them manually. For charts, you can export the XML and import as a system chart.	System views/dashboards are solution aware and are fully supported to be transported in solutions.
CUD operations (Create, update, delete)	Most users will have access to create their own personal views, dashboards and charts.	Only high privileged users and system administrators should have access to CUD operations on system views, charts and dashboards.

 

The problem with system views is that:

1. Requires IT to create/update and deploy the views
2. Cannot define which users see the view, all users will see all system views.
3. Can very quickly clutter the view selector with numerous views making usability a challenge when the users have too many views to choose from.

The problem with personal views is that:

1. Often leads to excessive sharing, if every user creates views and shares them with the team then volume of views will grow very fast making it hard for users to find the views they actually use.N
2. Once a view has been shared with you, you cannot “reject” it if you don’t want it. You would have to ask the view owner to un-share it with you.

 

We will explore more in details what best practices can be leveraged to reduce these problems:

• If the view is only required for a small subset of users it is better to leverage shared personal views
• If the view is to be changed often by business users then it is easier as personal view.
• If the view is a default view that everyone needs and does not change often it is better as system view.
• If your entity already has 10+ system views, you should consider whether you really need to add more system views or if you can manage at the personal view level.
• If different users need to see different information (e.g. service vs. marketing user) for the same entity then you can leverage personal views shared with a team (service or marketing team)
• There should be small number of users who are trained to create, maintain and share personal views. You should avoid everyone sharing their own views with everyone else.
• All users should be trained to create their own personal views but be mindful before sharing it.
• Before disabling a user in CRM please ask the user to delete, assign or un-share all personal views.
• When sharing a view, make sure that you also share the “share” privilege so that way you give everyone the chance to opt-out to your view or share with other users:

 

What happens to personal views if user leaves the company (disabled user)

If a user has created views and the user has shared these views with multiple users then it can be a problem when the view owner leaves the company and the user is disabled because the shared views continue to be active and all users with whom the views were shared will continue to see those views. However, at this point it is not possible to delete or update the views that were created by a disabled user. If you find yourself in this situation you will have to open the disabled user and click on “Reassign Records” so you can reassign the personal view to a new owner. (Note: This will reassign all the records in the system, not just the system views).

 

How to reject personal views

If another user shared with you a view that you don’t want to see, you have 2 options:

1. If the user who shared the view was kind enough to share with you the “share” privilege then you can easily opt-out to the view by removing yourself or your team from the sharing list.
2. However, if you are less lucky and the view owner only shared “Read” privileges with you then you will have find out who is the owner of the view and ask them to remove you. To find the view owner go to Advanced Find, select the entity from the dropdown and click “Saved Views” button. Now you can find out who is the owner of the view that you don’t want and you can ask them to remove you.

 

How to assign a personal view

If you created a personal view and you no longer want to maintain it, you can assign it to another user by opening the list of your saved views and clicking “Assign Saved Views”

 

 

How can IT identify which personal views were shared and with whom

There is no easy way to find all the shared views in CRM, you can create a custom report in CRM or simply run the following query in your database:

 

select userquery.Name AS 'View Name', userquery.OwnerIdName as 'View Owner', SYSTEMUSER.FullName 'Shared with user', TEAM.Name as 'Shared with Team'

FROM principalobjectaccess

JOIN userquery on objectid = userquery.userqueryid

left outer JOIN SYSTEMUSER on principalid = SYSTEMUSER.SystemUserId

left outer JOIN TEAM on principalid = TEAM.TeamId

WHERE objecttypecode = 4230

 

This will give you a list of all the views, the view owner and the users/teams with whom each view is shared. You can use the SQL statement above to create a CRM report that is available to CRM users from the CRM application.

CRM Auto-numbering: What happens when you reach the maximum number

I’ve often been asked this question about the out-of-the box auto-numbering feature in CRM: What happens to my auto-number when I get over 99’999 cases in CRM?

Let’s look at how auto-numbering works out of the box. Each of the supported entities (contracts, cases, articles, quotes, orders, invoices and campaigns) have the following configuration:

Prefix: This is a 1-3 character prefix that you can use to identify which entity the number references. In the example above if you see INV-01000-AS7F you know that this number references an invoice because of the “INV” prefix. This prefix is configurable.

Number: This is a sequential number that will be incremented with each new record. You see this number holds between 4 and 5 digits. Hence the question of what happens if you have more records than the number of digits can support.

Suffix: This is a system-generated random number that is supposed to be unique. I t’s very obscure why there is a need for a suffix, unfortunately it is not configurable and you cannot remove it. All you can do is specify the length between 4 and 6 characters.

 

Initially I thought that when your number goes over 99999 then it will simply change to 100000. However, I could not find any documentation that specifies how this works behind the scenes or what to expect. So I had no choice but to confirm my theory by testing:

This is good news. so I even went ahead and tested what happens if you have 1 million cases and found the same result:

Therefore there is nothing to worry about (except the lack of documentation).