Speaking with Guro about her collection of dresses (can you guess how many she has?), travelling stories, and interesting things regarding hotels, suitcase collections, and much more!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
When going through a backlog of various items, I suddenly realised that although the App Profile Manager was released in September 2020, I hadn’t devoted any space to it! So I’ve therefore decided (finally) to do an article to cover it.
First of all, what exactly is the App Profile Manager? Well, it’s a (somewhat) new feature that never existed beforehand. Essentially, the Omnichannel Agent App window has a number of configurable items, such as tabs to load at start-up, etc. Trying to work out where the configuration for each item is can, at times, be slightly frustrating, and I (for one) can’t always remember it correctly! But there’s also more, as I’ll go into below…
So, enter the App Profile Manager. At the moment, it’s only able to be used for two specific standard apps. These are the Customer Service Workspace app, and the Omnichannel for Customer Service app. In the future this may open up some more, but we’re limited to these for the moment.
So what does it do? Well, it’s there to enable system administrators to add configurations to an app. Essentially, it’s focused on on giving users access to certain items & functionality within an app.
As Microsoft puts it, it ‘allows administrators to create targeted app experiences for agents and supervisors as an alternative to building and maintaining custom apps’. Wow – Marketing sure can come up with some interesting lines at times!
I can hear you asking ‘so why should we use it’? After all, customer support agents will just log into the app, for example, and see the interface. Why should we use this, when we can just use the Omnichannel Administration app to configure things.
There’s actually a really simple answer to this. See, if we’re carrying out the configuration just through the Omnichannel Administration app, this will be set company-wide. All users logging in will have the same experience. However, there are companies that, although it’s all based around customer service, will have different teams that handle different things, and want them to have different screen layouts. Perhaps they’re even a multi-national.
It’s exactly for this purpose that the App Profile Manager exists. See, using it we can set up different screen profiles, showing different tabs, having different notifications, etc. We then assign it users to it (unfortunately we can’t use a security group at this point in time). When the users log in, they’ll then be presented with whichever layout they’re associated with. We can create custom profiles as we need, to handle the business needs!
Right – enough of talking about the concept. How do we actually get to it? Well, we need to go to make.powerapps.com, click into the list of apps, and then select either the Customer Service Workspace app, or the Omnichannel for Customer Service app. Clicking the ellipse next to it will give us the option for the App Profile Manager at the bottom of the fly-out menu:
This will then launch the App Profile Manager homepage. Some nice information shown here, with even a link to a video that we can launch to see how to go about things.
On the left hand side, we can see the apps in place, along with the ability to launch directly into the different settings areas for them. This is all standard stuff.
The power of App Profile Manager really comes when we’re going into the App Profiles section. Here we can see all of the app profiles that exist in the system. The ones with padlocks next to them are default system ones, which we can’t modify. But the other ones we ARE able to change, as well as being able to set up new ones:
When we open up one that we’ve created, we can see how we can go about customising it. There’s even a handy little visual guide to help users understand what/where each section is:
We’re able to configure the following (per app profile):
Once we’re happy with the setup performed, we then need to assign users to the app profile itself. To do this, simply slick the ‘Assign users’ button on the menu bar:
This will open up the screen to add users to the app profile. We can easily select from existing users, and then associate them to the app profile:
And voila, we’re done!
Users will access the app in the normal way, either through launching it in the browser, or using their bookmarks. When they log in, they’ll be presented with the app profile that they’ve been associated with.
If a user doesn’t have an app profile associated with them, then the default system app profile will be assigned to them, and they’ll see that when they log in.
Note: Although the system doesn’t enforce it, you should ensure to only assign users to a single app profile!
So there you have it. A way to customise the customer service agent experience across a customer, to provide the best interface possible to them.
How could this help you with your own scenarios? I’d love to hear – drop a comment below to share.
Discovering how Luise decided to learn piano (she also loves bubble wrap!), and how her luggage decided to go on a different journey to her (along with the use of technology, of course!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
One of the most basic functions of Omnichannel is the humble chat widget. This lovely little feature is there to be embedded on a webpage. People browsing the website can see it in the corner (or wherever it’s placed), and can then click on it to get help from a customer service person.
When clicked on, the chat window immediately opens, and people can connect to a live advisor. As mentioned previously, it’s also possible to add initial questions to the interface for the customer to fill out, and the information is then provided to the customer service agent.
All of this is wonderful. However, companies are now, more than ever, conscious of their branding. And by branding, I’m not just referring to a corporate logo. Businesses will often have colour schemes that are globally identified with them, along with fonts as well. Think of Coca Cola, for instance. The cursive script used is identifiable wherever you are in the world, even when it’s written in a different language, or the other way around!
With the default system customisation options, the chat widget itself is able to be pointed to a logo to be used in it. However further customisations and options, such as the colour scheme, are limited to pre-set options. So what happens if a company wishes to extend this further, and keep things in line with their corporate image?
Well, thankfully due to some extended development tools, this is able to be done. Below, I’m going to set out some of the functionality that is available through the usage of different scripts that can be added to the webpage within the chat widget code, which will then enhance it even further.
Pop out mode
It’s great to have the chat widget on the same screen, down in the corner somewhere. But what if you’re wanting to have it pop out, and present in a different window? It’s not possible through the default configuration, but it is possible through the usage of code. Simply adding the following line before the ‘></script’ tag at the end of the code block, we get to see this happen:
data-open-in-window="true"
It’s also possible to set the tag to “false”, which will then obviously not pop it open in a new window, but will keep it within the widget itself.
Font options
Not only are we able to pop out the chat window, we’re also able to use custom fonts. Again, the default font options leave a lot to be desired, in my opinion. Given the wide range of fonts being able to be used on websites nowadays, it’s definitely very nice to be able to use more fonts for the chat widget itself. I’d be slightly cautious here against being too ‘wild’ with them, as obviously we want to ensure that they’re accessible for all, and not difficult to read for some people.
Adding the following code snippet before the ‘></script’ tag at the end of the code block will make this happen. Note that we do need to specify the font that we’re wanting to use, though not all fonts may be available on website pages:
data-font-family-override="Stencil; Segoe UI"
Also bear in mind that different browsers may have compatibility issues with more advanced fonts, along with mobile devices, so I’d advise to be careful here. Ensure that you do test this out as widely as you can. There is also a second option font that can be used, in the case where the main font that you’ve specific is not available.
Custom colours
The final piece of customisation that I’d like to mention (at least for the purposes of this blog post) is around colours. Again, there are only a few pre-set colours available to pick from for the chat widget interface, which is a shame. For this, I’d definitely have expected to see the ability to select more colours, or have a colour picker/HEX value column available to use. After all, if it’s possible to do this in Microsoft Word (or other programs), why not Dynamics 365?
So again, there’s a nifty little code segment that can be added to the chat widget code script on the webpage. This requires you you know the HEX value for the colour that you’re wanting (if you don’t know this off the top of your head, there are free tools out there that can easily and quickly provide it to you).
data-color-override="#174F15
Personally, I think that the colour option is the best one to go for, as you can immediately utilise any custom colours that your branding contains!
Overall, I think that these are really great, and as you can see, I’ve played around with them for my own environment!
Have you ever had a need to customise something like this, but faced challenges? Drop a comment below – I’d love to hear!
Discovering how Jon loves photography, and has even used technology to automate things! Also covering the importance of mental health and looking after ourselves
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
Solutions are marvellous things. They enable us to be able to package up lots of components, and deploy them to different environments all together as one single package.
However, there have been changes over time as to how solutions are used. I’m not (for the most part) going to go into the Managed VS Unmanaged debate, which I leave to people who are more in the know….
Microsoft Dynamics 365 apps are installed using solutions. Third party apps provided by Independent Software Vendors (ISVs) also use solutions.
In Power Apps, solutions are leveraged to transport apps and components from one environment to another or to apply a set of customisations to existing apps. A solution can contain one or more apps as well as other components such as entities, option sets, etc. You can get a solution from AppSource or from an independent software vendor (ISV).
Custom development should also take place within a solution, to allow it to be deployed appropriately.
But it’s important to take a closer look at how solutions work overall, as we can be involved on multiple projects within the same environment. Not only that, some solutions may require other solutions to be present first, in order to actually work! A great example of this is Master Data Management (or MDM), which is where companies have a ‘backbone’ of data, which other parts of the system then hangs off.
To understand this concept better, let’s take a quick look at solution layering.
Solution Layering
Layering occurs on the import of solutions and describes the dependency chain of components from the root solution introducing it, through each solution that extends or changes the components behaviours. Layers are created through an extension of an existing component (taking a dependency on it) or creation of a new component or version of a solution
Managed and unmanaged solutions exist at different levels within a Microsoft Dataverse environment. In Dataverse, there are two distinct layer levels:
Unmanaged layer. All imported unmanaged solutions and unmanaged customizations exist at this layer. The unmanaged layer is a single layer.
Managed layers. All imported managed solutions and the system solution exist at this level. When multiple managed solutions are installed, the last one installed is above the managed solution installed previously. This means that the second solution installed can customize the one installed before it. When two managed solutions have conflicting definitions, the runtime behaviour is either “Last one wins” or a merge logic is implemented. If you uninstall a managed solution, the managed solution below it takes effect. If you uninstall all managed solutions, the default behaviour defined within the system solution is applied. At the base of the managed layers level is the system layer. The system layer contains the tables and components that are required for the platform to function.
The following diagram introduces how managed and unmanaged solutions interact with the system solution to control application behavior.
The system solution represents the solution components defined within Dynamics 365 or the Power Platform. Without any managed solutions or customisations, the system solution defines the default application behaviour. Many of the components in the system solution are customisable and can be used in managed solutions or unmanaged customisations.
Managed solutions are installed on top of the system solution and can modify any customisable solution components or add more solution components. Managed solutions can also be layered on top of other managed solutions. As long as a managed solution enables customization of its solution components, other managed solutions can be installed on top of it and modify any customisable solution components that it provides.
Unmanaged customisations. All customisable solution components provided by the system solution or any managed solutions can be customized in the unmanaged customisations
Unmanaged solutions are groups of unmanaged customisations. Any unmanaged customized solution component can be associated with any number of unmanaged solutions. These can be edited & modified, regardless of the environment in which they’ve been deployed to
The ultimate behaviour of an instance of Dynamics 365 or Power Platform application is the culmination of the system solution, any managed solutions, and any unmanaged customisations.
The official stance of Microsoft, according to its Application Lifecyle Management (ALM) documentation, is that unmanaged solutions are used for development, and that managed solutions are released downstream to further environments. For bespoke solutions, however, this may not fit, and an appropriate balance must be found.
Data ‘Backbone’ & Solution Dependencies
Given the way that companies are adopting Power Platform (and Dynamics 365, of course!) it’s highly likely that we will build out system structures that will form the backbone for multiple applications on an on-going basis. With this in mind, it’s appropriate to put in place proper planning for this, to avoid any issues that could occur in the future with appropriate system designs
Solution Dependencies
When creating system structures within an environment, using unmanaged solutions, connecting two (or more) tables together will create dependencies on each other. In simple terms, if we connect Table A to Table B, there’s a reciprocal relationship created back from Table B to Table A:
This happens even if Table A is in Solution 1, and Table B is in Solution 2. If they’re in the same environment (& both solutions are unmanaged), it will create the two-way dependency.
This will cause issues if trying to deploy each solution individually, and will fail on import, as the system will require all items to be available in the solution
Workable scenario
The way in which to handle the issue of solution dependencies is to ensure that the ‘master backbone’ of system design is created in the main development environment, and then to use that in secondary development environments as the core of additional solutions:
This is in line with the emerging recent Microsoft Best Practise information around solution management (which is likely to be moving towards having a single environment per developer, rather than multiple developers working in the same environment).
The steps for doing this are as follows:
Main ‘core solution’ exists (as unmanaged) within the main development environment
When a project requires this to build upon:
Secondary development environment is created
‘Core solution’ is exported as managed from the main development environment, & imported into the secondary development environment
Project work is carried out within the secondary development environment
Once project solution is complete (or when appropriate for deployment), it can be exported from the secondary development environment
If deploying directly from the secondary development environment to downstream environments, it should be exported as managed
The solution should be exported as unmanaged, and imported back into the main development environment. This will not cause dependencies to be created with the ‘core solution’ in it
Note: The main ‘core solution’ should consist of the items that are needed for core system work. If additional items are needed for multiple projects to work off (eg Account Manager field), this would need to be added to the core solution, rather than the individual project solution/s, as otherwise there could be further issues downstream.
If the project is completed, but requires further work to be carried out later on (or development support), then the following should be done:
Secondary development environment is created
‘Core solution’ exported from the main development environment as a managed solution, and imported into the secondary development environment
Project solution exported as unmanaged from the main development environment, and imported into the secondary development environment
Work and/or support can be carried out within the secondary development environment, and released appropriately
I’m expecting further information around this to be released by Microsoft in due course (I’m a little surprised there’s not more out there at the moment, to be honest!). It’s vital that we ensure that we’re working with solutions in the right way, to stop any issues occurring later on down the line.
Have you ever had a problem around this? Drop a comment below – I’d love to hear your experiences!
Discovering how Mark was actually a ninja in the past (you’ll have to listen to discover how!), the importance of looking after people, and challenges when running a company.
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.
So here’s the thing. There used to be the MB-900 exam, which was the Microsoft Dynamics 365 Fundamentals exam. This was aimed at people who had a small knowledge of Dynamics 365, and it was really the base/entry-level exam into the qualifications for it.
However, Dynamics 365 is actually comprised of two ‘parts’. There’s the ‘front office’ part that’s usually referred to as Customer Engagement (well, depending on how Microsoft wish to refer to it as, which can change from time to time!), and there’s the ‘back office’ part, which is the ERP side of things. This is the finance & operations sphere, where those functions take place.
The MB-900 was a slightly strange exam, in my opinion, because it covered both. There were questions around things like Sales, Customer Service, etc, but there were also Supply Chain Management questions as well, for example. Now I’m not saying that people shouldn’t know about both ‘sides’ of the equation, but people usually (for the most part) handle one or the other. It’s generally unusual to find someone knowledgeable about both.
Furthermore, if we take a look at the more in-depth exams in the MB range, we find that there’s a definitive split there. The MB-2xx series cover Customer Engagement, whereas the MB-3xx series covers the ERP side of things. So it’s definitely not the norm to have both sides included in a single exam.
Microsoft came to the realisation around this, and have therefore decided to update the Fundamentals space. In doing this, they’ve split things out. There’s the MB-910 exam (which is what this post is about), and the MB-920 exam, which focuses specifically on the ERP space. A good move, in my opinion..
The MB-910 launched this past weekend, and I took it around a day after it went live. Let’s go take a look at it, and recap my experience with it.
The official description of the exam is:
This exam covers the features and capabilities of Microsoft Dynamics 365 customer engagement apps.
Candidates for this exam should have general knowledge of or relevant working experience in an Information Technology (IT) environment. They should also have a fundamental understanding of customer engagement principles and business operations.
Taking it leads to the qualification for ‘Microsoft Certified: Dynamics 365 Fundamentals Customer Engagement Apps (CRM)’.
The description around the qualification is:
If you’re familiar with business operations, customer relationship management (CRM), and are IT savvy—either generally or through work experience—take advantage of this certification to highlight those skills. Validate your broad exposure to the customer engagement capabilities of Dynamics 365 to enhance your career journey.
People in different roles and at various stages in their careers can benefit from this fundamentals certification. Here are some examples:
IT professionals who want to show a general understanding of the applications they work with
Business stakeholders and others who know Dynamics 365 and who want to validate their skills and experience
Developers who want to highlight their understanding of business operations and CRM
Students, recent graduates, and people changing careers who want to leverage Dynamics 365 customer engagement capabilities to move to the next level
Once again, I sat the exam through the proctored option (ie from home). This is the way that I now usually take exams (even if I could go to an exam centre, I think that I’d be unlikely to, given the travel/time needed!). Checking in for the exam went without issues (the process definitely seems to be getting smoother each time), and I was ready to go within a few minutes.
As in my previous exam posts, I’m going to stress that it’s not permitted to share any of the exam questions. This is in the rules/acceptance for taking the exam. I’ve therefore put an overview of the sorts of questions that came up during my exam. (Note: exams are composed from question banks, so there could be many things that weren’t included in my exam, but could be included for someone else! ). I’ve tried to group things together as best as possible for the different subject areas.
Project Operations
Scheduling resources
Entering project time/costs
Skills
Roles
Different types of project costings
Customer Service
SLA’s, what they are, which ones to use
Omnichannel, including capabilities and channel functions/availabilities
Power Virtual Agents
Sales
Lead processes, deactivating & reactivating
Opportunity processes
LinkedIn Sales Navigator. How it interacts, which capabilities it has within it, how it works
Quotes. How they work, what’s required to handle them, document generation
Marketing
Website forms
Automation around responses
A/B testing
Event management
Field Service
Work orders
Route optimization
Scheduling boards
Document options
Attachments that users can access within the system, as well as outside of Dynamics 365
File collaboration tools, and integration with them
Timelines & activities
System currencies, default options, additional currencies, and updating them
Understanding different types of tables, and when you’d use each one
Reporting capabilities
How data is able to be reported on
Report Builder Wizard
Reporting on data held in Dataverse
Reports in dashboards
Usage of Power BI, including data gateways
I was slightly surprised with the level of detail in some of the areas. I wasn’t, for example, expecting the emphasis on Project Operations and Field Service that came up for me. Some of the level of detail seemed more fitting for an MB-2xx exam than this Fundamentals exam.
In a similar vein, I also wasn’t expecting Power BI and Power Automate so much. Perhaps that’s just my own perspective, though obviously with the Power Platform it would be there. However there is a PL-900 exam, around Power Platform capabilities, that I’d expect those sorts of questions to be in, rather than here in this exam.
Otherwise I think that it was generally on point for what I’d expect to find at this level of exam. The questions have definitely evolved over time, and I found myself giving more consideration to answers than I would have on the previous version.
It’s a good place to start for people who are looking to get qualified around Dynamics 365! If you do decide to take it, please drop a comment below to let me know how it was for you – I’d love to hear about your experience!
Finding out about how Tamara’s family came to get a dog, the joys of dog walking, along with the ‘joys’ of installing major hardware systems back in the day!
If you’d like to come appear on the show, please sign up at http://bit.ly/2NqP5PV – I’d love to have you on it!
Click here to take a look at the other videos that are available to watch.