Tip #969: The problem with sharing

Does Microsoft have guidance about how much sharing is too much? — CRMTOD reader

I find it hard to believe we have gone 968 tips without talking about the risks of excessive sharing in Dynamics 365. Few features in CRM parallel sharing on the “this is the best thing ever/this is my worst nightmare” scale.

How record based security can be used to control access to records in Microsoft Dynamics 365.

The good

Sharing is a good feature, because it gives administrators and users with the appropriate permission the ability to grant specific permissions to specific records, and is useful for handling exceptions to the rule. Need to have salesperson 2 handle salesperson 1’s accounts while she is out for a month filming Survivor season 83? Sharing can do that. Sharing can also be automated, meaning that if you have a need for a specific condition to automatically share records with a user or team, simple plugins, workflow assemblies, or Scribe can be used to do that. This has been the answer to many Dynamics clients funky security requirements.

The bad

While a very useful feature, sharing has a dark side.

  • Performance: sharing is facilitated by the Principal Object Access (POA) table. When you share a record with a user or team, a record is created in the POA table containing the ID of the user, the ID of the record, and the permission that he or she should have. But that’s not all! The cascading nature of sharing means that if a parental or configurable cascading relationship exists that is sharing enabled, the child records in those relationships will also be shared with the user or team (and additional records will be added to POA). There is also a bunch of murky reparent/inherited share scenarios that can also create records, which can cause the POA table to grow quickly.  This becomes a performance issue when the table gets extremely large (somewhere between 20 million and 2 billion records). When you query CRM, such as opening a view, advanced find, or viewing a chart, the results are filtered by the POA table. If the table is quite large or indexes are not optimized, this can lead to very slow system performance.
  • Administrator’s nightmare: Quick–show me which records are shared with Bob. You can’t do it. While you can click on a record and show who it is directly shared with, there is no way to easily do that for all records. Also, cascading/inherited shares don’t show in the sharing dialog on the record. Without opening each record in the context of that user, it is virtually iimpossible to know if your sharing strategy is working correctly
  • Forgotten shares: Remember that sales rep you shared the records with while her buddy was off for a month? Odds are you will forget to unshare those records. Got a workflow that automatically shares record with Tim if they are in Seskatchewan and the plumbing industry? Well Tim moved to a different industry vertical last month. Did your workflow remember to unshare all of those records?
  • Can’t “make it right”: After you use the system for a year or two, you may find that things get a bit off or you decide to make a wholesale change to your sharing strategy, so you want to run a “make it right” batch job to set/update all records with the appropriate sharing permission. There is no easy way to do this with sharing.

The answer

So to answer the question, yes, Microsoft does offer some guidance (if you are on premises) to optimizing and controlling growth of your POA table. But probably the best guide to understanding the POA table comes from this classic post from Scott Sewell. In it he explains how to decode the structure of the POA table and understand how your sharing strategy will impact database size. He also offers a Excel based decoder tool to encode/decode the POA table. Unfortunately the link in that post to the secret decoder ring is no longer valid, but Scott has located that file and you can download it here.

So now that you understand how the POA works, what are some steps that you can take to avoid the dark side of sharing?

  • Team ownership: In the old days, teams couldn’t own records, so we had to share to grant multiple people access to a record, without granting access to the entire business unit. With team ownership, you can assign records to teams of users in multiple business units.
  • Share with teams, not users. If you share a record with 10 users, 10 POA records are created, X 10 POA records for each child cascading shared record. If you share the record with a team with ten users, only one POA record is created (along with 1 POA record for each cascading share). This will dramatically reduce the size of your POA table. Want to take away a user’s permissions? Remove them from the team.
  • Use access teams for controlled sharing. So you can’t do owner teams, but you still want to be able to grant ad-hoc access to records to specific users. Some you want to just read the record, some you want read/write. Access teams can handle that, and you can have multiple access team profiles, one for read, one for read/write. Access teams are designed with performance in mind, so they don’t actually create the team and share the record until you add the first member of the team.

The real beauty of the team approach, be it owner or access team, is that it makes it much easier to see what records a user has, just by seeing what teams he or she is a member of. If you want to run a “make it right” batch job to reset all sharing permissions, you can do that by wiping out your team membership and then running a SSIS or Scribe job to populate the teams based on the new logic.

So please share your toys and Dynamics record access, but do it wisely.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #968: Should I modify system reports?

There are 26 system SSRS reports (not counting subreports) that come with Dynamics 365. If you find one that is close to what you need (like the quote report), should you modify the system report?

I say no. Here is why:

  • System reports currently in Dynamics 365 are the same system reports that were in Dynamics CRM 3.0 (for the most part). They were written by someone who is probably no longer at Microsoft. When you dig into the RDL you will find that the most basic system reports include a lot of overhead and things like system reporting parameters that are not documented in the SDK.
  • Even though the system reports have not changed much over the years, upgrades will sometimes overwrite/republish system reports. So if you modify the system reports, there is a possibility that a future upgrade could overwrite your changes.
  • If you are online, you will find that some system reports still use T-SQL queries, while that is not allowed for us mortals. Microsoft sometimes gives themselves special dispensation to to things that we can’t. So if you want to copy the report and modify it, you will likely need to convert your copy to FetchXML.

For these reasons, other than minor/cosmetic changes to reports, my recommendation is do not modify the system reports. A good SSRS report writer can recreate the system report faster than she or he will be able to decode what somebody who is no longer at Microsoft was doing 10 years ago.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #967: UI testing for Dynamics 365

Software testing is important and Dynamics 365 is no exception. Fundamentally, developing for Dynamics 365 is different from developing, say, an ASP.NET MVC application but, users don’t really care, do they? It’s a software that hopefully delivers business value, deal with it.

Developers who recognize the importance of the process, have always been making inroads into unit testing of the code they create, be it for the plugins to deliver magic on the server or javascript for the client-side functionality. Plenty of frameworks to choose from. For the C#, some developers prefer Moqs, some like Microsof Fakes, some even created CRM-specific agnostic frameworks. For javascript zealots, QUnit can be used for browser-based testing, something much more elaborate to step outside the browser, or, more recently, using Jasmine.

That’s all great but, technically, users don’t really care because with all these frameworks we’re not testing user experience.

Great news though, we now have a preview release of the UI Automation Library for Dynamics 365 CE and CRM. It comes from the Dynamics 365 team at Microsoft and is based on Selenium. I’m just going to copy their description verbatim because it sums up the purpose and the functionality really well:

The purpose of this library is to provide Dynamics customers the ability to facilitate automated UI testing for their projects. These API’s provide an easy to use set of commands that make setting up UI testing quick and easy. The functionality provided covers the core CRM commands that end users would perform on a typical workday and working to extend that coverage to more functionality.

This is great news and, in fact, it looks like the last missing piece of the fully automated testing pipeline.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #966: E-mail integration in team or department deployment

MailboxesJoel has been producing tips by a truckload, I don’t think he’ll notice if I sneak this one in, especially when a fellow comrade developer David “Xrm.Tools” Yack is in pain.


Anyone have any suggestions for where let’s say a Team/Department gets CRM in their own subscription but their e-mail is still managed by a their corporate email server totally outside of the CRM subscription and their control.

They would like to have some of the goodness of e-mail integration with Dynamics 365, but have no ability to influence the corporate email strategy.

Any creative suggestions?


I have done that exact scenario with a forward mailbox. If the forward mailbox is on the domain and the email address of the forwarded email matches the address on a queue or user, the emails can be created in CRM.

Tîpp Jäår

Joel has written about forward mailbox many moons ago, worth another read.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #965: Pass Parameters to Quick Create Form

If additional initialization logic is required when a form is opened, Dynamics 365 offers a choice between setting default field values (easy) and configuring custom parameters (not as easy but straightforward).

Quick forms also take parameters when opened. But, as Daryl “Always Raising” LaBar has discovered, sometimes it just does not work.

Short version: If you’re adding form parameters to a quick create form, always remember to add them to the default form as well, even if it “works” on your machine.

Long version: Go and read Daryl’s adventures in the local storage, if you feel like reading about a good lesson in investigative development.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #964: Use latest language features

I often find that developers like comfort zones. They tend to use the constructs that they already know and are comfortable with. That includes language features as well. However, programming languages are evolving all the time and new features are introduced with every new release. Those features aren’t just cool, they make developer’s life much easier in a lot of cases.

One of my favorites is interpolated strings, introduced almost 3 years ago in C# 6.0. Instead of:

  "Name is {0} {1}", c.firstname, c.lastname));

you can now write:

  $"Name is {c.firstname} {c.lastname}");

(Did I also tell you to stop using Console.WriteLine and start using Trace.WriteLine instead? No? That’d be the tip for another day then)

The way I see it, not only this new syntax allows for cleaner and more concise code, it implictly adds value to everything you create by sprinkling your code with dollar signs.

Of course, there are a lot more goodies in version 6.0 than just interpolated strings. There are null-conditional operators, exception filters, index initializers, to name but a few.

And don’t forget C# version 7 either, with out parameters, pattern matching, is-expressions, tuple types and literals, deconstruction, and many others. Like, how cool is this:

(string, string) LookupName(Guid id)
  // ... get those names
    return (first, last);

Languages evolve and so should your knowledge of them. So, what’s your favorite feature?

Share on FacebookTweet about this on TwitterShare on Google+

Tip #963: Minimum portal licensing requirements

Only someone as thorough as Feridun “Best Twitter Handle for CRM MVP” Kadir would spend their time analysing changes in the new (July 2017) edition of Dynamics 365 Enterprise edition Licensing Guide. As it turned out, it was a very good idea.

Until now, one could purchase just a single Team Member license, and get themselves a Dynamics 365 instance, a sandbox, and a portal merely for $10. Well, not anymore. Straight from the document, broken down to the separate bullet points:

  • Starting August 1st, 2017, access to the first included portal for the tenant, customers will be required to purchase a minimum of 5 Full User licenses of Dynamics 365 Customer Engagement Plan, standalone Dynamics 365 Applications (Sales, Customer Service, Field Service or Project Service Automation) or a combination.
  • Existing customers will not be impacted with this change until renewal.
  • New customers who need to purchase less than 5 users, may purchase the Portal “Add-on”.
  • Team Member Licenses will not contribute to the minimum user requirement

In other words: if you were legitimately using single team member license to get the portal, you are good until the next renewal, at which time you’d have to buy either portal add-on, of 5 full user licenses.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #962: Microsoft Portals Source Code Is Available

After a very short private preview program, Microsoft has just made the source code for the Dynamics 365 Portals available on the Microsoft Download Center. We’ve already reviewed the topic on the podcast but this milestone is quite significant to deserve another discussion.


One-off release of portal source code is available for download. If you’d like to contribute, head off to the community edition. If you crave some official training, Dynamics Learning Portal is the place.


It’s the full source code of the Microsoft Portals version 8.3 as of July 2017, released under MIT license. The downloads contains:

  • Microsoft Portals solutions. Portals run entirely “off” the Dynamics 365 Customer Engagement deployment and will need a number of solutions installed in your organization instance.
  • The source code. Visual Studio solution, some libraries that couldn’t be added via nuget, some docs and samples.
  • The deployment instructions for the source code.

The drop comes with some strings attached:

  • It’s unsupported. Do not call Microsoft if your code does not compile or if it’s just wiped out your entire Dynamics 365 instance.
  • It’s a one time release. Do not expect Microsoft to maintain this code or release any future versions of it.
  • Portal solutions distributed as part of the release are managed. The solutions are not just web resources and schema changes, there are also plugins and workflow custom actions that do not have the source code included. I’m not quite sure what to make out of it yet and how does it impact future compatibility.


I can think of quite a few audiences who would benefit from the code release:

  • Existing customers who use Adxstudio 7.0 or prior versions. These were left in limbo when Microsoft cut off all future developments of that “branch” and imposed some restrictions on Adxstudio portals support.
  • Dynamics 365 customers with unique portal requirements that cannot be satisfied by the Microsoft version. Think integrations with third-parties, payment gateways, micro services.
  • Customers in the restricted environments with the stern security demands making it impossible to go with either Dynamics 365 Online or Microsoft portals.
  • ISVs who can offer additional value with custom components.
  • VARs who can no longer feel restrained when discussing solution architectures and portal opportunities with their prospects and customers.
  • Consultants who can now offer migration, support, and training services around rejuvenated portal community.
  • Microsoft Azure accounting team raking in fees from the cloud deployments of the private portals.
  • Curious developers who would like to peek “under the hood”. Portal source code is a great research resource to see how things should be done. And how they shouldn’t be done.
  • Curious developers who graduated from “peeking” to contributing to the open source. Great opportunity to take part in the community efforts.
  • Commercial water cooler suppliers, soft drinks vendors, and local pizza joints who would benefit from the increased consumption by the developers engaged in the heated discussions while consuming obscene quantities of the said beverages and pepperoni slices.


First of all, kudos to the portal team because it’s hard to underestimate the skills required to navigate both the technical and legal complexities of the public source code release at Microsoft, even for the company routinely releasing the entire .NET as an open source. Heck, we are still waiting for the open source version of the Microsoft Dynamics 365 Developer Toolkit so that we can make it work with the latest two releases of Visual Studio.

We probably will never know the full story behind this one-off release but I couldn’t resist the opportunity to speculate.

Hosted-only shared portal model comes with some incredible challenges to provide a solid extensibility model, both flexible and safe. There are many obstacles and challenges including technical – what extensibility model to offer and how to package the extensions, devops – how to provide the private deployment facilities while maintaining SLAs for everyone, security – how to guarantee safety in the shared environment, support – how to provide for generic baseline support with tons of custom code deployed, and legal – how to address concerns of corporate customers around arbitrary code deployment and execution without opting for the revenue killing “one customer – one enviroment” model?

Add to that the exciting but turbulent times for Dynamics 365 platform with so many new features, capabilities, and requirements. The last thing we’d want is a solution rushed through just to appease some customers and then deprecated and killed couple years later because it was poorely thought through, turned out to be utterly uncompetitive, useless, and generally dead on arrival. Dynamics-cough-Marketing.

The entire Dynamics 365 ecosystem has been evolving as a rapid release environment which routinely takes away one of the most precious resources – time.

With the source code release, the portal team bought some time to properly design a sustainable extensibility model

Microsoft was also risking a revolt in the existing customer base of Adxstudio 7.0 portals, who has just until recently paid over $10K for the portal license. These customers havw invested a lot of money and resources into extending and developing their portals and wanted some clear upgrade path that would see them moving forward. With the source code release Microsoft has shifted the responsibility of upgrading and maintaining the existing Adxstudio portals to the customers.

Did Microsoft just wash their hands on Adxstudio customers with the source code release?

First of all, Adxstudio version 7.0.0018 or higher is still supported (read the article to understand the preconditions and the channels). And let’s be honest, customers and consultants who heavily customised the portals have always had sufficient skills and resources to deliver those customizations and, by proxy, to maintain the code base. Calling support in the environments with the mix of Microsoft and proprietary source code has always been a challenging exercise with volatile results.

Larger organizations have always been more or less self-sufficient when it comes to the portal extensions. Code release simply extends these capabilities without placing Microsoft in awkward position of eternally supporting legacy products by the virtue of sitting on the compiled code base without a suitable license model.

As I mentioned before, the situations is less clear about the extensions that are part of managed portal solutions, how complex is the functionality delivered by the plugins, is it critical or not, and whether it’d be feasible and permissible to replicate it [in the open source] – I’m sure these questions will be answered in due course.


Source code itself and a number of accompanying libraries is released under MIT license which is arguably one of the most permissive open source licenses. Do what you want with it, in other words.

Some of the included packages use different licenses, BSD, Apache, and Microsoft’s own Public License (Ms-PL). Pay attention to those, especially if you are in the corporate land or if you plan to release commercial products based on or around the released source code.

Call to action

Download, read instructions, play with it, and send your tips to jar@crmtipoftheday.com.

As far as source code is concerned, Adoxio, the phoenix business after the Microsoft’s acquisition of Adxstudio, has already put their hand up as a custodian of the publicly available source code, a.k.a. xRM Portals Community Edition.

Some may object but let’s be honest, with their expertise Adoxio is in a unique position to both ensure reasonable quality of the code and provide ongoing enhancements contributed by the community and Adoxio themselves. I do hope that one of the first developments will be a clear migration path for Adxstudio 7.0 owners to the whatever version we now have as open source. If you would like to contribute, go ahead, fork the project, do you craft and then submit a pull request.

Last but not least, if you would like to get up to speed with the portal extensibility using that source code (and portals in general), check out Dynamics Learning Portal for the upcoming Develop Dynamics 365 Portals courses. The curriculum is currently being updated to include self-deployment and extensibility scenarios, with new coding exercises to keep your brains busy and your hands dirty. First in-person class will be in New Zealand in October. If you cannot make it down under or prefer to get some portal wisdom in your pyjamas, virtual deliveries will start in November in PDT and HKT timezones.

If you can’t wait that long, teach yourself, listen to the community, organize your private training, or attend one of the portal training classes during D365UG Summit or eXtreme365 (details TBD for that one).

Share on FacebookTweet about this on TwitterShare on Google+

Tip #961: When you want Resco

I’m a big fan of the Dynamics 365 mobile apps. I’ve written a book about it, I present CRMUG summit sessions about it, and I fight the misguided app reviewers about it. However, there are several scenarios where it may not be the best fit, and a good third party mobile app (like Resco) is a better choice.

The following are some of the primary scenarios where Resco may be a better fit than the standard Dynamics 365 mobile app:

  • You want a different form for mobile. Dynamics 365 mobile is based on the strategy “design once, deploy anywhere.” This means that users on mobile see the same form that users in the web client see. There is not a “mobile only” form (the one you see that says “mobile” is for the old Mobile Express). For many users, this works great, but in some scenarios, having a form that is radically different on mobile makes sense.
  • You are on premises but don’t want to turn on ADFS. Dynamics 365 mobile assumes that you are running claims based authentication with IFD. If you can’t get your information security team to approve ADFS, Resco is an option to have mobile CRM without IFD.
  • You want to use entities that are not available on Dynamics 365 mobile. As we have covered in numerous tips, the list of system entities that are not available on mobile has shrunk in recent years, but if you have to have campaigns, campaign responses, letters, or some of the other entities that don’t work on Dynamics 365 mobile, Resco is a great option. It can even send email activities directly from the app.
  • You want document integration from mobile but don’t yet have server-side SharePoint. As we have covered here, the client-side SharePoint grid control is deprecated in version 9, but say you still have SharePoint 2010 integrated with CRM 2016? The only option to see documents in Dynamics 365 mobile is server-side SharePoint integration, which requires SharePoint 2013 or later. Instead of waiting until SharePoint is upgraded to see documents on mobile, Resco can work with the grid control based SharePoint document integration and display CRM documents in mobile.
  • Mobile mapping: Bing maps are available with the Windows version of Dynamics 365 mobile; however, you do not have maps with the iOS or Android versions of the standard Dynamics 365 mobile apps. Resco includes mapping on all versions, and it integrates with the device GPS and geocoding (lat/long) on records to not only display the address of a record, but also show the location of the user/device. So it not only can show you where a customer is, but also help you get there.

What’s the point?

The point is not Dynamics mobile bad, Resco good. Dynamics 365 mobile provides a very fully featured experience that will meet the needs of many Dynamics users. But my motto is “use the right tool for the job.” Keep in mind that it’s not either/or. You can easily have some users using standard Dynamics 365 mobile while others are using Resco.

What do you think? Leave a comment letting us know what you use, and why.

Share on FacebookTweet about this on TwitterShare on Google+

Tip #960: If your FetchXML-based report preview is not working

You are writing a FetchXML based custom SSRS report . When you click the “preview” tab in SQL data tools, the report runs without error, but does not display correctly. Maybe there are records missing, or you enter a parameter value that should return data, and it does not display any results. Is your report wrong? Are you crazy?


The answer is maybe, but probably not. You are likely running into what almost every FetchXML report author has experienced from time to time–when you preview a report in SQL data tools, the Report Authoring Extensions only retrieve the first 250 records. So if you select a parameter value that doesn’t have any results in the first 250 rows, your report will not display any data.

That’s why the first rule of FetchXML SSRS Report test club is

Test the report in CRM, not in Visual Studio

(Rule number two is move to a more powerful reporting platform like Power BI).

Share on FacebookTweet about this on TwitterShare on Google+