Monthly Archives: December 2018

Cloning your Dynamics Portals web site


Did you ever try to create a copy of Dynamics Portal web site in the same Dynamics Instance? You may want to ask “why would I do such a thing”, but think of it this way:

  • You cannot link the same Dynamics Portal to more than one web site record at a time, but you can still create multiple web sites and switch your Dynamics Portal between those web sites
  • With a little imagination, you can actually come up with a bit of development framework even when you only have access to just one Dynamics Portal (you would use your original web site as a “dev” site, you would do development on that web site, and, then, you would copy that web site to a production “web site” record once it’s all done, and, then, you would switch Dynamics Portal to use that web site record instead of the “dev” one)
  • Sure that leaves the question of how do you stop external users from going to the dev site while you are working on it, but that can be done through IP filtering:


Or, maybe, there is another scenario where you’ll find this useful.. Either way, this post is all about creating a copy of the web site record (and all the related records: web pages, languages, web files, etc)

First, there are a few pre-requisites for this exercise

I will be using the latest build of EZChange, so, if you wanted to follow the steps below, make sure to get that build first.

Once you have it, create a folder somewhere and two files in that folder:

  • portal.ecp
  • variables.xml


The first file there is a package definition file for EZ Change. The second file is where you will specify the connection strings.

For the content of those files, have a look here:

Just copy-paste the content from the corresponding sample files on github above.

In the end, you should have a folder that looks like this:


And another folder where you have extracted the EZ Change(before extracting, make sure to unblock the zip file):


You will also need a Dynamics instance with Dynamics Customer Service portal installed(at least that’s what I tested), but it will likely work with other portal types, too.

Once you’ve done all that, follow the steps below

  • Start ItAintBoring.EZChange.exe
  • From the File menu, open Potal.ecp packageimage
  • From the Package menu, open “Variables Editor”, select “qa” environment, and update the connection string:
  • From the Package menu, select “Build” option. You’ll be asked for the environment, so select “QA”. Then click ok and wait until the build has completed. This is when you’ll get one more sub-folder in the same folder where the Portal.ecp file is stored – that new subfolder is where all the exported data and solution files are stored for the package druing the “build” phase:
  • image
  • Now you can run the package (“Package”->”Run”). It’s going to take a while to run it – in my case it takes at least 25 minutes, but, in the end, you are going to have a copy of your web site record(s) including all the web pages, forms, etc:
  • image


You might want to rename the newer ones(look at the “created on” to identify them) so you could easily see the difference.

There you go – you have cloned your web site(s)! Feel free to bind you Dynamics Portal to a copy now:



A few things are worth mentioning here

  • There are two solutions in the Portal.ecp package. They are not linked to any Dynamics solutions – all we need is to export/import data. However, the first solution will have some build actions (data export), then some run actions (disabling the plugins and importing data). The second solution will have run actions only: second pass for the data to restore the references, and, also, a few actions to re-enable portal plugins
  • Data import actions are expected to keep original record id-s. So, to create a copy of the web site, we have to modify those ID-s consistently. This is why, for the “Portal Data” solution, Guid Shift parameter is set to 1 – this will ensure that all guid-s in the exported data are “shifted”(this applies to both entity id-s and lookup references):
  • image
  • Web Site Binding records won’t be copied through this process – Dynamics Portal can be linked to only one web site at any particular moment, and that linkage is maintained through the Portal Admin page

Note: will try adding a video late

Development for Dynamics – how it evolved


A lot has changed for Dynamics developers over the years. I was looking at this old post (well, 6 years old) by Gonzalo Ruiz, and I am still wondering what to make of it now:

I think traditionally we had these 4 options when setting up the environments for the project (well, other than doing development directly in production, of course, which is always an option, too):

  • Option 1: We can use that option described in the blog post above. Which is where there is a master configuration environment, all configuration changes are done there, and all customizations are done in the local development environments. How many environment do we need, though? Well, it’s roughly as many environments as many developers we have on the team plus a few more for QA/UAT/Production
  • Option 2: Instead of that, we might use a shared development environment and use a separate environment for integration. That comes with a lot of funny problems, but, mostly, it’s all about us, Dynamics developers, having to carefully avoid each other. “Don’t touch that since I’m working on it..” – that’s what it usually sounds like
  • Option 3: We can certainly do custom development in the shared development environment and drop the integration environment altogether.  What we had for Option 2 is becoming even a bit more messy this time around since, yes, we now have to also figure out how to export our changes from this shared environment and bring them to the upper environment (say, QA.. or, possibly, directly to Prod?)

I guess there are some other options, too, but.. As Dynamics projects are moving to the cloud, more and more teams are facing a choice where they have to deal with a limited number of environments. Of course that’s more  a problem for bigger teams than it is for the relatively small teams where it’s easier to coordinate, so, possibly, not every project is affected. But still..

Well, there is always one more option. We could be using a mix of on-premise/online environments through the dual rights licensing.  That sort of defeats the purpose of going online since, out of a sudden, we need to start supporting on-premise environments for development. That creates another challenge since online version is, normally, ahead of the on-premise. Besides, not everything can be developed on-premise these days (thinking of PowerApps, Microsoft Flow, etc)

So, what is your preference? What works for you?

Registering your client app to access Dynamics through WebAPI

A couple of hours, and I finally got my Dynamics authentication token in PostMan! The rest will be all about using that token, but, if you have not tried setting up PostMan before and don’t want to spend a couple of hours figuring out the authentication part.. Maybe this post will help.

Actually, the essence of the process is described in details here:

So, when trying to get the authentication token, and if you get an error like this:

Message: AADSTS50011: The reply url specified in the request does not match the reply urls configured for the application: …

Make sure you are actually using the same reply url in the PostMan environment settings that you used to configure the application in Azure:


In my case, I just did not use https in one place, but used it in the other:


Literally, I was using a different reply URL. Took me a little while to figure it out.

Still, if it’s the first time you are going over the registration process, you might be trying different parameters in the attempt to get it to work, you may also get this kind of error:

AADSTS700016: Application with identifier YYY was not found in the directory ZZZ

If this happens, just make sure to use Azure ApplicationId :


For the PostMan clientId variable:


With that, everything should work.

So that’s it.. my little “feel like a beginner again” post is ready – happy WebAPI-ing!

Dynamics Portals and accessibility requirements


If you are not sure whether Dynamics Portals address global accessibility requirements, there is an easy way to find out without actually having to re-test each and every page. Although, I have to say when this question came up earlier today I really had no idea what to answer. On the one hand, as a Dynamics consultant I don’t run into this kind of questions too often – accessibility is, usually, more important for the client-facing web sites. But, on the other hand, that’s exactly what the portals are, so that’s a valid question.

So, if you are wondering, just go to the link below and do a search for “Dynamics 365 Portal”:

Then download WCAG report and have a look.. Here is just a quick example of what you’ll see there:


Dynamics CE instance planning


If you had different applications which could all be implemented in Dynamics (maybe different flavors of the case/contact management), how would you decide whether to put those applications in the same instance or whether to set up different instances for some of them?

Not sure if there is a simple answer.. My colleague and I spent a couple of hours brainstorming this question earlier today, and it does not seem that we came up to any conclusion yet, so, if you have any thoughts, you are more than welcome to join inSmile

To start with, why would we want to have a separate instance for each application?

  • We can have clear data separation – there is no risk data from one application will surface in another application
  • There is no need to worry that configuration or customization changes made for different applications will start interfering with each other. This applies to the business rules, workflows, plugins, scripts, etc.
  • When the same entity is added to two applications in the same instance, corresponding entity views may show up for each of the users. Well, we can still control which views will be added to which apps, so, at least in the UCI, there is a solution for this. Same with the forms and dashboards
  • There is still a question of field labels and translations – what if two applications end up using slightly different vocabulary? Those labels will be showing up in the column titles and/or in the advanced find
  • Duplicate detection rules may become somewhat complicated, especially when some users have access to the data in one application, and others have access to the data in multiple applications
  • Regression testing is more complicated when the instance is shared – when updating one of the applications, we may have to run regression testing of all other applications
  • Every instance can have different dynamics portal (well, portal add-on may still have to be purchased)


On the other hand, why would we use the same instance?

  • All those complications aside, when it’s the same instance we don’t need to buy an add-on instance(or a set of add-ons to cover dev/test environments as well). This also applies to the portal add-on
  • Data sharing may have some benefits (for example, rather than having duplicate contacts in different instances, we might have just one contact record)
  • Added on Dec 11: If a user has access to more than one application, outlook synchronization for tasks, appointments, etc will work only when those applications are in the same instance ( as Lema mentioned in the comments below and as Joe Gill mentioned in his twitter reply )


Just by looking at the above(and I’m sure there can be other reasons in both categories), I am wondering if it would it be fair to say that, once two applications have different data models and/or data governance rules, they should certainly be separated on the instance level? In other words, an application in Dynamics seems to be more about working with the data than about the data itself(therefore, if the data is different, there should be different instances, but, if it’s the same data, it could be the same instance). Even in terms of cost-efficiency it might be better to invest into extra instances in this case since we’ll be saving on the extra work.

Or is there something I’m missing and there are other ways to think of this?

Dynamics Portals: setting up event registration web site (Part 4)

Since I am using “event” entity to actually work with the event registrations through the extra fields (see Part 3 of these series of posts), I need some server-side logic to process those fields.

In this post, I’ll describe how it’s been set up using classic Dynamics workflows, but it might be interesting to convert all those workflows into Flows, so maybe that’s what I do in one of the following posts. For now, though, let’s have a look at the processes below:


The first one on this list is a custom action that returns portal url as an output parameter. This way I only need to update the url once when/if the portal moves, and I can use that custom action in the email notification workflows without having to update those workflows in such cases:


The second process is an on-demand workflow that will de-activate event registration – nothing extraordinary there:


The third one is an on-demand workflow that will take an event registration and pull it from the waiting list, so it will:

1) Update a couple of properties on the event registration

2) Send an email to the contact

3) Reduce the number of available registration slots on the event

4) Wait for a couple of days

5) And, if the registration has not been confirmed by the contact after those two days, it will deactivate the registration


You will see that it’s using Get Record Id custom workflow activity to get the id of the records. And it’s using another child workflow to recalculate available registration slots. In both cases, it’ll be using custom workflow activities from the TCS Tools solution:

In particular, that “Recalculate Registrants” step will use an attribute setter custom workflow activity to get the number of active registrations linked to the event and to store that number in the “Number of Registrants” field on the event entity:


Once it’s there, remaining timeslots field on the event entity will be automatically recalculated:


Then, there is another workflow that will create or update event registration record when needed (again, this one is registered on the event entity since that’s how the data will be coming in from the portal):


Finally, whenever an event registration is deactivated/created, a workflow will start on the event registration:


This workflow will start a couple of child workflows. We’ve seen the first one already – it’ll recalculate available slots on the event.

The second one will check if there are free slots, and, if yes, it will try pulling an event registration from the waiting list, and, if there is one, it will start “Pull From Waiting List” workflow on that record – we’ve seen that workflow above, too. This is done with the help of TCS tools, again, so here is how it looks like:


And, btw, if you are wondering how the current version of the event registration web site looks like, feel free to have a look here:

As of Dec 6, there is a test event there that you can try subscribing to. I might, as well, use it to set up a real event (training maybe?), but that’s still to come..