Monthly Archives: July 2017

Syntax highlighting for the Code Now XrmToolBox plugin

You know you can run C# code directly from XrmToolBox now, right?

Let’s use XrmToolBox to run your C# code into Dynamics!

In the original version, there was no syntax highlighting, so your code might look really boring.. all black and white, no colors at all. If that felt a little depressing, here is an updated version:

You will also notice that you can save your code to a file and/or load it from a file in this version, so you can start creating mini libraries to re-use later. Just make sure to download updated version of the Code Now plugin – you can follow the instructions provided in the original article:

Have fun CRM-ing (or is it 365-ing now?)

PS. Adding those colors to the plugin became possible thanks to this awesome open-source library shared by Pavel Torgashov:

PPS. CodeNow plugin has a home page now, so don’t be a stranger – stop by any time:


SSRS and FetchXml.. There seem to be a problem?

I’m not sure if it’s my lack of SSRS knowledge or if it’s really an unbeatable problem, but here is what I ran into.

Imagine that you have two entities. Let those two be Fiscal Years and Orders. Apparently, in any fiscal year you can have multiple orders. Let’s say every order is attributed to a fiscal year based on its “Created On” date.. So, here they are, the entities:

Now what if we wanted to build a (FetchXml) SSRS report that would display something like this:

Basically, there would be two datasets:

  • FiscalYears
  • Orders

And, once we had those, we could do some grouping on the client side.. could be something like this:

=Sum(IIF(Fields!new_ordertype.Value = 100000000, 1, 0), “Orders”)

This would give us the total number of all service orders (assuming 10000000 means “service”). However, we would still have to do the same by fiscal year, and that’s where the problem shows up.

We cannot add a parameter from a different scope to the aggregate function, so we can’t do this:

=Sum(IIF(Fields!new_ordertype.Value = 100000000 AND Fields!new_fiscalyearid.Value = ?????, 1, 0), “Orders”)

There, we can’t really reference FiscalYears dataset. We can’t reference group variables. We can’t reference a text box.. We can’t reference anything from a different scope. The thread thread below is a little old, but, it seems, that’s still how it works:

IF it were a SQL report, we could use a stored procedure to prepare all the data on the server, but we can’t use SQL reports with Dynamics online.

Yes, it’s possible to use subreports to calculate the numbers per cell.. However, every subreport will have to open its own dataset, and that may end up being a rather slow report then.

It’s also possible to create rollup fields in the fiscal year entity to calculate those numbers.. However, we can’t create a rollup per every possible number we’ll need to display on the report – it may work for this particular report, but there can be more reports.. and, after all, that’s what reports are for – to do that kind of weird calculations.

I may be missing something, but, it seems, it’s one of those scenarios I’ll need to add to the the list of Things you Can’t Do with Dynamics

Any objections?:)

Dynamics 365 for Outlook (Outlook client) is deprecated – what about Dynamic Worksheets?

So, we are losing Outlook client for Dynamics:

However, there is another feature in Dynamics that requires Outlook Client – it’s Dynamic Worksheets:

To view and refresh dynamic data, Microsoft Dynamics 365 for Outlook must be installed on the same computer you’re using to view the Excel data.

Then, what is it going to be once there is no Outlook Client?

Actually, that question is not quite correct. Even right now, you can already connect your Excel spreadsheet to Dynamics without having to install Outlook Client. Things have been changing, and, it seems, more than once.

There is this article that mentions Power Query and Dynamics 365 data source:

However, if you download Excel 2016, you won’t be able to do what the article is suggesting. There is no “Get Data”.. there is “New Query”. And there is no “From Dynamics 365”, there is only “Facebook”.

Well, it seems office support site is a little bit outdated:)

It can still be done, though, and this article by PowerObjects will walk you through the steps:

I will not be repeating those steps here, but there is one I wanted to emphasize:

It shows a few things:

  • For the data connection, Excel can be using Dynamics Web API
  • It’s not only “online” anymore – windows authentication is supported as well

So, yes, long story short – we do have an alternative, and we’ll be able to connect Excel to Dynamics without having to install anything at all. At least once everyone starts using Excel 2016+.

There are a couple of features that may disappear, though:

  • Right now we can go to Dynamics and export data directly into Dynamics worksheet. We don’t need to set up anything – we can just open that worksheet and refresh the data (well, assuming we have Outlook Client installed)
  • We can also import that worksheet back into Dynamics to update the data

None of those features is going to work once there is no Outlook Client, so we may have to wait and see how Microsoft handles that.

And, then, I am also not sure, not right now, how to use FetchXml with those queries. It’s not going to be enough if we are only allowed to work at the entity level.. although, maybe there is a way and I just need to dig more?






Let’s use XrmToolBox to run your C# code into Dynamics!

We all know about XrmToolBox – it’s a tool of choice for a lot of Dynamics consultants. Although, it is, really, a set of tools rather than just a single one.. But, either way, you’ve likely heard about it.

Worst case scenario – you just learned about it from this post.. in which case I would actually insist that you download the tool right now (hint: it’s free) from the XrmToolBox web site:

So, let’s assume you have XrmToolBox, and let’s say you know how to use it. How about using it for the strange purpose of running C# code into Dynamics? After all, XrmToolBox is, already, connected to your Dynamics organization, so all you are missing is an XrmToolBox plugin that will allow you to run the code.

To tell you the truth, I just wanted to see how it works out.. It did work – see below:

1. Download XrmToolBox plugin from this url:

2. Deploy that plugin to the XrmToolBox folder

– Unpackage that zip file

– Put the dll you’ll find there into the XrmToolBox plugins folder (which is: %AppData%\MscrmTools\XrmToolBox\Plugins )

3. Restart (or open) XrmToolBox – you’ll see another plugin there

(Yes, I know.. I should have added some nice logo)

4. Don’t open it yet – first, connect to your Dynamics organization

5. Then open the plugin

6. You can, actually, hit “Run Code” – the code will run and it will print account names for all accounts in your Dynamics organization

What if you wanted to change the code?

First of all, feel free to do it! What you have there by default is just an example to get you started.

However,  keep in mind a few things:

  • You have to have a public static void CodeNow() method in your code
  • You can use Service property (IOrganizationService) and LogMessage method in your code (sure you can use others.. but that Service will already be connected to Dynamics, and LogMessage will print a message in the log area of the plugin)
  • Do not define classes or namespaces in this version, just use static methods. Actually, you can probably define a class.. I did not try but it should work
  • In the “Using” area, add all the namespaces just like you would do it in your regular C# file
  • Here is the list of referenced assemblies your code can use: System.Drawing.dll, Microsoft.IdentityModel.dll, System.ServiceModel.dllSystem.Runtime.Serialization.dll, Microsoft.Xrm.Sdk.dll, Microsoft.Xrm.Tooling.Connector.dll,Microsoft.Crm.Sdk.Proxy.dll

Have fun!

Continue reading about CodeNow plugin: Syntax Highlighting

PS. Since CodeNow plugin has a home page now, don’t be a stranger – stop by any time:

A selfie for your worfklow

Imagine your were a workflow, and you were configured to start on the update of a few different attributes. Well, maybe you were a workflow which were supposed to start on the update of email and phone# fields on the account entity.

You would be a great workflow, and you could do lots of things.

However, you would not be able to tell if it’s just the email that has changed.. or if it’s just the phone#.. or if both of those attributes have been modified.

Which would be quite unfortunate, since your sole purpose might actually be to raise an alert in those rare situations when those attributes are modified together, and, so, you would fail to do your job.

Would not it be great if you could, well, take a selfie? It would tell you right away how you look like at that moment, so it would not be a problem at all to know exactly when to raise that alert.

And now there is a tool for you. Here is how it works.

1. You will need to deploy TCS Tools solution

Just follow the instructions on this page

2. Then, let’s configure the workflow

2.1. Create a workflow

Let’s make it a real time workflow that runs on the update of just any attribute in the account entity:

2.2. Add a step to verify if emailaddress has changed

First, let’s add TCS Tools: Attribute Change Validator custom action to see if phone# has changed

Then, let’s set the properties of that step:

2.3. In the same way, add another step to verify if emailaddress has changed


2.4. Here is what you should have by this moment

Notice step names, btw, we’ll use them below:


2.5. Now you just need to add a condition

2.6. And a stop workflow step under that condition

3. Finally, activate the workflow

4. And, then, it’s time to do a test

Voila! Now your workflow knows what it looks like!

It’s NOT a good idea to close all browser windows

If you are using Dynamics 365 Online(or any other IFD environment), you’ve probably seen this message many times:

So, don’t trust it the next time you see it! It is NOT a good idea for those of us who tend to keep the browsers open for as long as our laptops can handle those windows. If, by some chance, you have not figured out how to work around this problem, it’s really simple.

Once you get that message, just navigate to Dynamics 365 in the same window – it will ask you for the credentials, you will enter them, and you’ll be good to go without actually closing the browsers.

All the other Dynamics browser windows will pick up new session once you’ve logged in. In some cases, you’ll see a a popup waiting for you when you switch to those other window – it’ll be complaining about the closed session or something along those lines. Click “cancel” or “close”, whatever it is, and you’ll be back in business.

Dynamics 365 Custom Actions

Custom actions have been around for a while, but, somehow, I have not used them at all on my projects so far. I would always create a plugin or a custom workflow activity instead.. Still, I’ve been watching them for a while:) And what I think is missing is a set of recommendations and/or best practices around actions which would explain when and why we should be using them.

I can hear you saying “of course there are.. have you been in the trenches for the last few years?”

Technically, I probably have been, a little bit:) However, I’d like to explain myself.

What are the primary benefits of the custom actions?

In this 2014 article, PowerObjects are stating that “The most fundamental benefit of custom Actions in CRM is to allow non-programmers to build automated processes; in turn, developers can trigger this Action by using a single command, like “Approve” or “Schedule”, etc. Before custom Actions, this was only possible by making code update a field or save a record that would in turn trigger a workflow.”

In other words, non-developers can define a “workflow” which the developers can, then, trigger through the action. This is interesting and sort of makes sense. However, have you ever looked at all the custom actions included into the default Dynamics 365 solution (actually, it’s not necessarily the “default” solution. It’s what you get when you deploy Field Service, Project Service, etc)? There are lots of the out of the box custom actions, but, if you look at them, you’ll notice something unexpected about them:

NO STEPS HAVE BEEN ADDED. Here is another one:


This seems to be not that unusual at all for the out of the box custom actions.

Why is there a custom action, then, if there are no steps?

The answer comes in the form of the Sdk Message Processing Step:

See? There is a custom action, and there is a corresponding message processing step. This sort of turns the whole scenario on its head, though. It’s a custom action created by developers for everyone else – all the business logic is implemented in the plugin. As a non-developer, you can call this custom action from the workflow. As a developer, you can call it from a plugin/javascript. But you can’t even change the business logic since it’s all embedded into a plugin.

It’s probably safe to say, then, that Microsoft itself is not considering the ability “of non-programmers to build automated processes” as a primary benefit of using the custom actions.

Then.. why not to use a plugin/workflow instead of a custom action?

The way I see it, there are a few reasons why we may prefer custom actions:

1. They are business logic modules that do not have triggers – we can trigger them when we need to

A workflow will trigger in response to some event. A plugin will run in response to a message. A custom action has to be triggered either as a workflow step or from the web api/plugin using code. This is a somewhat different level of control, although, it’s arguable if it’s that much better than using a workflow/plugin.

2. We can pass input parameters to the actions and retrieve output parameters from the action

This is actually interesting. We can’t pass parameters to / from workflows or plugins. I am not sure why, at some point, the decision was made to introduce custom actions rather than to add this functionality to the workflows, for example. However, as it stands, we can only use custom actions when we actually need to pass parameters to our plugin, for instance. Or when we need to get output parameters from the plugin.


For example, what if we wanted to calculate some sort of total value? We might create a custom action which would calculate that value, and it could simply use input/output parameters to communicate with the calling process – it would not have to update any of the records and/or wait till any of the records are updated.

Or what if we wanted to find most recent case activity? We might create another custom action, and we might call it in a similar manner everywhere: in our javascripts, in the workflows, in the plugins.. That would be different from doing the same in a custom workflow activity which would require a workflow in the first place.


It seems we should be thinking of the custom actions as of the “functions”. Those functions can be defined as a mix of workflow steps and plugins – we can pass input parameters into the custom action and retrieve output parameters from the custom action. The reason we can call then “functions” is that, unlike with the workflow/plugins, we can, actually, call those functions from other places – we can call them from javascripts, we can call them from workflows, and we can call them from plugins. Still, I am wondering how often do we actually need that kind of functions – as I mentioned in the beginning of this post, I have not used them on my projects at all so far, though that probably simply means the time has not come, yet.. Still, I’d love to hear about the real-life scenarios(which, I hope, you can share in the comments) where the choice between using a plugin/a workflow/a custom action was clearly to use a custom action.

That said, does it seem like I have arrived at some kind of answer as to when and why we should be using the custom actions? It could be the case if this scenario was clearly described and documented in the SDK manuals/help files. But, as of right now, I still cannot find any indication of how to pass those parameters to/from the custom action in C# code, for example, when I am looking at the SDK files.

Here is what Andrii Butenko, a Dynamics MVP, wrote back in 2013:

Actions: usage of input/output arguments in plugins that handle Actions

This is great, and this allows us to process custom actions parameters in the plugins now; however, I am wondering if that’s even supported? De-facto, that’s how a lot of people have been using the actions now. However, it would be great to see an msdn link where this same process would be described by Microsoft – right now this is all we have on the custom actions:

Then where does it leave us? Custom actions is a feature in Dynamics that is offering some interesting usage scenarios. This feature lacks official documentation for developers, and it also lacks official recommendations on when and how to use it. The community has been trying to figure it out on its own and has offered various scenarios so far, but, if Microsoft could add a bit of packaging to this feature in the form of more detailed documentation and samples, I think this would be very useful.

Sonoma Partners’ Chrome Extension for Dynamics

I wanted to see what are some of the tools Dynamics consultants are using every day, so I posted a question on Linkedin, and somebody mentioned Sonoma Partners’ Dynamics CRM DevTools. So I was looking at it tonight trying to figure out if it should be added to the Dynamics Toolbox, and, quite frankly, I ended up being on the fence about it.

First of all, if you want to see it for yourself, here is the link:

I admit that the concept is brilliant. This is a chrome extension, so, unlike some other tools it’s available directly in the browser. Yet you don’t need to deploy it as a Dynamics solution.. it’s sort of the best of both worlds – it does not “pollute” your Dynamics environment with any additional components, so you don’t even need to approve the solution.. and, at the same time, it requires minimal installation/configuration efforts outside of Dynamics.

Here is a screenshot:

What I am a bit unsure about is the functionality. For example, there is no doubt Ribbon Workbench can make your life much easier if/when you need to customize the command bar. With the CRM DevTools it’s not that black and white, it seems.

Quick update on this one (contributed by Christopher Fernando.. who actually introduced me to this tool in the first place)

It’s great when taking over an existing solution by looking at schema names on forms, showing hidden fields, and providing guids of the current record.

This actually makes total sense. You’ll see some screenshots below where the tool allows you to display hidden fields, to show labels, to see schema names.. When reverse-engineering an existing solution, this could be a useful alternative to going to the form designer since you can do all that in “real time”.


Anyway, even though I don’t feel this tool would be on everyone’s list, it does offer an original deployment concept and it provides some useful functionality, I am going to add it to the Dynamics ToolBox for now.

Here is a quick overview of what you can do with the tool.

1. You can see some extra details about the form

And, as you can see from the screenshot, there are a few buttons you can use to run certain actions. For example, Copy Record URL makes quite a bit of sense to me considering that I don’t have Outlook Client installed right now.. so I can’t, really, use “email a link” button. Other buttons seem to cover some very special troubleshooting scenarios (for example, you can show hidden fields to see what’s stored in them)

2. You can get some information about the logged in user


This can definitely help with troubleshooting. There could be a Dynamics user complaining that he/she cannot access a record. Using CRM DevTools, you can easily identify the security roles assigned to that user without having to navigate to the “Security” page in Dynamics.

3. You can change attribute values

Technically, you can do it directly on the form as well. However, CRM DevTools give you the ability to update any attributes (not just those which are visible on the form).

4. You can run fetch

This is yet another rather useful feature, even if it’s probably not going to be that widely used. It’s a rare occasion when somebody would prefer to run fetch (which has to be prepared manually) instead of using the Advanced Find. Of course, there are some things we can’t do with the advanced find. But, like I said, those are rare occasions (and, then, we have XrmToolBox for that).

As I mentioned earlier, it would be nice to hear your feedback regarding this tool. More specifically, I’d really like to hear a compelling story where it saved the day.. so I could post it here:)


See Dynamics Tool Box Contents So Far

Two additions to what Dynamics can’t do

Adding a few items to “What you can’t do with Dynamics” list

11. Can’t use editable grids with the opportunities associated view

As discovered by Joe Dubs ( and confirmed with my own tests, we can’t use editable grids with the opportunities associated view. Other associated views, or, at least, those I’ve tried, work just fine.


12. Can’t use disallowed custom code in SSRS reports with Dynamics online

Whoever PAPs is, he/she is not the first one who ran into this problem:

As per Microsoft:


You may receive an error when you try to upload a custom FetchXML report into a Microsoft Dynamics CRM Online organization:

Error Uploading Report
An error occurred while trying to add the report to Microsoft Dynamics CRM.Try this action again. If the problem Continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally you can contact Microsoft Support.

Microsoft Dynamics CRM Online uses RDL Sandboxing that prevents reports from uploading or running if they contain code that uses disallowed methods.

What you cannot do in Dynamics

This is going to be a strange post(or a series of posts). Usually, it’s all about how to do something. In this case, it’s all about what we can’t do.

Why does it matter?

Every now and then, a change request will come in, and you’ll end up spending days looking for a solution. You will probably experience infinite amount of frustration while doing that since it would seem like a simple change, and, then, you would not be able to make it happen.. Yet, in the end, you would realize that it’s one of those platform limitations which you can’t overcome. Would not it be better if you knew about those limitations in advance? Or, at least, if you could look them up quickly?

So, let’s bring those limitations to light here.


1. You cannot customize Opportunity Close dialog

2. You cannot customize Resolve Case dialog (and you cannot customize Cancel Case dialog either)

3. You cannot use a workflow to work with the related records on the N side of the 1:N relationship

For example.. If you wanted to update all the contacts associated with the account whenever something happens to that account, you would not be able to do it using out-of-the-box functionality. You would need a custom workflow activity – you can either develop that custom workflow activity yourself, or you can use one of the third-party solutions for Dynamics.

4. You cannot display Dynamics (view/dashboards/etc) in an iframe on your web site

It’s not supported – you will get an error message in your iframe instead of that nice dashboard you wanted to see.

5. You cannot use Advanced find for all sorts of “not exists” conditions

At least you cannot do it without utilizing additional tricks. For example, you cannot use Advanced Find to find all accounts that have no contacts associated with them. Actually, FetchXml is perfectly capable of processing that kind of query. However, you can’t use those features of FetchXml in the Advanced Find.

6. You cannot get access to the database in the online environment, and you are not supposed to go to the database directly in the on-premise environment

Just like that. It’s a sacred part of any Dynamics environment. With the minor exceptions granted to the on-prem users, you are not supposed to touch it. If you want to change something there, use Dynamics web API.

7. You cannot automate report generation in the online enviornment

Would not it be nice if you could create a workflow that would generate a report and automatically attach it to an email? Unfortunately, that’s one of those impossible things. There are tricks available in the on-prem environments, but none of them are using out-of-the-box functionality, and they are not guaranteed to work moving forward. If you want this to work, your best bet is to set up a separate reporting server, a separate reporting database, and to utilize those for this kind of automated report generation.

8. You cannot deny access per record

Consider the following scenario: there is an organization where every user should have at least read access to all the records. However, every now and then there is supposed to be an exception and you need to deny access to some records for some users (for example, this may happen because of the potential conflict of interests a user might experience if they had access to such records). That scenario can’t be handled in Dynamics since you cannot deny access per record – instead, you’ll have to figure out how to set up security in such a way that there is a compromise between what Dynamics can do and what your users want to have.

9. You cannot use ADX Portals for on-prem installations anymore

Or, at least, you cannot purchase licenses. move to the cloud, and you’ll be saved. Stay on-premise, and you are out of luck.

10. You cannot include theme customizations into the solutions

Do you like those particular colors you’ve got in your dev environment by customizing the theme? Do you want the same colors in production? Unfortunately, themes are not solution-aware, so you can’t add them to the solutions. They are, basically, data records which you will need to move from one environment to another using some other way.

11. You cannot use editable grids with the opportunities associated view

As discovered by Joe Dubs ( and confirmed with my own tests, we can’t use editable grids with the opportunities associated view. Other associated views, or, at least, those I’ve tried, work just fine.

12. You cannot use disallowed custom code in SSRS reports with Dynamics online

Whoever PAPs is, he/she is not the first one who ran into this problem:

As per Microsoft:


You may receive an error when you try to upload a custom FetchXML report into a Microsoft Dynamics CRM Online organization:

Error Uploading Report
An error occurred while trying to add the report to Microsoft Dynamics CRM.Try this action again. If the problem Continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally you can contact Microsoft Support.

Microsoft Dynamics CRM Online uses RDL Sandboxing that prevents reports from uploading or running if they contain code that uses disallowed methods.

See Dynamics Tool Box Contents So Far