Now that you’ve mastered the backup and restore for your CRM Online organization, you may be wondering, now what?
Backups are only held for three days, that’s not very useful, is it?
Well, actually, it is. These transient backups are very useful if you perform some scary-looking update to your production instance. But more importantly, they can be restored into any sandbox instance that you have.
CRM Online deployments have a free sandbox per every 25 users, chances are that you will have an unused instance lying around. Why wouldn’t you restore your backup into that instance and set it aside? That would create a persistent backup of your CRM organization at given point in time and set it aside as a reference or emergency stash.
If you’re not up to the scale of 25+ users yet, ask yourself if persistent backup worth a price of a large weak skim organic soya vegan latte per day, because that’s what an additional sandbox instance would cost you.
When no one in your organization including system administrators can create or update personal views, check that you don’t have any plugins registered on all entities to run in a context different from a calling user.
Symptoms: when personal views are created or updated, all users including system administrators receive the following error:
Object 4230 is userquery entity, a.k.a. personal or saved views. But how could it be that even system administrators are denied access?!
Personal views are special – you cannot grant privileges in any scope but the user. Go ahead, open Settings > Security > Security Roles > Any role and try to change the scope for Saved Views. See how only nothing or user is available? That means that even system administrators do not have access to other users’ views.
Enter a plugin on all entities. It kicks in when users are saving the views and needs at least read access to the entity. But since security context has been changed to another user, permission is denied.
Solution is either to change the plugin to run under a calling user context or not to register the plugin on all entities. Generally speaking, registering plugins on all entities is an extreme step and should be avoided.
One of the popular ISV solutions, Adxstudio portals (version 7 and below), actually has the cache invalidation plugin registered on all entities and the recommendation would be to re-register this plugin only for entities that you care about in the portal.
Some of these functions require parameters and documentation how to pass parameters is available. Except that the documentation does not explain how to deal with enumerated types required by some of the functions, e.g. RetrieveCurrentOrganization that needs AccessMode of EndpointAccessType enumerated type.
If you go into the Dynamics CRM Portal and change the Friendly name for your CRM organization that changes it for everyone when they access CRM via the browser. But it doesn’t change the name in the Outlook client. Each user will have to change it manually. Lets see how this works.
Select the Name field and replace it with the new friendly name.
But the change in the admin center doesn’t change the Outlook Client
Launch the Configuration Wizard, select Rename and then enter the revised Friendly name, Click Okay and you are done.
Be careful when enabling auditing on the Mailbox entity. As Jukka “Kalsarikännit” Niiranen has discovered after analyzing why one of the instance consumed disproportional storage:
“It all looked fine at first, but looks like at some point the sync process had started to update the exchangesyncstatexml field with new data every few minutes. [This] field … is hidden from the UI, and also a field for which I cannot selectively disable the audit for, since the Mailbox entity fields are not editable. Oh well, time to delete our entire CRM audit log history and move on…”
In the cases where the audit contains valuable business data, deleting the audit log history as a cleanup measure is a tricky business, especially for CRM Online.
CRM is very good at securing data but there is no way to control visibility of the system views for the end-users. There are good reasons why would anyone want that:
Systems grow over the time and it’s hard to control retirement process for old views, especially for large implementations. As a result, list of available system views tend to grow out of control.
If record is required on multiple customized sub-grids, chances are each sub-grid will potentially require yet another system view.
Remove views that are broken for a user/team. Your view may include fields from a parent entity users do not have access to. They will see “You do not have permissions…” error plastered all over the grid.
Simplify UI and provide better experience for the end-users. Tailor their experience by role and only show views that are applicable for their role.
When users ask for a new “report”, quite frequently they mean “give me the list of records satisfying certain criteria”. A.k.a. view.
Lucky for us, views can be shared:
Create a handful of universal views that make sense for everyone, e.g. “My accounts”, “Overdue invoices”, and implement them as system views
If you would like to restrict view to a specific user/team, create a personal view and then share “read” access to it with the user/team.
The only drawback of this approach is that users will see these “private” views under “My Views” subheading. Oh, and you won’t be able to use these views in system charts/dashboards, or subgrids.
In this video, we look at the different Authentication & Authorization options for Dynamics CRM Portal capabilities. We walk through an overview of the elements, and then explore how to access and change them.
Give us your feedback, all of it: good, bad, and ugly, I’m sure we can take it. Suggest new topics either in comments or by sending your ideas to firstname.lastname@example.org.
We’ve been hopelessly late with our daily tips this week and for a good reason – CRMUG Summit in Tampa, Florida. CRM Medic booth is one of my favorite parts of the summit; whenever one feels like dealing with another puzzle, just don a white coat and listen.
Ed G complained that his Subject tree is polluted in the UI with some mysterious entries he cannot get rid of. A bit of collaborative brainstorming and XrmToolbox magic later, and here is the summary.
For a long time Subject had a enigmatic featuremask attribute that is described in MSDN as “Information that specifies when the subject will be displayed in lists of subjects”. Experience shows that it’s been around for a long time and setting the value to anything but 1 would hide the subject from UI. Why would anyone want to do that? Presumably to preserve data integrity during the import process (of cases or products) but without introducing the old or obsolete subjects into the tree.
It was all going well until CRM 2016 changed the pseudo-lookup control used for the subject. Now it’s some convoluted dropdown tree concoction. That does not honor featuremask setting and shows all subjects including hidden ones.
Proof of concept is easy:
Import rogue subjects using Data Import
Verify that they are hidden in Settings > Service Management > Subjects
Open a case form and see the ghost
If you want to get rid of these, I don’t see a straightforward fix that does not involve writing code that would iterate over the subject tree and update the featuremask attribute to 1. Since subject does not appear in the advanced find, it’s not possible to modify values by export-modify-import process.
Users can freely access entity records in some views but not the others – instead they receive the following error:
You do not have permission to access these records. Contact your Microsoft Dynamics CRM administrator.
Check that the views that generate “access denied” error do not include fields from the parent entity users do not have read permissions for. For example, if users have read permissions for Jobs but not the linked (parent) Client then the presence of any of the Client’s fields in a view will generate the error above. Note: it’s OK to include the lookup field itself – in our case it will show client’s display name.
CRM for Outlook is one of the main components driving the adoption of Microsoft Dynamics CRM365. But it could be temperamental at times. SaRA, Office 365 Support and Recovery Assistant, that we mentioned previously, has been greatly enhanced and now includes the following features:
Verifying CRM for Outlook is the same major version as your CRM Online instance
Running the CRM Configuration Wizard with a custom configuration file