When working with the Form Component Control feature you can easily make editable forms on related entities, just by adding the corresponding lookup and change the control to Form Component Control. There’s loads of blogs on this already, but could not find anything on how to solve the problem that the wrong form is showing, even if the GUID you’re using (after checking 100 times) is the correct one!
It could be 1: Glitch from Microsoft, you can solve it by re-adding the lookup to the form. This actually solved our problem.
2: The form you are using in the component control is not added to the App you are using. We were using the Customer Workspace App and forgot to add the component control form to the App in the solution, because we created a fresh form only for the component control. So when we were using the App, it could not find the corresponding form.
3: The correct security roles are not assigned to the form! This is what you only check when building the form and forget about when you use that same form in your component control!
or 4: You’ve created your form as a Quick View Form. Currently only MAIN forms are supported by Microsoft.
When you try to Qualify your Lead your Dynamics 365 will quite often encounter the error: “You do not have {0} permission to access {1} records”
In our case the user did not have access to the Sharepoint Document Location entity. Also known as: the Document Location entity, which can be found in the Core records tab on the security role.
You can find which privilege your user is missing by clicking the F12 button and read the error message from the console!
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.
Characteristics
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).
Conclusion
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.
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.
4.Conclusion
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 😊
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 1Diagram 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.
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>";
formContext.getControl("new_contact").addCustomFilter(fetchQuery);
});
formContext.getControl("new_contact").removePreSearch(function(){
var fetchQueryRemove = ""
formContext.getControl("new_contact").addCustomFilter(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:
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>";
formContext.getControl("new_contact").addCustomFilter(fetchQuery);
});
formContext.getControl("new_contact").removePreSearch(function(){
var fetchQueryRemove = ""
formContext.getControl("new_contact").addCustomFilter(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.
Hi! In this webinar I would like to show you the handover from Dynamics 365 for Marketing to Dynamics 365 for Sales and how things around that can be automated with the Power Platform.
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.
