In this first ever ItAintBoring video, I am talking about a couple of things:
Dynamics does allow emojies. It’s just that, and I’m not sure why nobody else(myself included) spotted this interesting feature before Meagan Walker did it in her blog post:
So I could not help but to dig a bit more into it. Turns out you can use emojis pretty much anywhere in Dynamics (and not only with Dynamics), at least when using it with a web browser:
This will also work in the Unified Interface, though I did not try it with the mobile apps – it may or may not work.
Why is it working is an interesting question. Those emojies are not “images” – they are special characters/symbols provided with the font. And, as it turns out, Dynamics is using fonts that support emojis naturally:
As you can see on the screenshot, it’s Segoe UI Emoji that’s rendered there, and it does support emojis, or, at least, some of them.
One caveat with this is that, depending on which fonts you have installed in your system, the same emojis may be displayed differently (or, possibly, they won’t be displayed at all). For example, if you look at the screenshot below, you’ll see how it’s the same screen, but it’s a different font. So it’s the same emojis, but they have different visuals now:
There is a Microsoft Support article that you may try if/when you run into this kind of weird emojis:
Basically, it’s all about getting the right font installed (which, unfortunately, I could not really try in this particular environment because of some limitations).
When enabling / disabling external authentication on the portal, there seem to be at least a couple of gotchas. In general, the whole process of enabling external sign in through different authentication providers is described here:
However, if you wanted to disable external authentication, you might use false for the following site setting: Authentication/Registration/ExternalLoginEnabled
But, as per the documentation above, Azure authentication won’t be affected:
So your portal users will still see Azure signin option:
What will disable Azure AD signin is using false for the following site setting:
On the other hand, if you keep the signin enabled, as in the example below:
You will find that, once the portal user has signed in, they will see a few options on the profile page which make sense for the portal-based authentication but which don’t seem to make that much sense for the external authentication:
What’s happening there is that the same portal account/contact in Dynamics can represent a local portal account, and, also, can be linked to a number of external identities. I can check which identities are associated to my portal account on the portal side:
My portal account is a local account, but I can use google signin. And I can also go to Dynamics to see what’s happening there – there will be an external identity associated with this contact:
The only problem with this process is that, if somebody chooses to signin with Google (for example) when registering on the portal, and once they click “Change Password” in their profile, here is what they are going to see:
Which is a bit confusing because of the header and because it’s not quite clear which Username this page is talking about. It’s actually suggesting to create a local portal account, so it’s really just a matter of changing the header to make it clear (and, since we can’t disable this functionality, I think that’s just what we have to do – change the header).
That header corresponds to the following site setting in Dynamics:
So we can replace out-of-the-box value with something more appropriate:
And this is what we’ll see:
Once the local account has been created, that header disappears, and that’s more or less how we need it to be:
This is my personal opinion, of course, but I think it’s still difficult for Microsoft to look “cool” because, frankly, Microsoft has been and still is about doing everything. They have cloud services, artificial intelligence, operating systems, developer tools, CRM, document management, they tried phones, they.. what is it they did not try?
So let’s try a game of associations.
I say “SalesForce”.. you probably say “CRM”
I say “Apple”.. you probably say “iPhone” (or “iPad”)
“Google” – “Search” (or, maybe, “Android”)
Now let’s try “Microsoft” – what is it that comes to mind?
Maybe it’s Dynamics CRM. Maybe it’s Dynamics 365. Maybe it’s Sharepoint. Maybe it’s Bing maps. Maybe it’s Visual Studio. For me it’s, probably, still “Microsoft Windows”.
And you know the saying – “jack of all trades, master of none”. This is not cool at all.
Now you might think it’s not exactly what you expected to see in this post since I mentioned that, maybe, Microsoft is actually doing something cool this time around. I’m almost there, no worries.
See, a few years ago when Microsoft released the first version of Flow, I remember looking at it and thinking “why?” IFTTT and Zapier had been around for a while by that time, so it all looked like another attempt to say “we can do it, too”. Even more, I had a somewhat similar impression from PowerApps at first. Basically, I just kept thinking to myself why would not they just focus on Dynamics, SharePoint, Azure, etc? On the things that proved to be working.
Problem is, if Microsoft did just that, they would not be getting the cool thing they are calling the Power Platform. Actually, I don’t think it was in the plans – Dynamics CRM went through rebranding just a couple of years ago to become Dynamics 365. If Power Platform were there at that time, maybe it would not be necessary to rebrand Dynamics.. but it’s a different story anyway. What’s important is that, in the end, we did get the Power Platform.
And what’s good about it is that, finally, we seem to be getting something we can associate Microsoft with. I am just not sure if they are taking it far enough, since, as of this moment, Power Platform is a combination of Power Apps, Microsoft Flow, and Power BI.
It would actually be even cooler if Microsoft were able to associate just about everything with the Power Platform name because:
- That would resonate with their mission statement (“to empower every person and every organization on the planet to achieve more”)
- And that would actually be the name we could use to identify just about every product offered by Microsoft
As in(and this is all hypothetical).. You want to manage your clients, do AI predictions, orchestrate your data flows… You will find all those tools within the Power Platform. You want to get the best tools for your developers? Power Platform is the answer.. Operating system for your laptop? Comes with the Power Platform.
Of course it’s not what Power Platform is, yet. As of now, this name is only referring to these three products:
- Power Apps
- Microsoft Flow
- Power BI
And, by doing this, that kind of introduces the confusion since, for example, Dynamics 365 and Office 365 are still mentioned here: https://dynamics.microsoft.com/en-ca/microsoft-power-platform/, but, technically, Dynamics 365 is an application build on top of the Power Platform (even if Power Platform is, in a way, a rebranding of XRM, so it’s hard to even say where is the chicken and where is the egg here)
But, all that aside.. If Power Platform name sticks around, and, possibly, if it becomes the overarching name for other products, I will be able to say, one day, that Power Platform from Microsoft can do that. Whatever it is the client will be asking about. Without having to mention a bunch of different products.
And that would be really cool..
And there are some interesting consequences. For example, I was wondering what would happen to a Flow if I deleted a field used in that flow.
Here is the flow:
And here is the field which I’m just about to delete from Dynamics:
First of all, it does not have any dependencies, at least not according to what Dynamics is telling me:
So, I was able to delete it without any problems:
Now the flow did not recognize it yet even though I did refresh the browser:
How come? A few minutes later, here is what I see – there is definitely a change:
But the flow keeps working:
Not sure if flow behavior depends on the connector in this situation – maybe some connectors will fail to execute an action if there are missing attributes.. Although, I guess it might also be the expected behavior – if the attribute is “empty” in Dynamics, it would be missing from the output of the previous step (think plugins, late binding.. if there is no value, the attribute just won’t be there in the attributes collection). Which, from the outlook connector standpoint, is probably no different from when the attribute is missing for any other reason (as in when the attribute has been removed).
Still, if, logically, the Flow did expect that attribute to be there, you may get some unexpected results which you will only recognize later. What are we going to do with that? I am not sure at this point, but, I guess, the whole Power Platform is still in the process of bringing everything together, so there could be this kind of edge cases which will be handled later.
Ok, the title probably has something to do with Steve Mordue’s post I just read: https://stevemordue.com/the-changing-role-of-the-microsoft-business-applications-partner/
Thing is, I do believe pure developers are quickly becoming irrelevant in the Power Platform world. I am probably lucky to have on-premise clients since it’s a different world alltogether, but it’s not going to last forever either. Where you see “partner” in the post above, you can safely replace that with “developer”, and it all will still make sense.
There are, also, folks working on the third-party tools, XrmToolBox included, but that’s a different type of work – it’s not so much about Dynamics implementation as it is about supporting those implementations. As much as I appreciate all the work they put into those tools, I just can’t shake off the feeling there is going to come a moment when all those tools will be replaced with some out of the box features. Mind you, it has not happened yet, and it’s not going to happen tomorrow.
On the other hand, what I have been thinking about lately is that Power Platform has a lot of power (no pun intended) hidden in it. It may be still somewhat hidden for now, somewhat undiscovered yet, but it’s certainly there waiting for its time. If it all keeps shaping the way it has been shaping in the last few years.. it may become a requirement, or, at least, a huge asset on the resume, for the sales/marketing/service people to have some familiarity with the Power Platform tools.
There is CDS, there is Flow, there are Power Apps, there is Power BI, of course there is still Dynamics.. But it’s all becoming more and more integrated, and, yet, each of those tools individually is becoming more and more powerful. Maybe it’s not there yet, maybe it’s still going to take a year (or a few years), but the obvious implication of this process is that Power Platform consulting is not going to be the same what it used to be with Dynamics 3-4-2011-2016.
Our clients will start building apps on their own. All those plugin customizations we got used to will really be considered low-level and highly undesirable (since those will still require specialized skillset). But it’s not just that. In the development world, we are all used to the application life cycle management, various forms of testing, etc etc. This assumes a relatively long application development cycle, even when using an agile methodology. I have very little hope that any of that will actually stick around once our business clients realize they have the power of Power Platform at their disposal. There will be individual Flows and individual apps, most of them won’t be tested on the organization level, most of them won’t have any development project plan. Not that it’s a bad thing – it’s just a different thing. And, maybe, that’s the reason why we’ve never got a good application lifecycle management methodology for Dynamics.. maybe it was not in the plans.
All that said, if you look at it from the business standpoint, and I will probably get back to it later, these are all good changes. As usual, there are going to be challenges, a lot of them are going to be new to all of us, but the fact that a lot of really powerfull tools which we used to custom-build, all of them integrated with each other, are going to be available to the end users out-of-the-box is worth thinking about.
So, who knows, maybe the new role of the Power Platform consultants will be to help clients navigate in this new world, to educate them on the hidden treasures and dangers, to guide them sometimes, and, in the rare situations, to do the heavy lifting of low-level development.
There seem to be some kind of caching issue in v9 which I can’t exactly pinpoint, but, basically, it’s like this:
When updating a plugin assembly, you may find that either the plugins are not updated or the custom workflow activities are not update correctly. As in, you may not be able to see updated activity names in the workflow designer. Or you may not be able to see updated parameters..
For example, here is what I saw in my v9 instance:
While in the plugin registration tool it all looked good:
This was happening in v9, where the solution containing this assembly was installed as a managed solution. In the 8.2 instance, which had the unmanaged solution, everything looked good.
So I asked, I googled, but, it seems, this is just some kind of vague issue (and it’s definitely not client-side caching since I tried different browsers, private sessions, etc)
Either way, if you run into it, and if you are looking for a workaround, the only way I could make it work is by completely unregistering the plugin assembly. Which can be a bit of a challenge if you are already using those workflow activities somewhere else. Fortunately, in my case I did not have any dependencies from other managed solutions – not sure what I’d have to do if that were the case short of reinstalling all managed solutions (which would probably cost me some data).. Still, I had some other workflows relying on the workflow activities in my assembly, so, in the end, here is the workaround recipe:
- Create a new solution
- Add all the workflows using your custom activities to that solution
- Export the solution – you’ll need to re-import it in the end
- Deactivate all those workflows
- Then delete them (if you don’t do it, you won’t be able to proceed to the following step)
- Using plugin registration utility, un-register the assembly
- Re-register your assembly, steps, and custom workflow activity (this is where, if that assembly is part of another solution, you can just re-import that solution)
- At this point your assembly should be updated correctly
- Finally, re-import the solution you exported above
This time, you should be able to see correct activity names/parameters in the workflow designer:
An updated version of TCS Tools is available – it fixes an issue with simple type(number, text, etc) fields not being updated in some situations, and, also, adds the ability to run an on-demand workflow on all the entities returned from fetch Xml:
For example, the configuration record above will instruct TCS Tools to update firstname field on the contact records associated with the account (through the accountid) – it will use “name” field for the update, and, then, “Set Contact Phone” workflow will run on each of those contacts.
You can leave any of the sections empty if you wish – it could be only the workflow or only the field update.
Just remember that you need to create a workflow and pass that configuration record to the Lookup Setter activity for all this to work:
You may think it’s going to be some kind of promotional post, but it’s not.. well, maybe a little. But it’s something that came up as a side-topic of the linkedin discussion here: https://www.linkedin.com/feed/update/urn:li:activity:6441012490728980480/
My personal relationship with the MVP award is kind of controversial. I only had one, so far, and I got it (as far as I know) because of my contributions to the community forums and because of this blog. And, of course, because another MVP decided to nominate me. Quite frankly, a lot of those forum activities and blog posts were meant to get me there – yes, I did want to see what it really means to be an MVP, what kind of perks you get, etc. And, since it was aligned with my other goal of getting up to date on the Dynamics “technology” (after having spent a few years stuck with the older versions), it all worked out pretty well.
Now, about 9 months later, I am asking myself whether it was worth it, and, also, whether MVP designation is something I’d like to have moving forward, even if I still have 10—11 months before this one expires. So I figured I’d share some of those thoughts.. You may find it interesting. Just keep in mind it’s just my perspective – I’ll try to keep it short.
Basically, I believe it’s wrong to think of the MVP designation as of an award. It’s more like a recognition that something is not quite right with the person since that person is spending his/her spare time trying to figure out the details of a particular Microsoft product.. and not only to figure them out, but, also, to share that newly acquired knowledge with the rest of the community. Why are they doing it? Go figure.. But this is what the MVP-s(already recognized or not yet) are, basically, doing.
Then those folks are awarded an MVP, and what comes with that is the ability to communicate with the same kind of people and/or with Microsoft directly. In other words, one can just keep doing the same they had been doing before they were recognized.. just with an increased efficiency. I can open Slack and ask a question – another MVP will certainly answer. I can (under the NDA, but still) send an email to Microsoft with a question/concern, and somebody from the Microsoft product team will address that question/concern. Simple as that, MVP recognition comes with the ease of access to the knowledge and information that was not there before.
If you think there is anything else to it(as in, more “tangible”), just consider.. There are no direct monetary awards. In theory, MVP-s might have some extra value for their employers because of the added reputational benefits, but, on the other hand, with all the MVP-related activities.. are those folks going to be as focused on their immediate job-related activities? Well, who knows.. So that does not necessarily mean an increase in the salary. There are some minor perks like MSDN subscriptions, Azure credits, etc. They are not life-changing, though they may be useful every now and then.
And if you do come to the conclusion that MVP is not so much an award but, rather, a recognition/diagnosis of some special kind of insanity, you may have to ask yourself if you want to be like that moving forward. That’s certainly an interesting life-style, but you have to keep pushing the bar higher and higher all the time, and all you have is your curiosity, passion, and, hopefully, time.
Do you have enough of that?
Actually, I am starting to think that somebody who is a two-three-X times MVP deserves a special recognition and a special treatment. That’s a person who probably spent countless hours contributing to the Microsoft community in some way.. So they were recognized as MVP-s, but they did not stop, they did not slow down, they just kept pushing. And yes, even though MVP is a recognition/diagnosis of insanity, but it’s also a way for Microsoft to say thank you to those strange people who may not have all the answers, but who are curious and passionate enough to keep looking for those answers and to keep sharing them.
So, if you want to join those ranks, think twice You’ll have to let some of that insanity into yourself. Because, even if what I wrote above sounds a bit idealistic, that seems to be the kind of mindset that will, more likely than not, get you an MVP recognition down the road as long as you stay in that mindset long enough. And that’s, probably, the only mindset that will allow you to be re-awarded after that. All other motivations – I think they just wear off, sooner or later.
I’ve been struggling with portal caching lately – I would update some data in Dynamics, and that change would not be reflected on the portal right away. Unfortunately, there are times when this behavior is just not acceptable since it may lead to all kind of negative feedback from the portal users.
And, then, it seems that an ultimate solution presented itself in the form of this tip of the day:
I am not talking about publishing all customizations or about invalidating the cache.. I’m talking about the Change Tracking option:
Enable it on the entity, publish all.. Refresh the cache as described here:
Maybe refresh it twice. And, then, enjoy the results. To be fair, it seems that, occasionally, some data may still be cached “incorrectly”, at least that’s the impression I got so far. Still, in 9 out of 10 cases it seems to be working once that change is in place.
I’d really love this tip to be mentioned in the portal documentation..