Monthly Archives: December 2018

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:

http://gonzaloruizcrm.blogspot.com/2012/01/setting-up-your-development-environment.html

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:

https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/webapi/setup-postman-environment

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:

image

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

image

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 :

image

For the PostMan clientId variable:

image

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”:

https://cloudblogs.microsoft.com/industry-blog/industry/government/accessibility-conformance-reports/

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

image

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:

clip_image002

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:

clip_image004

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

clip_image006

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

clip_image008

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:

http://www.itaintboring.com/tcs-tools/solution-summary/

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:

clip_image010

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

clip_image012

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

clip_image014

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

clip_image016

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:

clip_image018

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:

https://treecatsoftware.microsoftcrmportals.com/

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