Citizen development in the Microsoft Power Platform is a very attractive idea. Lots of companies would like to reap the benefits, but many are hesitant because it often presents more challenges than benefits. First, let’s take a look at what makes it attractive. The premise of allowing individuals and small groups of employees to create their own unique applications to optimize their workflows is amazing.
A simplified example of this might be a traditional CRM application built to manage sales efforts. Imagine a nuanced or bespoke need from a small group of sellers to capture and track gifts given to customers during sales cycles. A citizen developer can quickly and easily create an app that pulls in all their open accounts, contacts, and opportunities, then add a custom table for gifts to track items like bottles of wine, gift baskets, theater tickets, dinners, and so on. By combining a traditional CRM like Dynamics 365 with a bespoke Power App, everyone is happy with the least amount of organizational cost and disruption.
The IT team can deploy and manage large-scale apps for common tasks like sales, accounting, and logistics. But rather than trying to adapt these large applications to fit every bespoke user need, they can ideally offload that to requesters with low-code, no-code applications. This allows the business to operate with control and predictability through managed applications while staying nimble with bespoke apps at the citizen development level.
Additionally, the licensing cost for citizen development apps is generally much lower, which is another appealing factor.
The Risks of Citizen Development
So what’s the downside? While Microsoft Power Platform offers many advantages, it also comes with inherent risks. In this article, I will expose some of those risks, particularly around the data stored within Dataverse. The following challenges often arise when organizations adopt citizen development or low-code, no-code application development:
- Inconsistency in application development efforts and life cycles
- Design-blind data overwrites in a common data model
- Lack of data functions for a Center of Excellence (CoE)
Inconsistency in application development efforts and life cycles
First, let’s explore the issue of inconsistency in application development efforts and life cycles as it relates to Dataverse data. Returning to the gift tracking example, after using the app and compiling a significant amount of data, the internal audit team might define a need to track age verification for any gifts of alcohol. They build their own app and use the existing gift app table data to filter records for wine or alcohol gifts. Without informing the sales team, they change the status field values from "sent" to "auditing" or "audited."
This inadvertently corrupts the sales team's data. When the sales team sees these unfamiliar status values, they send a replacement gift to the customer. By the time the error is discovered, it's difficult to identify which records were changed and which gifts were resent, creating confusion and unnecessary costs.
Design-blind data overwrites in a common data model
This gift tracking example also introduces an indefinite loop and the phenomenon of design-blind data corruption in a common data model. While receiving unlimited bottles of wine might sound great to some customers, it presents significant cost and audit challenges. Imagine the complications if recipients were under legal drinking age and kept receiving gifts from the company!
To fix the corrupted data, the native solution would be to restore the entire environment. This means all data and metadata (including apps) would revert to the state from a week or two ago. Not only does this wipe out all new records created since that recovery point, but it also reintroduces old bugs and removes any new features. This is a disaster waiting to happen, which is why many organizations shy away from citizen development.
Lack of data functions for a Center of Excellence (CoE)
Another issue is the lack of specific data handling capabilities in Power Platform. In a CoE, there is often more focus on the “C” (centralization) than the “E” (excellence). While centralizing administration of a tenant and its Dataverse environments has matured rapidly, the ability to manage data at an “excellent” level is still limited.
For example, restoring an environment requires enough storage space to accommodate a full duplicate of the original data. If you have a 100GB environment, you'll need an additional 100GB just to perform a restore. Worse yet, you can't inspect the details of the backup without restoring it in full first. This makes it costly and inefficient, especially when you consider the unpredictable restore times that can be influenced by infrastructure demands.
Navigate Citizen Development Risks with Own
These examples are just the tip of the iceberg when it comes to the risks associated with citizen development in Power Platform and Dataverse. Without the right tools and processes to isolate and restore data, organizations can face serious consequences.
With Own, you can protect your critical Dynamics CRM and Power Apps data, maintain compliance, and minimize the impact of data loss or corruption. Our solution allows you to restore records up to 10 levels deep for retrieval at a great hierarchical depth. Plus, you’ll have a usable copy of all your data so you can replace lost or damaged data at any time, ensuring continuity.
Click here to learn more and request a demo.
