That title is quite a mouthful, and I did try to collapse it into a few succinct statements but couldn’t make it work. But this is a question I see all the time and like anything, there are a few ways to handle it.

The Problem

You have a number of developers working on multiple initiatives in your PowerApps Environment, how do we get them to stop bumping into each other?

This problem has existed for a while and unfortunately, PowerApps doesn’t do itself any favors because it provides a great big sandbox for everyone to jump into, use, and play with as much as they want. At firs,t you all start playing around with ideas in the sandbox, and the next thing you know you’re building solutions and pushing them to different environments.

When I talk to people about this problem, I generally like to use the Visual Studio example – “Would you buy one copy of Visual Studio and have everyone on the same machine, editing the same project files at the same time?” No, you wouldn’t, but that’s what you’re trying to do here.

Below are some options you can consider when thinking about this problem, however, like any software project, how you have architected your solution and how your delivery process functions will directly impact what option you go with. It might be that you need to consider a few options.

Option #1: Individual Development Environments

Yes, individual development environments can avoid the entire overwriting of other people’s work, however, this will require a more stringent approach to solution development as every developer will always want to have the latest “core” solutions so they are always building against the latest and greatest. This is very easily accomplished by changes in PowerApps Pipelines now but if you have 50+ solutions in your architecture could become a bit unwieldy to start with.

When looking at individual development environments, it’s important to ascertain what level of individual environments you need;

1. Developer – Every developer gets their own environment.
2. Team – Every team gets their own environment (maybe teams of 2 – 3 where they communicate more.
3. Feature – Every component/feature (i.e., service or marketing) gets its own environment and if you’re fixing issues in that area, you work on that tenant.

Any system can work, you will need to ensure you know how you are going to get changes from those multi-environments into the main “integrated” environment where everyone’s code gets merged together to ensure everything lines up.

Option #2: Changes to your Delivery Process

Are you assigning 5 tickets to work on the contact entity to 3 different people all at the same time?

Has someone looked at that work to ascertain whether they are all changing the same forms at the same time?

Generally, when I hear of teams bumping into each other it’s also due to how work is being laid out and can easily be solved with a bit more communication. PowerApps has evolved to have people who are focused and specialize in areas of PowerApps – creating tables/fields, working with the UI, building web resources, etc, etc.

The same goes for competing delivery schedules. If you’re assigning someone work to start on the account table today, and that work will take 1 day to do but someone else is starting work on the account table at the same time, but their work is going to take 2 weeks – why don’t you push out the 1 day change sooner? Granted this is a simplistic example and what I have seen more often than not, is that work that is still in progress is held off and/or hidden and/or uses a toggle switch to hide that feature – just like we do in other areas of Software Development.

Option #3: Evolving Solution Architecture

What you built yesterday can change tomorrow. This is good, this is great, you should be doing it so go for it. I know it’s a pain when you’ve built this wicked awesome pipeline, DevOps infrastructure that is amazing and gets everything done for you and everything is running smoothly. But software evolves, architecture evolves and your system needs to evolve with it.

Changes to your solution architecture are not a failure, it’s a growth strategy. If your team is growing, it might be time to take a look at it. If you have people that are more focused on back-end processes, let them run with that and leave the tables and UI to another team. Both sides will thank you, because now changes that should not impact each other are no longer impacting each other – which is the goal of the entire system as a whole.

Don’t hold your team back, embrace change.

Many of the problems that we run into in the PowerApps world have already been solved in any software system to date. The problem is we were able to “get away” with many things in the PowerApps world that as we scaled our teams – team size, workload, and solution architecture – didn’t hold up and in the case of the latter – we didn’t want to change. However, if you take a page from any application built on any language, the architecture, code, and project structure are constantly evolving in exactly the same way for exactly the same reasons.

It’s okay (and great) to change your strategy with PowerApps, the platform is designed for these changes to happen.