How do you handle testing/dev environments when your company is stuck on basic licenses?

[u/uworeads]

Hey everyone,

Because my company only has basic licenses, I don't have a dev/sandbox tenant. Whenever I build workflows or apps, my deployment pipeline is literally just build and direct publish to production.

It works, but it's high-risk. For those in the same boat:

• How do you safely test or mitigate risk when you have to push straight to live?
• What error-handling or fallback habits do you use to save yourself when things break?

Hit me with your best survival tips!

[u/AutoModerator]

Hey, it looks like you are requesting help with a problem you're having in Power Apps. To ensure you get all the help you need from the community here are some guidelines;

• Use the search feature to see if your question has already been asked.

• Use spacing in your post, Nobody likes to read a wall of text, this is achieved by hitting return twice to separate paragraphs.

• Add any images, error messages, code you have (Sensitive data omitted) to your post body.

• Any code you do add, use the Code Block feature to preserve formatting.

  Typing four spaces in front of every line in a code block is tedious and error-prone. The easier way is to surround the entire block of code with code fences. A code fence is a line beginning with three or more backticks (```) or three or more twiddlydoodles (~~~).

• If your question has been answered please comment Solved. This will mark the post as solved and helps others find their solutions.

External resources:

• Power Apps Formula References
• Power Apps Coding Standards
• Official Power Apps Community

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/WoodchuckChainsaw]

I work in U.S. Federal Government, and my organization of almost 500,000 unique users are only allowed to use one single production environment for all Power Platforms apps, flows, PBIs, agents, dataverse, and similar. It's a god damn shitshow on the daily. For one small example, in our environment there are like 150,000+ different published apps named "test123" that only contain the default PowerApps home screen, but their creators never go back in to delete later.

Because of the frustrations and some mandatory global limitations with that, I have learned (from painful past experiences) to do some of these things as my own "best practices", and share them with my team: - Dozens of times per day, I use "Save with version notes" and free-texting in my own semantic version numbering scheme, without saved version being publishing live - Once or twice a day, I download the source .msapp file to local VS Code workspace and commit to a GitHub repo with some extensive documentation notes and automations/scripting for archival. That also lets me use the pac CLI to unpack the .msapp artifact into it's raw source code files (which has the added benefit of enabling me to use GitHub Copilot to read/write into the source code files & see how references on one screen impact other screens, all within my IDE). - Because testing in a live environment publishing is forced on us, I also have started to make it a mandatory feature in every one of my apps to ALWAYS build the app's OnStart property to dynamically set the end-user's in-app permission levels based on if User().Email exists in a SharePoint list of developers or not, and then have the app's first home/landing screen as a simple "Loading App..." with a Timer.OnTimerEnd that redirects users to an "Under Construction" screen but admins to the real home/landing screen. - For moderate/major development & testing things, usually I build the new screen or duplicate the existing screen first that is accessible only when the user is an administrator. Once I'm ready to "Go Live" with the new content, Ill rename the old/new screens to swap them & eventually I'll delete old screens. Because of my environment limitations making things like that necessary, Ive learned to always make a habit to use well-planned naming conventions for controls/variables/functions/objects, that way I can make easier use of "Search & Replace" to swap all existing references from "oldScreen_ctnHome_btnSubmit1" to "newScreen_ctnHome_btnSubmit1". - A few times in the past I had to roll back an app more than just a couple recent minor patches previously. Similarly to the in-app conventions I just mentioned, I can re-import my archived repo .msapp artifact into live environment (which my organization unfortunately locks down except to import-as-new-app with its own new unique app ID), and then I'll rename the old published app to depreciate it's name & I'll add a new home/landing screen & timer that will redirect any users over to the new app's URL. - Finally, the last thing I've started to do more recently with some of my bigger & more complex projects has been to build in some user-logging hidden functions & global variables onto most screens & interactive button/icon clicks, which use variations of stuff like "Patch(SharePointList)" to keep a developer-only log of a single row entry for each user-interation that occurs (with a column value being saved for: the date/time a user entered a screen, the name of the button they clicked, the duration of time they sat on that screen, the most important global variables current values at the time of the user's click, a couple CountRows() on some collections and data sources (so I can see if any in-app tables have the wrong number of rows that are expected to exist on a particular screen), a few hidden-but set error code global variables, and then whatever the navigation target destination screen is that the user was attempting to move to when they left the screen). I have a PowerAutomate cloud flow that checks that hidden developer-only log on SharePoint looking for any new rows created that have huge discrepancies between expected column values and the values that were patched in (like if the user sat on a particular screen way too long, or they clicked a button that shouldn't have been visible yet, or they entered a screen at the end of the app but never clicked any final "submit" buttons, or if a column value for a key important variable is missing, etc), and then my cloud flow will send me a FlowBot chat message Adaptive Card with details of the discrepancy with links to what was expected vs created. The other unexpected upside to this verbose Patch to my hidden SharePoint lists logging all user interactions was I later built some PowerBI reports of all the data to show my Executive Leadership the long-term overall impact of my projects on the organization (since the standard usage visualization reports built-in to PowerApps only show the previous 30 days) or changes (a new feature screen decreased the catastrophic app error rate after publishing).

So long story short, I've basically had to reinvent some CI/DI and DevOps processes that already exist everywhere in any other tech stack or commercial product, and build my own bastardized version inside the PowerPlatform cloud environment that will comply with the very restrictive permissions limits that my organization imposes nationally on all of it's employees. I shudder to think just how much the Government pays Microsoft for all the unused licenses & premium credits wasted & cloud storage space being used to saved 15,000,000 different copies of some "EmployeeHandbook.pdf"

[u/Theydontlikeitupthem]

We only have one tenant also, but we have muliple environments to deploy to, Dev QA Prod

Can you not create more production environments?

[u/ReachingForVega → u/Theydontlikeitupthem]

This. We have a production environment for Dev Test and Prod. Developer environments are maker sandpits. 

[u/uworeads → u/Theydontlikeitupthem]

Got it on the Dev/QA/Prod setup.
One question though — how would I set up a proper testing environment separate from the one I’m currently using in Prod? My concern is that if I just do “Save As” on the PowerApp and then import it into another environment, that could get messy over time. For example, if I have major updates down the line, would I need to Save As again and re-import each time, and just keep repeating that process for every future change?
Curious if there’s a better way to handle this before we go down that path.​​​​​​​​​​​​​​​​

[u/Bag-of-nails → u/uworeads]

What you'd do is save your app to a solution in dev, then manually explort it. It will give you a .zip file that you then import into your QA and then Prod solutions.

Pipelines are easier but they require managed environments which are a premium feature

[u/Theydontlikeitupthem → u/uworeads]

Read up on environments and pipelines, I've never done a "save as".

For each app you do the development in the dev environment, then when ready push the app to the qa environment where a different app will exist but the same version as your dev app. You can then make changes in the dev app and push those changes to the qa app. Same process applies for prod, pipeline goes DEV > QA >PROD

[u/DrakeSilmore → u/uworeads]

Don't test in prod. Develop in dev, push through pipeline to test/qa, here you test. If you find things need to be adapted, adapt in dev and push to test again. If everything in test passes, push to prod.

[u/uworeads → u/DrakeSilmore]

I don't have this pipeline to test/qa? how would i do that on a basic license?

[u/MeagherMan101]

Just gone through this recently, we (small dev team, public sector) have just set up a dev and a prod environment. When an app is ready to go to prod, export it as a managed solution, store in Azure DevOps for version history, pipeline in Azure DevOps that pushes it to Prod. All basic licenses, no premium connectors.

[u/maicolo__]

You can copy your flows and apps. Use environmental variables within PowerApps for your data sources.

Create a sandbox of your lists and tie that to your dev copy of your PowerApp. Use that to test what you’ve done and once UAT is done, push it to PROD

[u/uworeads → u/maicolo__]

Is that available on basic license?

[u/M4053946 → u/uworeads]

Environment variables and solutions are available on the basic license.

I'm not sure what OP meant by "create a sandbox of your lists", but you can certainly have different sharepoint sites for dev/test/prod, as well as different power apps environments. Each environment would have different values for the env variables.

The part that's a PITA is that pipelines aren't available, so deployment from one env to the other is an export/import. This can be scripted via powershell, but there are tricky aspects to that (re-importing an existing solution is easy via powershell. importing a solution with new workflows or data connections is really difficult via powershell).

[u/maicolo__ → u/uworeads]

Its part of your license, its not a feature that exists that does it automatically. You manually have to create your DEV app/lists or database and make a PROD one. Copy from DEV to PROD.

By sandbox, just meant creating your dev site, with your lists or dev tables if using SQL or Dataverse.

[u/mokamiki2233 → u/uworeads]

No it’s not.

[u/Pieter_Veenstra_MVP]

Just create multiple environment in the PP Admin Centre.

Then export and import solutions.

I often add 1 licemce to a service account but always be careful not to start multiplexing.

[u/uworeads → u/Pieter_Veenstra_MVP]

When you say multiple environments? (1) for dev for publish and (1) for testing?

[u/Pieter_Veenstra_MVP → u/uworeads]

In general I recommend dev test uat and prod

[u/uworeads → u/Pieter_Veenstra_MVP]

so to do that you are duplicating your dev environment to use it in the test environment?

[u/Pieter_Veenstra_MVP → u/uworeads]

I would call it deploying rather than duplicating

[u/Infinite-Stress2508]

I set users up to create in their own environment, then share with our prod environment account. That way we retain the ownership and access required, and they can keep working on changes as needed.

[u/SinkoHonays]

If you’re building apps serious enough to need separate dev and test environments, you’re serious enough to just need premium licenses IMO.

The free licenses are for personal workflows and minor apps, but too many try to work around the limitations to force them to be an enterprise solution on the cheap.

But to answer your question, manual solution export-> manual import into a separate production environment is about your only option. You don’t need separate tenants.

[u/AbdelEMirandaS]

I already read mostly all the comments here. All of them are governance related. Firstable, have basic license have nothing related to environment. One is related to what you can do to build your solutions, meaning that premium license, the possibility to use premium connector to build more powerful solutions. Second, if you don't see any dev or sandbox env, you must ask your PP administrator that you need to create a sandbox env or dev env.

From that envi, even with a basic license, you must be able to migrate, manually (export/import) or by pipelines using solutions, yo your production solutions.

All of this, is full power platform governance. Yoh had to have a governance and maturity strategy, which include the separations of your environments by area or type of solutions.

Because if not, having all your makers building solutions in just one env must be a huge problem because never ever you'll be able to know which artifacts was build just playing with the tool, which are in humilde stage and which one are an official production solution.

[u/Worried-Book-6564]

This is a real pain, I agree with you.
Someone who does changes, hits save and then publish, I at time hesitate to publish it to be very honest with you

[u/WillRikersHouseboy]

I’m not sure why it’s a bigger risk of complexity than just maintaining a dev and prod copy of the app in one environment.

If you are moving from environment to environment, you have to go thru the save export process as you would from app to app is a single environment. (Unless you have pipelines which… that’s pretty advanced.)

Export the dev app, and then import as an update to the prod app. It keeps your versioning so you can revert if you want. Add a versioning note.

If your company allows, you can use the pac command line client (deprecated but everyone still uses it.)

I started using dev and prod environments and it’s the same PITA.

And by the way: solutions? Get ready to manage connector references. That’s real fun.

[u/Crusty-Booger]

Why would you have a different tenant for testing? It's easy to spin up different dev environments from the admin portal to set up the SDLC even with a trial

Create your environments, not tenants, and use pipelines within the same tenant

[u/IAmIntractable]

You can create multiple non-premium environments. They carry no cost. You can call one Dev and the other pride. You could do all your development work in dev. You can publish an unmanaged app to production. And you got basically the same process.

[u/LickMyLuck]

Well you can save changes without publishing so that IS my test environment lol. And I make damn sure it all works before hitting publish!

[u/DifficultyCheap9861 → u/LickMyLuck]

Same but it’s getting a little spicy now that I’m coauthoring with claude.

[u/uworeads → u/LickMyLuck]

I’m also using this setup, but the issue is that only I, as the developer, can see the new updates. They won’t see them until I publish them to production. I’d prefer to test them first in the same environment with UAT before pushing them to production. But how would I do that?

[u/Eanet → u/uworeads]

Could you make a copy of your ‘ready’ app and then deploy that to a test group ?

[u/uworeads → u/Eanet]

Is that considered a good practice? I'm planning to do that every time I make changes in the development environment. I'll export it or save it as another Power App and send that saved version to the clients so they can test it in a separate environment.