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.

truckstop

tl;dr

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 1.3.1.0 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.

Antidote

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.

Reproduce

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.

Tip #1078: Illustrated tipster guide to the decision making process

The binary choices seem to rule the Dynamics 365 landscape as of late. Everyone has an opinion, everyone seems to know the right way to do things, everyone stands by their choices until their last Dynamics breath.

To stop very mature “did not – did to!” arguments when designing, building, and operating Dynamics 365 solutions, we present the ultimate, the one and only, the illustrated tipster guide to the decision making process:

(Full size hi-res image)

Judicious application of spießrutenlaufen is encouraged, as usual.

Tip #1077: Connect to the right instance

As Guido “Future Olive Farmer” Preite has discovered, sometimes CrmServiceClient may connect to the wrong instance. Just like that.

Dynamics 365 instances now can be backed up and restored at will. The side-effect of this awesomeness is that URLs and unique names may no longer match, leading to the fun times with connections. Here’s the scenario:

  • Instance https://foo.crm.dynamics.com with a unique name bar
  • Backup and restore that instance into https://bar.crm.dynamics.com, the unique name will be something like org1234567
  • If you use CrmServiceClient with a connection string that points to https://bar.crm.dynamics.com, it may actually connect to the first instance.

If you do experience this behavior, the workaround is to specify organization unique name in the connection string, i.e. use https://org1234567.crm.dynamics.com as URL parameter.

Thanks to Clément “French but not Tanguy” Olivier for the workaround and Matt “SDK Deity” Barbour for explaining the scenario.

(Facebook/Twitter cover photo by John Carlisle on Unsplash)

Tip #1076: Add all assets to your solution

A good observation from Nick “Benchpress” Doelman that, once you click Add All Assets when adding an entity to a solution, you won’t be able to remove any of the assets of that entity. Both, Add and Remove Components buttons will be gone.

The reason is fairly straightforward (though options could have been labelled better). Add All Assets does not simply mean “I want it all now!”, it implies the future as well, i.e. “I want it all now and forever”.

Add All Assets is like a super-vindictive ex-partner: gets all your assets after the divorce and still receives a slice of any future fortunes.

When Add All Assets option is checked, you no longer control assets of the entity, you just get them all. If someone else adds, say, a view, a form, or a field to the entity, you’ll get them in your solution as well. This is in a contrast with selecting some or even all components one by one where your solution won’t automatically get the future additions.

The components are easy to miss, make sure you test the solution export after crafting your selection. As Steve “Still an MVP” Mordue has pointed out, it’s possible to inherit some invalid attributes that would require a manual intervention.

Tip #1075: Get off the bad server process

One minute your instance is humming along just fine, then suddenly it’s spewing strange errors something like

The customized site map could not be used because it is configured incorrectly. The default site map has been applied instead.
To resolve this issue, repair the customized site map and import it again.

The url, as frequently is the case, contains even more bizarre

Error Details: Sub area with id “nav_workflow” has an empty title.

The sandbox copied couple hours prior is humming along just fine, the other users report that they had this issue few minutes ago but everything is unicorns and rainbows right now.

Most likely, there was indeed a temporary issue that has been resolved but now you are stuck with the bad front-end server/process that is dealing with your requests. Quick test: if you can connect in incognito mode then the rotten service-side connection that your session is pegged to (by the application load balancer), is most likely the case.

Solution: Delete the ApplicationGatewayAffinity cookie. How exactly you do that, depends on the browser (Firefox, Chrome). You don’t even need to logoff.

(Facebook/Twitter cover photo by Denny Luan on Unsplash)

Tip #1074: The minimum you need for an opportunity

I like to keep things simple and, sometimes, Dynamics’ in-built functionality make things complicated. Opportunities (and Leads) are a good example of this. There is no doubt Dynamics 365 is great choice for managing a sales pipeline but you need to find a balance between using all the functionality provided and keeping the system flexible enough to meet unanticipated future needs as well as friendly enough that sales people will use it.

So what is the minimum you need to manage a sales pipeline in CRM?

First of all, no Products. Unless you sell well defined widgets with well defined prices, Products will need some work. Then there is the whole setting up of price lists, tax rates, and units of measure and so on. Remove Products (if you can) and things get simpler.

In terms of fields, I believe the minimum Opportunity fields you need to have a pipeline are:

  • Contact or Account (depending on whether you are selling to people or companies)
  • Estimated Revenue (how much the deal is worth)
  • Probability (so you can weight the expected revenue when projecting future sales)
  • Estimated Close Date (so you know which quarter/year/reporting period the sale will close in)
  • Status Reason (So you can categorise your pipeline)

Arguably, Status Reason could be swapped out for Stage and you could link the stage with a probability via a workflow but, again, things are getting complicated and not necessarily adding value (we are stuck with Status/Status Reason anyhow so why not use it?). In terms of automated probability, sometimes an Opportunity at an early stage is a sure thing and Opportunities at a later stage are more shaky (lawyers arguing over the contact terms anyone?) At least at the start, my preference would be to leave stage and probability unlinked and let the sales person enter the values independently.

In my experience it is better to start out with a basic system and build on it, than build a complex one and try and simplify it later. To reference my favourite quote from Civilization IV, “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

Tip #1073: The story of the small change

“It’s a small change, we don’t need to test it” said many a CRM administrator. What could go wrong?

Maybe this ancient CRM proverb will make you rethink that idea:

Because the admin added a field to the opportunity form, the field count increased beyond the mobile field count limit,
Because the field count increased beyond the mobile field count limit the form script couldn’t find the “next appointment date” field on the opportunity,
Because the form script couldn’t update the “next appointment date” field, the workflow that creates the appointment didn’t run,
Because the workflow that creates the appointment didn’t run, the sales meeting didn’t synchronize to the sales rep’s calendar,
Because the sales meeting didn’t synchronize to the sales rep’s calendar, the sales rep missed the meeting,
Because the sales rep missed the meeting, she lost the sale,
For the want of a sale, the sales rep was fired,
And all for the want of a proper testing procedure on small configuration changes.

Many variations of this proverb have appeared over the years, such as one where an administrator removes an option from an option set that makes a business rule fail, leading to corporate bankruptcy, or a configurator adding a lookup field to the accout form without granting users security permission to the lookup entity making an approval process not run, causing a nuclear power plant reactor meltdown. Whichever variation you prefer, the lesson is the same:

  • Small changes can have big consequences
  • All changes, no matter how small, need to be properly tested before moving to production
  • There is a correlation between complexity of form scripts and work flows and the amount of testing required for small changes. A form with very few automations will need minimal testing when making changes to it, a form with many complex dependent automations will require extensive testing of modifications.

Tip #1072: Open existing contact in All Contacts view

I need to get out more often. Thanks to the relevance search, I have not used All Contacts view since the awkwardly named Dynamics 365 July 2017 Update seen the light of the day. Because if I have had, I would have noticed that clicking on any contact in this view opens New form instead of opening the existing record. Demian “Sostenga mi cerveza” Raschkovan pointed that out to me and casually mentioned that copying the view and replacing the system one with the cloned copy solves the issue.

Credit is where credit due. Nishant Rana mentioned this bug in October last year. And I like the workaround by Davide (thank you – whoever you are!) – just add and remove any column, publish customizations and the system view is now working!