Under the Hood – There’s a Dynamics 365 App for that

Microsoft has surely been looking at Salesforce for the past few years, feeling somewhat envious of their ‘apps’ market. If you take Salesforce at their word, they have over 1.4 million registered developers, so the apps market for Salesforce is clearly not a flash in the plan.

With the recent launch of Dynamics 365, there appears to be a concerted effort at Redmond to build an ecosystem around Dynamics 365, but how has this been implemented and what do application developers need to know?

365 Apps v Solutions

Back in the day when solutions were introduced in Dynamics CRM 2011, you could see the start of an effort by Microsoft to have proper application lifecycle management around Dynamics CRM customisations and configurations.

Unmanaged solutions were a way a developer could keep track of their many bits and pieces within CRM. Managed solutions were way of packaging those up and making it a bit harder for customers, competitiors or the uneducated or untrusted to update things you didn’t want them to.

Progress surely from the free-for-all that existed in CRM 3 and 4. But even with solutions, any seasoned CRM developer will have had issues migrating things between environments, and there was always a sharp intake of breath when moving something to production. If you accidentally changed something you didn’t mean to you risked bringing that change to production with you.

Between CRM 2011 and CRM 2016, Microsoft improved this functionality dramatically. New features added in CRM 2016 included adding the ability to manage the granularity of solutions. For example, you could chose to include only a form within a solution, and could clone a patch to move that form to a new environment without risking migrating other things that shouldn’t have changed.

I was recently talking to some experienced non-CRM developers who had cross trained in Dynamics CRM and received some CRM 2013 training. Their impressions of Solutions initially were positive, but ultimately they realised their real limitations – the need to present a friendly interface to the user.

What’s in an App? – It’s all about the Site Map!

For those new to Dynamics, the sitemap has gone through a few different iterations, I would summarise it’s evolution as follows.

• CRM4 / 2011 – Menu on left hand side of screen menu. Usability pretty good.
• CRM 2013-2015 – Top menu optimised for tablets. Poor usability. Lots of scrolling required.
• CRM 2015 SP1 / CRM 2016 – Much improved, back to CRM 2011 usability levels.
• Dynamics 365 – Finally improved on CRM4 Usability!

Traditionally, the site map in CRM 4 was a flat xml file you had to update manually. In CRM 2011, this same file became solution aware. But in CRM 2013-2016, usability aside, configuring the sitemap was not trivial. It involved either handcrafting XML (or using the excellent Site Map editor in XRM Toolbox).

Pre-Dynamics 365 User Interface – Busy Busy Busy

What confused the hell out of Dynamics CRM users was that they only wanted to see what they needed to see. Take the following scenario – a Complaints handler wants to use Dynamics CRM to handle Complaints. They have a complaint entity and maybe a case entity, some accounts and contacts. That’s it. Why is there a need to show them Sales and Marketing and Setting menus at all?

Additionally, there was a fair bit of low level work required on the sitemap by a developer to restrict things. If an Organisations sales function want to come on board for a different use case a few months later, things get harder to configure.

There was a need to configure low level security role permissions in conjunction with sitemap xml. Pre Dynamics 365, it was always necessary to configure security permissions BOTTTOM UP to tweak the User Interface.

365 Apps – Top Down Configuration

To quote Microsoft

“The new modular business apps are based on the concept of functional separation that let you choose to expose a limited set of functionality for users in Dynamics 365 depending on their area of work.”

In a non-marketing world, apps would/should have been called ‘Modular Business Apps’ or ‘Multiple Site Maps that can hide and show things’! However the app bandwagon had to be jumped on, and now we have ‘Apps’ and an in-built Microsoft developed editor to create them.

At first glance to a CRM user, this may not seem like a big deal however it has some massive benefits for developers, CRM analysts and ultimately users. You can now:

• Show only the solution elements you want a users to see. Don’t want to see ‘Orders’ for a particular role while still giving the user low level permissions to update it? – just hide it!
• Show only the views and forms you want a user to see. Tired of having to disable the all the Sales Dashboards and the ‘Contacts: No campaign activities within the last 3 months view’. Just don’t add it!
• Apply a different site map for a user role.
• Include apps in your solution – managed or unmanaged.
• Validate the app and it’s dependencies to make sure you have everything you need.

The new GUI for the app designer and sitemap editor is quite intuitive, especially if you have ever updated the sitemap before.

How does it work?

Once you have published an app, click on the Dynamics 365 text in the top left and it will show you all the ‘Apps’ available to your security role. Alternatively go to https://home.dynamics.com and it should show you any apps you have permissions to see.

When you click a sitemap, a GUID will be added to the end of the browser URL and the correct sitemap will be displayed.

AppModules, APIs and Limitations

If you really go looking under the hood, you will see that an ‘App’ is actually an entity called ‘AppModule’. All Dynamics developers will go ‘Yay’, we can access that and create them in code. Alas no, again to quote Microsoft :

“While the AppModule entity stores the modular app information and appears to support common messages and methods, programmatically creating, updating, and deleting AppModule records isn’t supported. This is because the modular business apps have dependency on other entities as well apart from the AppModule entity. Therefore, you must only use the new app designer to create and manage your modular business apps.”

Undaunted, I had a look at the undocumented AppModule entity, whose attributes I have documented below.

Attribute	Description
appmoduleid	Unique id for entity instances
appmoduleidunique	Unique identifier of the App Module used when synchronizing customizations for the Microsoft Dynamics 365 client for Outlook
Appmoduleversion	App Module Version
appmodulexmlmanaged	App Module Xml Managed
clienttype	Client Type such as desktop or MoCA
componentstate	For internal use only
configxml	Contains config xml
createdby	Unique identifier of the user who created the record.
createdon	Date and time when the record was created.
Createdonbehalfby	Unique identifier of the delegate user who created the record.
description	Description for entity
formfactor	Form Factor
importsequencenumber	Unique identifier of the data import or data migration that created this record.
introducedversion	Version in which the similarity rule is introduced.
isdefault	Is Default
isfeatured	Is Featured
ismanaged	Is Managed
modifiedby	Unique identifier of the user who modified the record.
modifiedon	Date and time when the record was modified.
modifiedonbehalfby	Unique identifier of the delegate user who modified the record.
name	Name of app module
Organizationid	Unique identifier of the organization associated with the app.
overriddencreatedon	Date and time that the record was migrated.
overwritetime	Internal Use Only
publishedon	Published On
publisherid	Unique identifier of the publisher.
solutionid	Unique identifier of the associated solution.
Uniquename	Unique name of app module
url	Contains url
Versionnumber	Version Number
webresourceid	Unique identifier of the Web Resource

The ConfigXML attribute stood out as a prime candidate for storing the new site map app definition. However, no attempt to retrieve it via code worked – the ConfigXML came back as null each time.

using (var xrm = new CrmServiceContext(_service))
{
	var apps = from a in xrm.AppModuleSet
	select a;

	foreach (var app in apps)
	{
		Console.WriteLine("Name:" + app.Name);
		Console.WriteLine("Url:" + app.URL);
		Console.WriteLine("ConfigXML:" + app.ConfigXML);
		Console.WriteLine("AppModuleXmlManaged:" + app.AppModuleXmlManaged);
		Console.WriteLine("WebResourceId:" + app.WebResourceId);
	}
}

If you want to get at this, you may have to revert to exporting and importing and manually amending solution zip files.