Dynamics 365 – Best practice to delete components

by: Robin Schaareman

In this article I would like to share some of my experience and best practices about deleting components in an unmanaged/managed environment. First you will read about the characteristics of both unmanaged and managed solutions, then a best practice to delete components and in the end a conclusion.


On several websites/articles you can find a lot of information about managed and unmanaged solutions. The most important characteristics are shown here:

Unmanaged solution

  • Flexible – you can add or remove components
  • Used in DEV environments – unmanaged solutions can be exported as managed
  • Deleting an unmanaged solution won’t remove all components in the environment. They will be available still (including the data)

Managed solution

  • Can’t add or remove components directly
  • For ISV’s a good way to implement solutions on environments
  • Deleting the managed solution will remove all components from the environment including the data attached to it

Obsolete components

Once you work with a so called DTAP (Development – Test – Acceptance – Production) street once in a while it happens that some of the components in the solution become obsolete. How to remove these properly? To make this work there are some tips and tricks to smoothen this process:

1.Remove all the dependencies of the component in the DEV environment
It is highly recommended to remove all of the dependencies of the component you want to get removed. If any of the dependencies are becoming obsolete as well, make sure to follow these steps for that component too. There are scenario’s where you remove a component in DEV and struggle to remove it in any other environment due to the dependencies of the component. If you want to remove a field, make sure to make it non searchable.

2. Check data/usage
If the component you want to remove is a field, make sure to check if that field has been used in the past couple of weeks. Sometimes fields or other components are being used in processes that are needed for other functionalities for example. Also make sure there is no data in production that needs to be preserved. Once a component is deleted the data which can be stored on it will be removed as well.

3.Rename the component
If you are working in a team it is useful to rename a component that becomes obsolete. This way everyone within the team knows that this component has no dependencies or data on it anymore and the usage of the component has been double checked. To easily find components that are obsolete put ZZ_OBSOLETE before the components name. The ZZ make sure it will be visible on the bottom of any list so you can easily delete it in other environments instead of searching for it.

4.Deploy above changes to all the environments this component is in
If the component is in Production already then it is recommended to deploy the above changes to T A and P before actually removing the component. This will minimize the problems you can encounter once you try to delete a component.

5. Deleting the component
There are several ways to delete components, but you need to start in your Development environment. After that you can use the holding solution + apply functionality during a deploy to clean any fields that are not in the solution anymore. If you are working with unmanaged solutions it is also possible to clean components directly on the environment itself (without a deploy).


There are several ways to achieve a deletion of a component in your solution, but as said before it is recommended that you discuss with your team what will be the policy on this. If you and your team have a clear understanding on what to do when deleting a component, you will minimize the number of problems/errors you can encounter.

Dynamics 365 – How to setup Email to Case management with the new ARCUR (Power Automate flow)

by: Ritchey Hazeu & Robin Schaareman

1. Setup Mailboxes

Since we were going to connect multiple mailboxes to CRM there were several options on how to do that. We chose for the option to make an Exchange Online Rule to send all incoming e-mails to one leading e-mailbox. This mailbox will receive all the e-mails of all the connected (functional) mailboxes and this leading mailbox is connected to Dynamics 365. We choose to go for one leading mailbox because you only need to setup your configurations once, instead of a unique configuration for every mailbox.

1.1 How to set up a mailbox in Dynamics 365

When connecting the mailbox make sure you got Exchange Online admin rights or Office 365 admin rights (or connect with someone who got them instead).

When creating the mailbox make sure you use the below options:

When you’re done creating the mailbox, Save, click on Approve email, after approval click on Test & Enable mailbox. The status should go to Succeeded….

If you’re forwarding a mailbox to the leading mailbox with a lot of historical data you also got the possibility to choose for a particular time to sync. This can be found in the Email Server Profile, advanced tab (sorry for the Dutch language😉):

Don’t forget to create mailboxes for outgoing email traffic. Follow the same steps as above but only select Email router for outgoing email. Users will be able to select this outgoing mailbox (connected to a queue) when creating emails.

2.ARCUR and Routing rules

The new ARCUR is being managed by a Power Automate flow (actually 2 flows) which you can create from the ARCUR data record. Within this Flow you can execute all sorts of conditions to convert the email to a case and if this is not possible place the email in the right queue.

When a case record is created from the ARCUR flow we wanted to let the routing rules decide which queue it should enter. Therefore, we placed the email addresses (To and CC) in the e-mail field on the case so the Routing rule can pick it up and route it accordingly.

One of the most important things we’ve implemented was to extract the CC email from the activity party entity related to the email record, since the out of the box activity party was not working properly in Flow.

It should look similar to the following:

After that you can place the Cc email string variable in the creation of the Case, together with the To field. The routing rule will do it’s work accordingly.

3.Lessons Learned

Since we went live, at first with a pilot of 1 e-mailbox and later on we connected more e-mailboxes, we faced some issues/situations which we need to monitor more closely or improve on next time we connect an e-mailbox.

3.1 Tracked to Dynamics (undeliverable)
We noticed that no new e-mails were coming into Dynamics 365 anymore. We checked several things and saw that our “dummy” e-mailbox was receiving all the e-mails of the connected e-mailboxes but they were not showing up in Dynamics 365 anymore. All e-mails that were in Dynamics 365 had a label “Tracked to Dynamics 365” and all e-mails that were not tracked to Dynamics 365 had a label called “Tracked to Dynamics 365 (Undeliverable)”. After quite some research on several settings we created a ticket at Microsoft because everything was setup correctly and nothing was changed since the error occurred.

After a few calls with the Microsoft team we found out that is was a known issue on their side which had something to do with the ARCUR flow. We did not check the ARCUR flow since we thought that all e-mails should be in Dynamics 365 first for ARCUR to do something with it. Unfortunately we were wrong and ARCUR can influence the behavior of emails being tracked, or not. Simple solution/work-around for now was to disable ARCUR and enable it right away. New e-mails were coming in the system again and all seems fine.

Why this occurred has not been clarified by Microsoft yet since they still work on this issue that will prevent this*. It took some time for us to figure out that turning ARCUR off and on again would do the trick, all the e-mails that were send to the ‘’dummy’’ mailbox were not processed to Dynamics 365. To trigger this again we needed to add a field to the Mailboxes field. The field is called “Process Email Received After”. Once this field was added tot the form we could change the date to the past and it will trigger the process to track e-mails to Dynamics 365 again. 

*we will try to update this blogpost if we have more information about the error in the ARCUR flow.

3.2 Monitoring
Once we had the error that e-mails were not being processed we needed to make sure that the next time this happens we needed to be informed sooner. To be faster we need to create some monitoring that will check on the categories in Outlook, once a Undeliverable category is assigned we need a signal so we can fix it right away.

The other monitoring part is maybe an overkill but it will help to grow trust in the system. Check the number of e-mails being received on the e-mailbox vs the “dummy” e-mailbox vs Dynamics 365. These numbers should add up. Once this is not the case it needs investigation on what happened so you can act accordingly.

3.3 Delay ARCUR
Dependent on how your ARCUR flow is setup you need some delays build in to make sure an E-mail is attached to the correct Queue. In essence our ARCUR is doing the following:

  • Check if the e-mail can be converted to a case, if yes a Case is created
  • If the e-mail can’t be converted to a case the e-mail is attached to a general queue

Unfortunately, this interfered with the queues that were setup. The queues were setup that if an e-mail from Mailbox X was coming into Dynamics 365 it was going to be assigned to the queue of Mailbox X as well. We found out that some of the e-mails were in the queue of Mailbox X and some of the e-mails were in the general queue. This happened because sometimes the ARCUR was faster than the Queue itself and attached the e-mail to the general queue. In other scenario’s the queue was faster which resulted in the e-mail being attached to the queue of Mailbox X and ARCUR generating an error the there was already a queue item of that e-mail. The general queue is for e-mails that could not be attached to their correct e-mailbox queue, for example an e-mail that had the attached e-mailbox in the CC instead of the TO.

To prevent this, we made a wait condition in the ARCUR flow so it could check if the e-mail was already attached to a queue. If this was not the case ARCUR can attach the e-mail in the general queue.

3.4 Duplicate e-mail
We’ve faced a scenario where emails entered CRM accordingly, got converted to a Case, but for a particular mailbox the emails were not routed to the right queue. The Routing rules were setup accordingly but after some investigation we saw a contact person record created with the same email address as the mailbox. For CRM it’s 2 duplicate records, one queue and one contact person record with the same email. For CRM it’s impossible to decide where to route it to. So our advice is, inform users to NOT create contact persons with the same email as their own mailbox.


Eventually we managed to successfully setup Case management into Dynamics 365. We encountered numerous hick-ups during the implementation which costs us a lot of time. Hopefully you can use our blogpost in your advantage to save some precious time 😊

Dynamics 365 – Tips and tricks to setup a flexible security model

By Robin Schaareman

Within Dynamics 365 a layered security model, strengthened by a Base security role, will give you and your customer maximum flexibility in configuring the system and meet the customer needs.

In this article I will try to explain from my own experience what I found valuable in designing a security model.

Start early in the process

When on a “green field” project don’t hesitate to start talking about the security model at an early stage. Some customers demand special requests that certain users/teams don’t have any access to particular data from another country for example.

When working on a global rollout or a regional one can influence your decisions in designing the model. In some countries opportunities is one of the entities that contains really sensitive data and it is particularly at risk when an employee decides to stop working for that customer. In other countries this is not an issue at all and both situations require a different approach in your security model. Some other really helpful questions that can help in designing a good security model:

  • Will the records be user or team owned?
    It can be handy to know who is owning a record… By default CRM will put the user as the owner of the record. Most of the time this is correct but, in some situations, this is rather odd. Let’s take an account for example, why is this owned by 1 person? In bigger companies which sell different products/services it is quite normal that an account can be owned by multiple people. In this case maybe a team as the owner will be a better option. Also, a totally different approach can be done via a new entity called employee’s involved, here can be a list of employees that are involved at that customer. The owner field can be hidden in that case. All of these questions/answers can impact your security role/model.
  • Can notes be visible to anyone?
    Notes are attached to records but the security is not inherited, this means that the security of the notes entity need to be setup separate.
  • Activity type entities?
    These type of entities are being managed via 1 security setup. If you can see all the activities of the whole organization this means that Tasks, Emails, Appointments, etc will be visible. It is good to talk about this upfront so there will be no surprises afterwards.

Base security role benefits

Most of us know that configuring a security role can be sensitive to “human” errors. This all has to do with all the dots you can click, or even the whole row. This and the fact that multiple roles sometimes need the same change is rather inefficient. The Base security role can simplify your security model. Give everyone in your organization a security role (name it the Base role for example) that will just give user the ability to login into Dynamics 365.

After that the role can be used to give users permissions to entities where the rules applies to all users. For example, if anyone in the organization can Read all accounts you can configure this in the base role instead of in all other roles. The change is much faster and easier to maintain. Do this for all the entities that users share privileges of. After this you can specify certain roles within the organization by just a few dots/clicks on a separate security role.

Extra dimensions

In Dynamics 365 a security role “dot” can be on User/Team, Business Unit, Parent/child Business Unit and Organization. The Business unit privilege can give a user different permission if you setup a different BU/Team structure. With a rather different structure you can create a new “dimension” to give users privileges and be more flexible in order to meet your customer needs.

Below are two examples. Let’s say we need to add a 4th team that need access to the opportunities of Team 3 and 4 only (so not Team 1 and 2). You can put the users in both teams and leave the user/team privileges on the role. But you can also add another layer to the Business units and give the role a BU privilege on opportunity. In this case Team 3 and 4 will be separate from the other teams. This extra dimension is a way to solve those requirements other than adding users to multiple teams constantly.

Diagram 1
Diagram 2

Don’t mirror the real world 

The last tip I want to give is “Don’t mirror the real world”. Yes sometimes users refer to their team or department etcetera but this does not mean you need to build this situation in the system as well. This can make things much more complicated then it should be and sometimes you need to give up some of the flexibility as well.

Dynamics 365 – Filter lookup with FetchXML (and how to deal with invalid XML format)

By Ritchey Hazeu

In some situations you can’t use the standard filtering options Dynamics 365 has to offer. For example when you use the same entity twice on a form. And you would like to lookup a new field and only filter it on the second entity.

In these cases you can use Javascript to Filter the Lookup yourself. Let’s say we are using the Order entity and want to filter a new field, let’s say Contact and filter it only on the lookup to Order on the Order form, not to the Order itself.

We will create the webresource and place it on OnChange of the Lookup. Don’t forget to check both boxes:

And how does the Javascript looks like?

function filterContactLookup(executionContext){

var formContext = executionContext.getFormContext(); // get the form context

if(formContext.getAttribute("new_orderid") != null) {

var orderField = formContext.getAttribute("new_orderid").getValue();
var orderFieldID = orderField[0].id;
var orderName = orderField[0].name;

formContext.getControl("new_contact").addPreSearch(function (){

    var fetchQuery = "<filter type='and'><condition attribute='new_orderid' operator='like' uiname='" + orderName + "' uitype='salesorder' value='" + orderFieldID + "' /></filter>";



        var fetchQueryRemove = ""




This piece of code work fine when there are no special characters being used (for example the & character). And it happens quite often that the & character is being used in a name. I’ve tried all kinds of different options to fix this, like:

var fetchQuery = fetchQuery.replace(“&”, “&amp”);

fetchQuery = “?fetchQuery=” + encodeURIComponent(fetchQuery);

All different Xrm.Encoding options as noted on https://docs.microsoft.com/hr-hr/powerapps/developer/model-driven-apps/clientapi/reference/xrm-encoding but without success

and more options which works perfectly in C#….

Gladly for me there was a much easier option, and that was simply to remove the uiname from the fetchxml, and it kept working!

function filterContactLookup(executionContext){

var formContext = executionContext.getFormContext(); // get the form context

if(formContext.getAttribute("new_orderid") != null) {

var orderField = formContext.getAttribute("new_orderid").getValue();
var orderFieldID = orderField[0].id;
var orderName = orderField[0].name;

formContext.getControl("new_contact").addPreSearch(function (){

    var fetchQuery = "<filter type='and'><condition attribute='new_orderid' operator='like' uitype='salesorder' value='" + orderFieldID + "' /></filter>";



        var fetchQueryRemove = ""




It took me a few hours to notice this…. So hopefully it will save you some time.

And please let me know if there are other options, for example when you don’t got the GUID and only the uiname.

5 Ways to Make Digital Transformation with Microsoft Dynamics 365 Actually Work (PART II)

By Bas Bergstra

In my previous blog about Digital Transformation (‘DT’) with Dynamics 365 initially the concept of DT was briefly explained by stating that it serves strategic objectives of our customers, which can be realized with support of Dynamics 365. Next, I emphasized that DT can be applied in a variety of ways. After this introduction my blog then zoomed into two ways of making DT with Dynamics 365 work. As the title suggests, it is now time to bring in three additional best practices.

The earlier discussed way number 2 for DT with Dynamics 365 regarded the importance having strong awareness of out-of-the-box features. On the other hand, it is crucial to have your semantics in place. Besides the point of that each industry or even organization is likely to have its own jargon; once having deciphered that, you may experience another haze. Often departments, teams or groups people commonly have different interpretations for the same concept. Another challenge is that you may assume familiarity of your counterpart with concepts such as Artificial Intelligence (‘AI’) and Robotic Process Automation (or ‘RPA’), but these are still not so mainstream as you might assume. Just imagine how long it took before the term ‘Internet’ was starting to resonate with your grandparents. So before introducing more advanced Dynamics 365 functionality such as Customer Insights and Lead Scoring Models, make sure to get your audience acquainted with the underlying concepts.

Finding out the DT maturity level of your customer is an effective route to determine appropriate timing of introducing Dynamics 365 features to them. This fourth way of making DT with Dynamics 365 work also relates back to the second challenge previously mentioned in this blog. The reason is that interpretation and timing often go hand in hand. Consider an example regarding a customer service manager who currently receives a weekly report on customer complaints expecting the same from the new Dynamics 365 solution.  After finding what he perceives as a ‘report’, you realize that his requirement could be met by simply providing access to of view of cases in Dynamics 365 Service. Do this instead of overwhelming him right away with Dynamics AI for Customer Service, thus time the pace of digitally transforming their processes to support customers. Remember, Rome was not built in a day either.

The last success factor for a Dynamics 365 implementation that I would like to share here regards user adoption. DT implies change and the willingness to adopt varies per user. Roughly spoken users can be grouped into three categories, i.e. 10% very open to change (referred to as pro-change opinion leader), 10% resistant to change (alias ‘con-change opinion leader’) and the opinion of the rest (80%) is likely to be affected by the opinion leaders. With tactical involvement of the group who is in favor, you are likely to win the majority also with your demonstration of added value with Dynamics 365. So, make sure to first focus on the pro-change opinion leaders and convert them into ambassadors or advocates inspiring the 80% group.

With these 5 ways you have a head start to leverage Dynamics 365 and transform your customer’s business. Please feel free to share your experiences, so I can start improving and or extend these ways in new posts.

Link to part I of this blog.

5 Ways to Make Digital Transformation with Microsoft Dynamics 365 Actually Work – Part I

By Bas Bergstra

Experienced with Microsoft Dynamics 365 implementations for some time now? Then you are probably also familiar with the term Digital Transformation. Even more so, chances are that if you have been working with Dynamics 365 for more than a few years, you probably already were helping transform the business of your customer before Digital Transformation became a buzz word.

Still, even though Dynamics 365 each year is well positioned in Gartner its Magic Quadrant for CRM and enjoying a steady growth of its user base, there are still many challenges to overcome when transforming organizations with that platform.

As a Consultant having worked with Dynamics 365 Customer Engagement (previously known as ‘CRM’) for many years now, I can totally relate to the challenges that we can run into.

Before zooming into the confrontations that might arise during your projects, let us break down the term Digital Transformation (‘DT’). The reason is that DT actually serves a goal, while technology such as Dynamics 365 is merely a mean to achieve the strategic objectives of our customers.

DT as a concept can be widely interpreted. Some organizations consider having a chatbot added to their website as a transformation in the way they provide service to customers, while others apply innovative technology to completely revolutionize business models in industries. Typical examples of disruptors such as Tesla, AirBNB and Uber have by now actually become a bit stale but are useful to illustrate the other side of the spectrum.

When looking at your typical project involving Dynamics 365 let us assume there is some degree of DT that your client is aiming for. Regardless to which extent ambitions are set, expectations regarding the level Dynamics 365 can meet then will be high. Especially when clients have completed a laborious RFI- and RFP process. The first challenge is then to manage their assumptions regarding the platform; this requires broad and detailed knowledge of the (latest) features.

Having completed the appropriate Microsoft certifications will certainly help a lot, even for the more seasoned consultants. This is contrary to a surprisingly common belief that learning theory only serves to successfully complete the exams. The actual benefit of certification is that it will trigger you to familiarize extensively with Out-of-the-Box features. For those of you who are still skeptical, the key is that preparing for an exam pushes you further and thereby encourages true commitment. Obvious reasons are the fact that you will then have a deadline to have completed your studying and the fact that Microsoft Learn is covering topics more extensively and effectively than ever before. In addition, checking YouTube offers tons of material, also listen to the relevant Pod casts to keep up.

With thorough knowledge of the Dynamics 365 features you might expect to be on pretty solid ground, when starting to engage with customers to determine a fit or gap for their requirements. And yes, as a starting point you are correct with that, but there is off course a ‘but’ leading to the second challenge. 

Customers typically do not express requirements for easy mapping to Dynamics 365. More often than not, specifications seem to demand for something different than what you learned when preparing for the Microsoft certifications. A common example is whether to map requirement for prospect management to the Out-of-the-Box entity Lead, Account or even Contact (in a Business-to-Consumer context).

Still, when having successfully completed the Dynamics 365 Sales exam you probably are able to effectively explain each feature and then together decide the adequateness accordingly. The key here is to consider standard functionality before entering the world of reinventing the wheel, by e.g. creating your own custom entity to manage a Prospect. A major drawback is that such entity will not leverage neat features such as seamless conversion of customer touch-points (i.e. activities such as e-mail or a web site visit) into a Lead for follow-up.

This concludes the first two ways to make DT with Dynamics 365 successful. Make sure to check my next blog with the more best-practices. Naturally I also highly value your feedback.

Link to part II of this blog.

Dynamics 365 – Security role Flow / Power Automate

By Ritchey Hazeu

You’ve build a Flow as an admin, deployed this flow to the next environment but none of your users are seeing this Flow.

Sound familiar? Read the following:

Besides activating Power Automate in your system settings (Settings -> Administration -> System Settings -> Customization -> Enable Microsoft Flow) there is also a privilege in the Security roles:

Navigate to one of your security roles and go to the Customization tab.

Below you will find “Run Flows”.

Dynamics 365 – Transition to Unified Interface

By Robin Schaareman

Earlier Microsoft announced that in October this year (2020) cloud organizations need to be on the newest Unified Interface. Via the website https://runone.powerappsportals.com you can check what date is set for your own environments. You can postpone this date to a date which suit you and/or your organization more. Be aware that 1st of October is the deadline, after this all environments should be on the Unified Interface.

On the Microsoft website you can find a lot of information how to check whether your solution is ready for the Unified Interface. Most of the information will be about if the technical parts in your solution will still function after you transition to the Unified Interface. However this is really important it is just as important that all the end users will benefit/work with the new interface as well.

Since it has been changed a lot it is good to discuss a suitable approach to implement this feature. Via this blog I will share my approach in how I implement the new Unified Interface at a customer. It might be a standard approach but in my experience this was effective enough to bring the new feature in the organization.

  • Prepare with your team

Before you inform the users about this new feature it is important to check if your solution is applicable. If this is the case you can create a new App within Dynamics 365. This app can be used for testing all the forms etc and see how it looks. If it all looks good you can strip this new app to make the sitemap just with the minimal entities needed for sales to do their work. For example, accounts, contacts, activities and opportunities. This will be the app that will be used during a pilot period with the users. Create a separate security role so the users that will attend the pilot can access the new app.

  • Inform important stakeholders/champions

Most of the time at a customer there are some enthusiastic users which are happy to hear about new features or changes. These users can help you get a platform to all other users and make them enthusiastic as well! Get those people in a room and inform them about the new Unified Interface. Show them the benefits of the new interface (its faster than the “old” version 😉) and discuss your plan in how to implement this new feature. Important outcome in this meeting is a date and a list of users that can attend the demo/pilot.

  • Give a demo to the users + surprise pilot!

After you have set a date with the stakeholders you can give a demo to a group of users that will attend a pilot (which they don’t know yet!). During this presentation you can show the new Unified Interface and all the benefits that comes with it (tablet/mobile version etc). At the end you have a small surprise, users that want to attend a pilot can start with that right after the meeting. Show the users that they can access the new features via the new app and at all times can switch back to the more familiar interface (if they get stuck or something). Also try to explain that they work within the same database.

  • Discuss the outcome and way forward

During the pilot you need to be pro active and ask pilot users how it is going. If they found any issues or have recommendations just write them down and discuss them with your team and the other stakeholders. In the end you can facilitate a meeting with all the pilot users to discuss the outcome and which of the feedback will be implemented before the release. After that you can propose a date to go live 😊 at the beginning you can still make an app which contains the old version of the UI. For some users this can be helpful in the transition to the new UI. Like I said, pretty straight forward but in my opinion an effective way to implement the new UI. Hope this helps