And I do mean barely. As in, I had to get 700 out of 1000 to pass, and I think I got 738.
Under the normal circumstances, I probably wouldn’t even try taking that exam, but there was a reason I wanted to do it, and quickly, so there we go… a Power Platform consultant decides to take a D365 Customer Service “functional” exam and it ends up being almost a failure.
But, of course, in the end what matters is that I have passed. Combined with PL-200 that now makes me a “Microsoft Certified: Dynamics 365 Customer Service Functional Consultant Associate”, which is exactly what the goal was.
Still, I was impressed with what I’ve seen in D365 while getting ready for the exam, so wanted to share those impressions while they are fresh a little more.
Although, I am not planning to talk about D365 functionality below. At least not for the sake of explaining how to configure things. For that, you can download skills outline from the exam home page and look up each of the topics in Google. You will find Microsoft docs are surprisingly comprehensive these days – almost everything is covered in great details. Combined with the various learning paths and a trial environment, that should give you enough material to prepare.
I’ll just emphasize that this is really a “functional consultant” exam – it’s all about how to do certain things in the specific first-party application. So, you have to learn the functionality, and there is a lot to learn.
Which, to be honest, makes perfect sense for a solution architect and, to some extent, for a developer, too. Since, if you don’t know what’s there and how it works, you won’t be able to build your solutions on top of what’s there – you’ll have to build from scratch.
Anyways, while studying for this exam, I could not help but notice how a lot of the functionality could probably be implemented in our custom model-driven applications. And, yet, some of that might not be doable.
Is it possible that “first party” apps have certain advantages over the apps we can develop? It would kind of make sense, since internal dev teams have god-like powers which might allow them to bend the rules sometimes, and we, mortals, just have to follow those rules
So, let’s look at some of those things from the “architecture/development” perspective.
I’ve already written about how Omnichannel is using form-specific links in the left-hand navigation panel, but that was just one of a few.
Here is another one: Omnichannel installation experience.
In the PowerPlatform admin portal, we can start provisioning an Omnichannel application this way:
That will open up a dedicated provisioning web page – the whole provisioning process is described here, but here is a screenshot to save you a trip to that link:
You can see how a web page above is loaded from a completely different url, and we could do the same in our apps. Creating a custom web app for the installation – why not? It might not be worth the efforts for smaller apps, and it might not be feasible without a dev team, but, if you are really working on something big, that’s not a bad choice.
In the context of the recent discussions about what pro developers can do in Power Platform, that’s one area where a pro-dev on the project could help quite a bit.
But, of course, this is more an ISV thing, since, if this were an internal application, we could easily get away with a manual one-time installation.
Other than developing an “application portal” to support this kind of installation experiences, there is, also, another options, and that’s package deployer, since it allows us to create “custom code that can run during or after the package is deployed to Dataverse environment” (which is another way to say “you can do whatever you want – add data, perform configuration tasks, etc… all from within your code”):
There is a corresponding “Deploy Package” task in the Power App build tools for Azure devops:
However, you may have noticed that Ominchannel takes it a little further – somehow, we have access to the “Manage” command which brings us to the deployment page. Not sure how that is done and whether ISV-s can, actually, add their apps to the Dynamics 365 apps “folder” in the admin portal (yet to customize that popup menu). Here is what I found in the docs, but I am not sure what it means and if that helps:
Having said all that, let’s look at something else. How is Unified Routing implemented?
I’d think there would be a set of plugins etc, and I am pretty sure there is, but here is something unusual:
In the default solution, there is a thing called “Account routing hub”, and it has “Master Entity Routing Configuration” type. I tried editing that one, and ended up right in the customer service hub:
So what is it, exactly? I am not sure – guess we’ll be able to use those things, too, but we are not there yet. Although, there seem to be a plugin registered on the master entity routing configuration:
So… it actually seems this is very similar to the environment variables. Just like we have environment variables in the solutions now, and those are, more or less, “data”, it seems there is other data that can be added to the solutions (even if we can’t use that kind of functionality yet).
Could we do the same just with the plugins? Probably. That, again, would be a nice piece of work for a pro-dev on the project, but, of course, since it has already been implemented in the first-party app, why would we try re-inventing the wheel (well, except that there are licensing fees, of course).
But that’s enough of reverse-engineering for one post – I’ll get back to this later. It seems I need to look at the unified routing functionality a little more first (and, possibly, write up another post), since, for some reason, it’s still not working in my trial instance 🤔