Monthly Archives: September 2018

Power Platform Admin Center Analytics – is somebody hacking my Dynamics instance?

I have my own online instance of Dynamics v9, so there is not a lot of activity there on a regular day.. but I know for sure that I did not go there even once yesterday.

So this morning, when I went to the Power Apps admin center to see the analytics for that instance for the last 24 hours, it’s not that I was terrified by the number of API calls, but I was a bit surprised.. apparently, something was happening in Dynamics even when I was not using it.. Was it hacked? Somebody was trying to steal my data?

image

From the looks of it, all those API calls are associated with the entity type codes. You can see how there are retrieve multiple calls for the MailBox entity (9606), which is probably my server-side exchange synchronization. There are Delete calls for the AsyncOperation entity (4700), and there are other calls.

Here is what showed up in the System Jobs chart:

image

And there is another nice chart that shows you the most used entities (custom vs out of the box):

image

Apparently, mailbox synchronization is an ongoing activity that requires a few API calls no matter if the user is working in the system or not. Which is understandable. Other than that, there are, also, system jobs doing rollup fields calculations:

image

So most of it actually looks quite normal so far – some activity should be expected even if nobody is working in Dynamics.

The only piece of this which is still puzzling me is the “most active users” chart:

image

Apparently, I was doing something I was not even ware of. To figure that out, I just enabled read auditing in Dynamics – we’ll see what is it I’m reading when I’m not in the system – may take a few days till I get clean data, but we’ll see what shows up.

And, by the way, all those numbers really come down to about 6.5 calls per every 5 minutes. Given that each user is allowed 60K calls per 5 minutes (https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/api-limits), that’s really nothing to worry about, at least from the utilization standpoint.

Server-Side email integration: one mailbox – one organization

 

When setting up server-side email integration, it’s good to remember the same mailbox can only be used with one organization:

https://support.microsoft.com/en-ca/help/4053618/incoming-emails-aren-t-being-synced-because-the-email-address-for-the

“An Exchange mailbox can only be configured to use Server-Side Synchronization with one Dynamics 365 organization. These alerts are logged if you have multiple Dynamics 365 organizations and try to configure your mailbox to use Server-Side Synchronization with multiple organizations.”

 

The fix is extremely simple if you know what to do, and you just need to enable the checkbox when testing a mailbox:

image

This will confirm to Dynamics that you are going to use this mailbox with the organization where you are running the test.

Part of the problem is that, it seems, in some on-premise builds at least (not sure about v9 online), when doing this test you will not get any meaningful mailbox alerts – all you will get is a failure for the email status.

image

You can switch to the alerts view for that mailbox, and you will see nothing there:

image

This is because, it seems, there is something wrong with how those alerts are handled, and it only becomes clear from the trace logs( https://support.microsoft.com/en-ca/help/907490/how-to-enable-tracing-in-microsoft-dynamics-crm ):

image

This tracelog is from 8.2 version, so it may or may not be working correctly for other versions/builds.

If you feel adventurous, you might try deleting that constraint right from the database, and, then, the next time you’ll run a test on the mailbox, you’ll see this alert:

image
But you don’t, really, have to do it (at least try not to do it in production)  – just don’t forget to enable the “sync” checkbox when testing a mailbox for server-side synchronization.

Using Emojis in Dynamics

 

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:

http://meganvwalker.com/using-emojis-in-optionset-fields/

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:

image

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:

image

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:

image

 

image

There is a Microsoft Support article that you may try if/when you run into this kind of weird emojis:

https://support.microsoft.com/en-ca/help/4021341/emojis-are-not-displayed-in-office-applications-in-windows-7

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).

Dynamics Portals: External Authentication

 

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:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/configure-oauth2-settings

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:

image

So your portal users will still see Azure signin option:

image

What will disable Azure AD signin is using false for the following site setting:

Authentication/Registration/AzureADLoginEnabled

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/portals/azure-ad-b2c

image

 

On the other hand, if you keep the signin enabled, as in the example below:

image

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:

image

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:

image

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:

image

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:

image

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:

image

So we can replace out-of-the-box value with something more appropriate:

image

And this is what we’ll see:

image

Once the local account has been created, that header disappears, and that’s more or less how we need it to be:

image

Power Platform – might be a good name for everything Microsoft is doing.. that would be really cool

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..

image

You may still be thinking “Dynamics”, but it’s the whole Power Platform now

 

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:

image

And here is the field which I’m just about to delete from Dynamics:

image

First of all, it does not have any dependencies, at least not according to what Dynamics is telling me:

image

So, I was able to delete it without any problems:

image

Now the flow did not recognize it yet even though I did refresh the browser:

image

How come? A few minutes later, here is what I see – there is definitely a change:

image

But the flow keeps working:

image

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.

The end of Dynamics developer is near?

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.

We’ll see..

Sometimes, you may have to re-build the whole thing

 

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:

image

While in the plugin registration tool it all looked good:

image

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:

image

TCS Tools: Updates and fixes (v1.0.16.0)

 

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:

image

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:

image