Tip #1088: Errors importing marketing list entity in Dynamics 365 v9

If you make changes to the marketing list entity in Dynamics 365 v9 and try to move your customization, you may receive an error importing the customization.


  1. Extract the solution and open the customization XML file
  2. Locate the List entity in the XML file
  3. Add the following tag in the XML file:


4. Zip the solution and import it again

Tip #1087: Hierarchical Security and Disabled Users

So you want to use hierarchical security to give your sales managers access to their team’s account records. One thing that you should be aware of is how hierarchical security works when users are disabled.

If a user becomes disabled, records that he or she owns are not available for hierarchical security. This is a performance related limitation but is not currently documented in the official documentation.


  1. If a user who owns account records leaves the company, your offboarding process should include reassigning his records to another user (or to the sales manager).
  2. If #1 is not practical, such as high turnover scenarios or where there is no current replacement for the territory, consider creating a team for each sales manager called something like “west territory-open.” Make the sales manager a member of the team, then assign the disabled user’s records to the open team. That way the manager can see and manage those accounts, but they will be open so that when a replacement is hired, they can be reassigned to the new user.
  3. If none of these options work, consider an alternative to hierarchical security. One common approach that we frequently did prior to the introduction of hierarchical security was to create an access team on Account that grants the desired managerial permission, then have a nightly batch job (using KingswaySoft, Scribe, or some other ETL tool)  that builds the access team membership with the sales manager for each account. This approach avoids the problem of sharing, as well as the limitations in hierarchical security.

Tip #1086: Bring back content access levels

Dynamics 365 Portals have a very convenient way to control access to knowledgebase articles – content access levels. Link contact, account, or web role to a content access level (e.g. Gold Partners), then simply associate that access level with a knowledgebase article and boom – that article is only available to the users associated with that access level (directly or indirectly).

However, when you deploy Dynamics 365 v9.0, you may find that following the instructions to Assign content access levels to knowledge articles is not possible because, well there is no “symbol that looks like a lock.”

That is because knowledgebase articles are now part of the Customer Service Hub app and that app is configured to use one form only: Knowledge Article for Interactive Experience.

  1. Go to Settings > My Apps and then click … on Customer Service Hub and select Open in App Designer
    Open app in App Designer
  2. Locate Knowledge Article entity, click Forms, select Portal Knowledge Arcticle for Interactive Experience.
  3. Save, Validate, Publish
    Fix forms and republish
  4. KnowledgeBase Article form will now have the form switcher and the second form will have the coveted Content Access Levels.
    Form switcher
  5. Alternatively, just append and configure the Content Access Level subgrid to the summary tab.

Tip #1085: Using Voice of the Customer to survey users

Several people have recently asked me if they could use VOC to send surveys to application users. The answer to that question is “yes, sort of.”

When you send a non-anonymous survey invitation, you copy an HTML snippet to a Dynamics 365 email template, and when the system generates the email, it replaces the snippet with a client-specific URL that includes the ID of the customer. That’s how Voice of the Customer knows which customer record to link the response.

These invitation templates only work with contact and account records, not users or other records. If you try to put an invitation snippet in an email template sent to users, you will fail (trust me, I’ve tried).

Workaround 1

One workaround is the possible solution I suggested at the end of tip 951. Create contacts for system users, then create a lookup field for contact on the user record, linking the user to his or her contact record.

This then creates a trail you can follow with workflow or other system processes to send a survey invitation email to the contact related to a system user. For example, say you want to automatically survey the requesting user when an internal case is closed, you could have a workflow fire on the resolution of the case and trigger an email send to the originating user’s related contact record.

Workaround 2

Another school of thought is don’t use Voice of the Customer to survey users. It’s called Voice of the Customer for a reason–it’s designed to get customer satisfaction feedback from external customers. VOC fills an important gap by providing an interface that external parties can use to provide feedback into Dynamics 365. Users, by definition, have access to Dynamics 365, and any of the D365 user interfaces can be used for capturing input from users. Instead of using VOC for user surveys, you can use the feedback entity, create a custom user feedback entity, or use a dialog (yeah, they are going away at some point in the future, but still very viable for the foreseeable future). With any of these approaches, you can still send an invitation link to the feedback form via a workflow and you can also create additional relationships to other entities (which is not currently available via Voice of the Customer).


Tip #1084: New way to learn Dynamics 365

Our resident video tipster, Derik, has been a bit quiet lately and, as it turned out, for a good reason. If you are not a partner, and do not have access to Dynamics Learning Portal, then you’re in luck.

Managing Customer Engagement with Microsoft Dynamics 365 course is now offered free of charge through Microsoft Learning. The course contains tons of videos, step-by-step exercises, and targets first-time Microsoft Dynamics 365 users, young professionals and students.

The course is set to be archived in June 2018 so hurry up and learn!

(Facebook/Twitter cover photo by Clever Visuals on Unsplash)

Tip #1083: Don’t expire your passwords

Mini Truckstop

Dynamics CRM TipperJonas “The Shuffler” Rapp fed us a perfect question for a security slam dunk.

Recommended expiration settings


(Jonas’s words, not mine)

Yes, really. We’ve already mentioned the brilliant password guidance in our tip 1031. Since some folks seem to have missed the memo, here’s the quote from the guidance (highlights are mine – g.d.).

Most administrators will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user (who is likely to choose new passwords that are only minor variations of the old) and carries no real benefits as stolen passwords are generally exploited immediately. Long-term illicit use of compromised passwords is better combated by:

  • monitoring logins to detect unusual use
  • notifying users with details of attempted logins, successful or unsuccessful; they should report any for which they were not responsible

Regular password changing harms rather than improves security, so avoid placing this burden on users. However, users must change their passwords on indication or suspicion of compromise.

It’s good to see Microsoft reviewing and adjusting their security recommendations on a regular basis. Stay safe, folks!

Tip #1082: Forming an opinion on which form

If we use ClickDimensions and Dynamics Portals, we have a wealth of options when it comes to creating a form for an external party to fill out. We have:

  • Dynamics Portals Web Forms (and Entity Forms but these are in my ways a simplified version of Web Forms)
  • ClickDimensions Surveys
  • ClickDimensions Web Forms

The question we may need to ask ourselves is which one to use for a given situation. At this stage I could use an illustrated guide to pave the way. After all, TOTD does occasionally feature flow diagrams. However, I am feeling nostalgic so my tip today will be in the form of a Commodore 64 BASIC program.

EDIT: Not everyone turned out to be a BASIC fan. Heck, some probably were not even born when BASIC was the language du jour. Scroll down to see a handcrafted diagram, if reading code is not your thing.







15 REM *****I DONT DO COLONS*****










1,000 words equivalent

Tip #1081: Magic of managed solutions and sitemaps

The topic of managed solutions and sitemaps turned out to be so popular that a few trucks stopped by for the first Tipping Truckstop of 2018.



Before installing any managed solution, backup your sitemap. Because

Managed solutions and sitemap are like magicians and their assistants: one distracts the audience, another one disappears.

The story

Guido “Future Olive Farmer” Preite has reported that installing Organization Insights version removes Process Center and Application sitemap areas in Dynamics 365 version 8.2.2. Jerry “Once Tipster Forever Tipster” Weinstock has since confirmed that the problem exists in Dynamics 365 version 9.0.1 as well.


Miquel “Third musketeer” Julien was first to offer the solution:

I met the same problem two weeks ago! I used the XrmToolBox (must be some kind of a native French thing – t.j.) to change the sitemap after the insight solution import.

Now, before any managed solution import, I save the sitemap with the Sitemap Editor tool.


When I questioned the ability of a managed solution to delete other entries in the sitemap, Jonas “Surströmming MkII” Rapp outlined the detailed steps to reproduce the issue:

As long as the parts you are removing are “known” where your solution is developed. (which applies to all default areas – t.j.)

  1. Create a solution in vanilla CRM
  2. Add sitemap to it
  3. Use favorite sitemap editing tool to remove parts of standard solution sitemap
  4. Export solution managed

You will see in the customizations file that the removed areas/groups/subareas appear with action=deleted. And that will apply wherever the solution is imported. That’s why you should

always always always make sure you reset the sitemap to default before adding your own stuff when building ISV solutions

Otherwise someone will get angry and you will feel the flames that the orginsights team is feeling right now.

ISV Story

Jerry has some additional advice for ISVs:

As an ISV we initially recommended to our clients to backup their sitemap and even their default solution prior to importing our Managed Solutions.

However, since no one ever had the time to do it apparently or read the directions we changed our approach – We don’t include a sitemap in our solutions any longer. We do include instructions on how then can update their sitemap to add the entities from our managed solution.

Since going that route, provisioning sessions usually end with a happy face. Even though it’s time consuming for the client.

Tip #1080: Setting KPIs for user adoption

After you deploy Dynamics 365, you will want to monitor how well your employees are using the system. Using tools like Microsoft Dynamics 365 Organization Insights you can monitor how active your users are, but that is only part of the user adoption story. In this tip, Tabetha Sheaver explains what you should consider to get a full picture of user adoption of Dynamics 365.

When determining CRM user adoption metrics consider these 3 KPI’ to measure:

1. Business Outcomes

Is the needle being moved on the business outcome you were trying to achieve when you originally purchased? (This is a lagging indicator but telling none the less. Focus on RESULTS not feelings.)

2. Usage

Are people using the system? – Measuring some objective areas like is the system user friendly and does it add value to the persons daily work activities can be done via surveys but you can also track people that have never logged on or only use it rarely to determine if its really worth paying for a license for them. If people aren’t using the system or are only using it for certain tasks it can indicate a system configuration issue or a training issue.

3. Data

Is the data accurate on an on-going basis? Are you collecting too much or too little data? What is the data that is being collected actually being used for?

Set KPI’s in each of these areas to measure user adoption success.


Tip #1079: Security Design Principles

We have a lot of flexibility when it comes to security in Dynamics 365; field-level, record-level, hierarchy, ad hoc sharing and so on. Sometimes, depending on the requirements, there are a few ways to skin the cat (such a violent expression). Whenever you are presented with a range of options to solve a problem, it is good to fall back on some guiding principles to work out the right path. Here is my MASCOT model for security design.

Maintainability: If the design cannot be maintained by a power user/non-coding developer, rethink. Having a base security role helps in this regard

Always Think of the User: If the Users hate it, the system will not be used. There is a balance to be found between governance and practicality

Simplicity: Keep the design as simple as possible. Minimise Security Roles and Business Unit complexity. Documentation gets lost and exception rules are often forgotten. Do not share security roles between Users and Teams though

Configuration First: Mixing development and security can lead to scalability issues, especially if automated sharing and un-sharing is involved. Keep the system running smoothly by avoiding ad hoc sharing of records via code

Only Use Security When Necessary: If there is not a valid business reason to protect information, don’t. A lack of trust is not a valid business reason

True Security, Not Security By Obfuscation: It is sometimes much easier to remove a field from all forms and views and think it is secure. If the data can be found via Advanced Find, it is not secure

I remember one security model which broke all of these rules. Accounts came in from a third party system via integration. Based on the Account’s office location, code automatically allocated it to a Territory and then ad hoc shared the Account to all Users with permission to access that Territory. To keep up with the growing scaling issues and minimise User complaints, the administrator was upgrading the RAM of the SQL Servers literally every month. Field security was implemented by simply adding and taking away fields from forms and having Users use the right form. It was a mess.

I reviewed their system and proposed a security model using both record and field level security and no code. The only difference was one field, previously read only, would be editable. A vastly simpler security model and no more RAM blow out. The CTO refused to change because he was the architect of the original model and, despite having auditing enabled, did not trust his employees not to edit that one field.

Six months later he was sacked, his team replaced, and a rival CRM system implemented (yes, THAT one!). They could have upgraded Dynamics for a fraction of the cost but the system was so despised it was politically easier to ditch it.

Learn from the mistakes of others and embrace the MASCOT.