Hello friends! I’m back with a new blog post after *checks watch* about a year and half. Better late than never and I have my excuses all lined up.
The main one is that I disappeared off down a rabbit-hole of developing services related to COVID-19 and all the manic, reactive, overtime accruing intensity that you might imagine that would entail.
I have re-emerged with a *lot* of experience and opinions on the so-called ‘low code’ technology stack on the Microsoft cloud platform — Power Automate, Power Apps, Dynamics CRM / Common Data Platform aka Dataverse and many of the associated Azure services you can plug in to those things.
So this blog is going to be my summary of lessons learned and key take aways from that experience, what I thought worked, what didn’t so much and what skills a team needs to build on to successfully deliver.
Addressing “Low Code”
Let’s quickly deal with the reductive label first— we always need to have one seemingly.
We’re going to be examining this through the frame of the Microsoft Power Apps platform and related technologies, given that’s my experience. Your mileage with other vendors may vary!
I’ll start with the premise that NO CODE is just pure semantics and it doesn’t really tell you anything helpful about the reality of trying to build a useful and complex service using the type of tools we’re going to talk about.
Lets take Microsofts own words to describe Power Apps:
Power Apps provides a low-code approach to rapidly build apps for any device, while seamlessly working with your Azure-based services through a rich professional developer extensibility model
Power Apps Platform can be broken down into the following services (leaving Azure mostly to one side — that’s a whole other story), and I’ve used all of them to a greater or lesser extent at this point:
These will be largely familiar to people who previously developed solutions for Dynamics CRM, either the current 365 cloud offering or the on-premise version.
- Often foundational to other elements of the stack that you might want to use. For example your Canvas or Portal app will likely make use of any custom business entities (tables) defined here
- Model custom tables, business processes, workflows, and code if you need it (hint: you probably will)
- User experience is ‘on rails’ and significantly restricts what you can build
- As such the training requirement is higher and users with lower digital skill levels will need help in this regard
- Requires some form of full Dynamics CRM license associated with a known identity (e.g. people in your Azure AD organisation)
- As stated above — you will likely need one of these regardless of which route to decide to go with the user-facing solution(s). It doesn’t have to be the Model Driven App — that’s the key point. You could build models and rules using the MDA and then surface functionality to users via a Canvas app
- C# plugins are the devil and kind of like putting all your business logic in database triggers. Sometimes there is not a great alternative depending on the complexity of what you need to achieve. This is where your NoCode hopes and dreams will go to die. My advice is to try and keep them simple and isolated in what they do (i.e. avoid plugins triggering other plugins)
- Your team will need dedicated Dynamic CRM / Dataverse expertise for both development and ongoing support and administration. Do not neglect how users will be created, onboarded, off-boarded, supported and their access control generally managed. This will be a mix of Azure Active Directory and Dynamics Security Administration itself, but the boundary is flexible and can lean more towards one or the other
The option for when you want to surface some process to external users via a simple website
- User identities can be anonymous or they can be linked to some external identity provider (e.g. AAD, Facebook, LinkedIn etc.)
- The permissions model is different to that exposed by a model driven app. For example, Dynamics security roles are not respected by default if you login with a licensed Azure AD identity
- The designer is… basic. That’s about the kindest thing I can say about it
- If you want to get into the nuts and bolts of more complex page design then be prepared for a world in which you edit HTML templates embedded inside Dynamics CRM custom entities. The learning curve is steep here and the developer experience poor
- The user experience can be much simplified versus a model-driven app, but you will still be quite tied to the underlying views and forms that have been created in the model-driven app itself
- Upgrades require down-time. You have the option for a maintenance page, but just be aware that 100% uptime scenarios are going to rule this one out
Allows for bespoke UIs to be built on top of a model-driven app/common data service environment
- Much more flexibility in terms of design of the UI than a Portal App will allow. Accessibility to a WCAG AA standard can be achieved and has tools to support this during development.
- Unlike Portals, these DO respect the core Dynamics CRM security model out of the box, so views will be filtered according to staff business unit or team membership if desired
- You can scale delivery by building multiple different Canvas Apps in parallel to act as views for different user groups onto a common underlying data model
- Licensing is more cost-effective than consuming the full Dynamics license required to access a model-driven app directly
- Good where you need a simple sequence of screens which allow users to perform a more focused set of tasks
- “Low code” again is a purely semantic here. Instead of writing JavaScript you are writing something which is akin to Excel formulas. If your application needs validation, conditional display rules, conditional navigation or any of the common things which reasonably significant production software would need, then congratulations — you now have “code”
Formerly known as Microsoft Flow, PA is a way to build drag-and-drop workflows which interact with your model-driven app, canvas apps, other 365 platform applications (e.g. Microsoft Forms) and other third party external systems.
- Good for scheduling simple batch workflows on the platform. For example, run a Dynamics entity query and then perform some action over the list of records. They can be a good way to “fix-forward” bulk data issues that you encounter. Remember that you don’t have any direct access to SQL Server database in this brave world of SaaS Dynamics
- Good for approval based workflows and process automation. Regardless of any end-user applications we built, I used Flows for email-based approval workflows with the team and the client
- Not so good for high intensity workflows where reliability, performance and detailed monitoring are key (See NFRs below)
- Given what they are, they can be difficult to test and maintain once they reach a certain level of complexity. You are best advised to keep any given Flow simple and if you need something more complex consider de-composing your Flow into a parent plus several children which it calls
Non-Functional Requirements are key
This statement is true when you build the infrastructure yourself and it’s also true when you delegate some portion of this responsibility to a SaaS layer of abstraction.
Much of the benefit gained from using these Power App platform tools is in freeing the team from the need to stand up infrastructure on which to run the service and by extension from the need to own everything that comes with it.
The context for this service delivery meant that there was limited time to write the infrastructure-as-code, conduct the performance testing, schedule external pen testers, resolve the findings of said testing and put in place the team to support all of those things on an ongoing basis. Let alone taking into account the lead-time getting approval to do any of it.
The key points to consider then of a more SaaS based approach are:
- SLAs are already in place which may be good enough for what you need. You just need to be careful that you understand these and that your requirements for uptime, for transactional throughput, for security and for accessibility can be met
- You also need to understand that better SLAs are going to be tied to license tiers. For example, the throughput of Power Automate flows has it’s own licensing model which will accrue additional cost the more transactions you need to handle (See “Per Flow Licensing”)
- The same goes for observability and operational resilience. For example, Power Automate workflows are in my opinion fine for automation of a range of day-to-day business processes and tasks. However if you need high-volume, reliable and measurable throughput on integration between systems then Logic Apps is the better alternative. The flows are largely portable between the two, but the pay-as-you-go nature of the Logic App flows on Azure and the integration to Azure Monitor make it the better choice for that scale of use case
- Testing is a challenge in all of this. As you have given up the notion of “normal” code or infrastructure as code, you have also given up on things like unit test frameworks. Any kind of testing you do will thus be a similarly higher level of abstraction.
- Licensing is just generally complex and requires support from the supplier to help you choose the best fit for the clients needs. The difference between a solution which licenses 1000 users for Canvas app access is going to be significantly less expensive than one which is solely based on a Model-driven app UX
- For all of the above options the challenge of the Service Designer and the User Experience Designer is significant. Tools lack the flexibility to tailor the experience to the same level of a bespoke web application and here a trade-off is made and skills are developed as people become familiar with those limitations
- Automation is possible using Azure DevOps, but is not a widely held skillset — many things in the Dynamics 365 world are still done manually and finding good examples of pipelines which can deploy and/or rollback Solutions (the deployable units of Power App applications) are surprisingly thin on the ground. Innovation in this area is a big differentiator and our team put in a lot of work on improving the reliability of this process
- The core Common Data Platform/Dataverse on which all of the platform components sit is what feeds your data analytics and reporting. This could be a whole blog in itself (and maybe it will be!) You have options for operational reporting in Dynamics Model-Driven Apps, exposing dashboards via Canvas Apps, using Power BI or replicating data into Azure for off-line analysis using the vast array of tools which can be leveraged there. This should be a core part of any technical strategy when using the tools this platform provides to build a service. We have used all of the above things in combination.
Power Apps — a good fit?
Based on the outcomes for the client and the public — yes it was. Hindsight being wonderful and all, of course there are many things I would do differently, but relying on many of the Power Platform SaaS services ultimately made delivery possible in many cases.
Delivering complex services requires a combination of different technical approaches, and one size does not fit all.
Some components required the flexibility, performance and reliability of Azure infrastructure, other components could be rapidly prototyped using a combination of model-driven and canvas apps to cope with the equally high rapidity of changing requirements.
As ever, our job as technologists is to know what’s on the shelf that we can reach for when needed and the Power App platform has many interesting tools which are worth consideration if you are in the Microsoft space.
