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.
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
Some things you run into make you go: ‘Oh yeah, totally forgot about that’. I hope most of you don’t have this happen all that often. I ran into one of them a few days ago and thought I’d share.
I was adding a custom filter to a lookup-view in the business process flow, as you can’t change the view in version 8.2 of Dynamics 365 via normal configuration. I ran into a problem where the filter worked on some fields in the flow, but not all. After spending quite some time on this I came to the below conclusions.
When customizing the business process flow via Javascript, you have to take into account that Dynamics adds ‘header_process_’ as a prefix to your fieldname. In addition, there is something else Dynamics does that is less obvious, and maybe less known as it won’t occur all the time. Dynamics adds a postfix of _X to each field that’s repeated in the same business process flow. X here is the next occurrence, starting with 1. The reason this is hard to spot is that it happens all the way at the end of the schema name of a field. Even if you use a tool like the Power Pane (which I would recommend), you probably won’t see the postfix in the schame name unless you hover over it to appear in full.
In my specific case, I work with a branched business process flow in which two similar stages exist, but you only ever see one of them. The invisible stages of the business process flow are also taken into account when the postfixes are appended. I didn’t know about this, and didn’t look closely enough at the exact schema names!
Another reason the search can take so long is that your code doesn’t actually give any errors. It simply doesn’t execute!
By Ritchey Hazeu (Dynamics 365 Consultant @ Capgemini)
This time: Tools!
When you’re surrounded by developers, you hear a lot of tools which they use to manage their code. They are talking about Visual Studio, Plugin registration tool, SDK, Azure DevOps Server (before TFS), etc. In this blog we will tell you more about those tools and how they are being used.
Visual Studio
VS is being used by developers to develop new functionality. VS supports 36 different program languages, has a built-in debugger (a tool to write good code) and a code profiler (measures the functions which are created by the developers).
Azure DevOps Server (before TFS)
When you’re working in a team with multiple developers and they are all creating code in Visual Studio you need a place to store this code. You also need to make sure there is a version control. When developer A is working on a piece of code, developer B needs to be aware of this. Azure DevOps Server (before TFS) is providing this so called ‘source code management’. The most powerful thing Azure DevOps Server (before TFS) provides is that it covers the application lifecycle. When you want the store the code in the cloud the name is Azure DevOps (before it was called VSTS), and the code is stored in Azure.
SDK (Software Development Kit)
When developers first start working with Dynamics CRM they will download the SDK because it contains the following:
‘The SDK includes an architectural overview of Dynamics 365, the entity model, security model, and web services. Sample code and walkthroughs are provided to guide you through the new features. It also contains information for developers who customize the web client or Dynamics 365 for Microsoft Office Outlook, including scripting, integration of custom webpages, and sample code’ (quoted from https://www.microsoft.com/en-us/download/details.aspx?id=50032)
If will give the developers a bunch of insights in the code which they can use to start off with their own developments.
Plugin Registration Tool
Before we will explain this tool, we need to know what plugins are. A plug-in is a custom made (C# or .net) function that is used to extend the standard functionality Dynamics CRM offers. They can run synchronous & asynchronous, when you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes. Plugin act on a certain event in CRM.
An example: You want to automatically send out an e-mail to your customer when the SLA of the case is breached.
The plugin is being created in Visual Studio, with the use of the SDK (you need to include references to Microsoft.Xrm.Sdk) and stored in Azure DevOps Server (before TFS). The plugin is registered in the Plugin registration tool, with the tool you can connect your plugin to different instances in CRM.
Custom Workflow
Plugins can be executed on a wide range of events on a CRM entity. Custom workflows are bound to the events which you can see in the CRM application (Create, Update, Status Change, Delete and On assign). Workflows are instead giving (non-technical) users more insight in the process because it’s visible in CRM, unlike the plugin process.
Another difference between workflows and plugin is that workflows are running async and plugins are running sync (read a little bit back for the explanation).
When you create a Custom workflow you also create an assembly and register this just like a Plugin.
Next article will be about the Architecture of a CRM (on-premise) environment!
By Robin Pietens (Dynamics 365 Consultant @ Capgemini)
For those that have not yet heard: Microsoft has decided to deprecate the use of Xrm.Page.
Microsoft did indicate their understanding that this feature is used a lot, so they will retain compatibility with it for quite some time. However, new functions should be written in a way that is as future-proof as possible right? For some reason I was unable to easilly find a nice overview of what we should change to deal with this deprecation, and I decided to do something about that.
So where we used to write:
function doSomething(){
var some = Xrm.Page.getAttribute("new_some").getValue();
var action = Xrm.Page.getAttribute("new_action").getValue();
console.log(some + " " + action);
}
We should now do something else, and write:
function doSomething(executionContext){
var formContext = executionContext.getFormContext(); // get formContext
// use formContext instead of Xrm.Page
var some = formContext.getAttribute("new_some").getValue();
var action = formContext.getAttribute("new_action").getValue();
console.log(some + " " + action);
}
The other thing to do is to check the box of ‘pass execution context as first parameter’ when setting up the function on the form. If you, like me, make parameters of just about anything, simply pass them with comma’s separated from the executioncontext. Then put everything except the executioncontext in the box as comma separated parameters that will be passed to the function:
And the function itself will look like this:
function doSomething(executionContext, firstparam, secondparam){
var formContext = executionContext.getFormContext(); // get formContext
var some = formContext.getAttribute(firstparam).getValue();
var action = formContext.getAttribute(secondparam).getValue();
console.log(some + " " + action);
}
Any new Scripts that you write should conform to the standard outlined in this blogpost. When making changes to existing libraries, it’s a good idea to take it into account as well. Talk the costs and benefits through with your customer, to keep them as upgrade-proof as possible!
If you want to stay up-to-date with features like this one, keep an eye out for new blogposts and follow us on LinkedIn.
By Robin Schaareman (Dynamics 365 Consultant @ Capgemini)
We have all probably seen a situation like this before, a customer has a Dynamics CRM/365 solution which is in use for several years but the adoption of the system is not satisfying enough. The client asks you to help improve their user adoption of Dynamics CRM/365. Improve user adoption is not an easy task. Via this article I want to give some tips/guidelines that can be used to help a customer improve their user adoption. Let’s start at the beginning….
1.Back to the beginning
To make sure you can start off with a solid solution for your client you need to take them back to the beginning. Why was CRM introduced in the first place? Did CRM solve the problem the client had? These are typical questions you can ask your customer in order to get a good picture of the situation.
2.Demonstrate the benefits
There will always be users that did not have a problem with the previous way of working and don’t see the value of the CRM system. Therefor it is extremely important to show the benefits of the CRM system. Even when the system has been live for some time it can be good to demonstrate new features or updates.
3.Involve users
Always involve the “daily” users when it comes to maintenance or development of the CRM system. Give them a voice when it comes to new features or changes in the system. This can be done via several ways. The most important one is communicating about the CRM system. New features, roadmap, tips and tricks etc. Try to find topics which suit the users most so they are actually interested in the message you are spreading. This is one way of communicating, you can also try to organize workshops/training sessions every now and then to demo new features. These sessions are also a great way to interact with the end user!
4.Recruit champions!
Reach out to enthusiastic and influential business users to help improve user adoption. This will help with the overall usage of CRM. These so-called champions (this is just an example, you can name this group of people to your liking 😊) are the first point of contact for the other users. They are willing to help other users understand the system and are very valuable for you when it comes to information. Not every user complains via the helpdesk or via a ticketing system about the struggles they have with the system. Champions who are working with these users will pick up some of these complaints, and can inform you, the developper, and even help you think of a solution!
5. Keep it simple
CRM is very complex and can be confusing at some points. Keep the interface (e.g. forms ) clean with attributes that users currently need. A cluttered interface won’t help in making the system easy to work with. This can be done via some best practises for example; WYSIATI (What You See Is All There Is) and to let the user flow through the form with the help of a business process flow.
6. Sharing is caring
It can be hard in some environments to make this happen but keep in mind that CRM works best if you share the information in it. Dashboards, reports and views will be more valuable if there is a lot of data that can be used. Try to demo this to the business more often to show the benefits, this will help in security discussions you might have with compliance.
7. Accessibility
Make the CRM system accessible in various ways so the user can interact with CRM which suits them best. Tablet or Phone, but also on the browser and via the Outlook app! All these ways contribute in user adoption since these options will help the user create records easily.
8. Keep up the pace
And at last, keep up the pace! If your time to market is short, users will come to an understanding, that giving feedback about the system actually changes it as well. This will motivate users to actively think about their CRM system.
