A few years ago while working at Celedon Partners, I wrote a blog post titled Dynamics CRM as an xRM Development Platform. In the post, we discussed the leveraging the Dynamics CRM platform to build Line of Business (LOB) applications. At the time, this was broadly called XRM development and essentially meant building relational systems that meet a particular business need. These discussions usually involve a comparison between using a platform versus building systems from the ground up. As an XRM example, we looked at building a Health Record system on the Dynamics platform, mapping out basic platform capabilities to general system requirements. It was pretty clear (to me) that XRM solutions stack up well against the build from scratch approach largely because since its early days, Dynamics CRM has been an excellent platform for building out these kinds of business solutions.
And in recent years, it’s only gotten better.
Leveraging the platform
In my Celedon post, we looked at some fundamental platform capabilities and approach to solution development. With Dynamics CRM, we can configure the underlying schema through adding fields to existing Entities, or adding brand new Entities and attributes of their own. Once you settle on your underlying data model, we can then design custom data entry forms, queries (Views), dashboards, reports, and even custom workflows that provide custom business logic. All of this can be considered configuration since it is done almost exclusively in the web based user interface and almost no code is required.
For more complex system requirements, we usually move beyond configuration into customization. This means engaging developers to code data processing or custom business logic to your solution. Dynamics CRM provides many options for developers: custom script added to data entry forms, extending workflows using custom workflow activities, new user interface components using HTML web resources, or registering plugins within the CRM execution pipeline.
But what if you do not have access to a development team but you still have some complex system requirements?
Microsoft is here to help! As the Dynamics platform evolves and their customer base grows, the Dynamics CRM product team adds capabilities for both developers and non-developers alike. This means adding more configuration options that had previously required customization. This sounds an obvious thing for Microsoft to do: you build software, so you release new features. But Dynamics 365 is a platform, not just a single use software solution. Extending a platform to support extreme customization can be a massive investment not just in building the features, but they also need to ensure you minimal negative impact on those already using the platform.
In deciding where to allow customization, I imagine Microsoft asks LOTS of questions before building anything. A few come to mind immediately:
- How in demand is this new feature by the community?
- Will this new feature actually be used by our customers and developers. If so, how many?
- Will this new feature break any other components in the current or upcoming release?
- Will the feature force current solutions to change their solution, and if so, how complex is the change?
- What is the return on investment?
- Will this make our current customers happy and attract new ones?
Tip of the iceberg when we think of list of system capabilities within the Dynamics CRM platform.
As tough as the process is, we see new capabilities with each release making things easier for designers, developers, and system administrators to deploy new and manage existing LOB applications. Some releases include relatively small but useful platform additions while other releases include what amounts to a new product launch. Here is a short list of examples from recent releases that stand out as Microsoft’s investment into the platform.
You can now configure your Entity grid to be inline editable right on your Entity form, built on the Custom Control Framework (another really cool topic). This feature has been in demand for several iterations of Dynamics and it finally arrived in 2016. This new feature has its quirks, but this is a significant investment by their developer team. Check out this post by Razwan Choudry on Configuring Editable Grids in Dynamics 365. This is a feature that might only be used in a few places within any given system, but Microsoft decided that this was worth the investment to build, deploy, and support as part of the platform.
This feature is a big step into making integration easy for non-developers. Many solutions require data from external systems, whether something simple like looking up a zip code or a complex integration with an accounting system. Virtual Entities offer a configurable method for making this external data available right within your Dynamics CRM system. Although the data provided is read only in Dynamics CRM, Virtual entities presents a solid option for many use cases when you do not have a development team available. Check out my post on Virtual Entities here: External Data Integration via Virtual Entities for a bit more detail.
Dynamics Portals is the result of the Adxstudios acquisition back in 2015. Adxstudios had been a gold standard portals solutions for Dynamics CRM for quite some time, so it’s a well known solution that Microsoft now includes as part of the Dynamics 365 solution offering. Customers can now add a Portal to their existing Dynamics 365 subscription and receive the same benefits of other hosted services in terms of managed hosting, SLA, and support. Both developers and non-developers can then quickly configure a public facing Portal to both capture and surface data to and from their Dynamics CRM solution.This is a big investment by Microsoft from a few perspectives: the initial purchase, the engineering effort to integrate the existing code base, and the infrastructure investment for hosting this new product.
What about other users?
So far, everything we discussed lives within the Dynamics CRM space. This is all really powerful stuff, but LOB applications frequently extend past the Dynamics CRM environment. Portals is a step in that direction as a solution for a public facing websites, and Virtual Entities allow users to pull in data from external sources through relatively simple configuration. These are options available to developers and non-developers, but ‘non-developer’ usually refers to someone with some level of technical skill. But what if I want to allow less technically trained users to design their own applications that integrate with your Dynamics CRM solution?
This demand leads to the idea of a “Citizen Developer”. Microsoft has been evangelizing the Citizen Developer at recent events as their plan to empower all users to build their own “low code, no code” LOB solutions. Here is a great post by Steve Mordue about the term: Dynamics 365 and the Citizen Developer. As Steve describes, this is not a new concept. But this time around, Microsoft seems to have a solid approach with their PowerApps service.
We’ve been seeing a lot of buzz around PowerApps recently, so what is it? Right from the PowerApps blog:
PowerApps is a service for building and using custom business apps that connect to your data and work across the web and mobile – without the time and expense of custom software development.
The PowerApps service has been around for a few years and I was skeptical as I first started reading about the service. What sounded like a great idea really did not seem like it was a production ready platform. With recent releases, the PowerApps service seems to have matured tremendously. What tipped the scales for me was listening to a talk by Charles Lamanna at the spring Tech Summit in Washington DC. Charles is the General Manager Application Platform at Microsoft and he presented a series of use cases around the PowerApps service. Check out his video that sums up his presentation: Business Application Platform: PowerApps | Business Applications Spring 2018 Release
As Charles describes, the PowerApp service provides capabilities to average users that previously required development experience. Users can quickly build a simple Canvas App that is easily deployed to organization user via mobile, or they can build a more complex Model Driven app that collects data and executes server side workflows. Either of these can be created right within the PowerApps designer with very little code outside of a few formulas that might be required along the way.
Scratching the surface
PowerApps is a big topic and this post only touches on a few of the PowerApps service capabilities. Things have evolved over the few years since its initial release and PowerApps discussions today usually include the Common Data Service, Microsoft Flow, and the overall Dynamics 365 platform. I plan on writing a bit more about the PowerApps service offering in future posts. My current interest is with Model Driven apps so I keep an eye out for more detailed posts in the near future.
A large collection of material is available for both those new to and already familiar with these services. The PowerApps resources provided by Microsoft: PowerApps Canvas Apps – Learning Resources is a very comprehensive list of training material with videos and labs. I have also registered for the new Pluralsight course by Vishwas Lele : Line of Business (LOB) Apps with PowerApps and Flow. I’ve just started the course but so far it provides an excellent overview of the PowerApp service capabilities.
In the meantime, what are your experiences with the PowerApps service so far? I would be interested in hearing about success stories as well as some pitfalls to avoid!