PowerApps production environment with no CDS is pointless ?

[R3dKap]

Hi all,

Is there any interest in creating a production environment in PowerApps using a PowerApps Plan 2 licence if my customer doesn't plan to use CDS but only SharePoint lists ?

Can it be relevant for customer not using CDS ? To what end ?

Thanks,

Emmanuel

[wyotim]

There are a couple reasons that a PowerApps 1 or 2 licence without CDS would make sense in my mind. The first would be premium connectors. The second is on-premises gateways. With just a standard Office 365 license, these items aren't available so using custom connectors or on-prem SQL servers would be out of the question.

Now, between a PowerApps 1 and 2, the only real non-CDS difference as far as I can tell is that you would get many more Flow runs per month (4,500 with PA1 compared to 15,000 with PA2). As to whether a PowerApps 2 plan is worth $33 more a month (or your equivalent currency) than a PowerApps 1 plan, I would have to say no considering adding an equivalent Flow 2 plan is only $15/month, so that's $18/month of unused CDS ability. 

[R3dKap]

Thank you @wyotim for your interesting reply...

One other thing though... What about having a production environment (in addition to the default one) so that I can use the default one for developpement and the production one as a real production environment ?

Do you think that using various environments used for DEVELOPMENT, VALIDATION and PRODUCTION phases of apps could justify a PowerApps Plan 2 licence (my customer doesn't mind paying for it) ?

If so, are there any simple way to publish an app from one environment to the other without going through the extraction process ?

[iAm_ManCat · Accepted solution]

Think I can answer this - you need to think of your default environment as production. You could buy one Plan 2 license to create a dev environment and one testing(validation) environment, then push to default once they are ready.

When a user logs into and opens up PowerApps, they will see their default environment and apps, if you create your apps in another environment the users will have to switch to that every time in order to open their apps (unless using PowerApps for mobile)

The export/import process is really not that much of a hassle if you aren't producing hundreds of apps and takes +- 5mins tops per commit-to-live.

What I've opted for is:

• On the initial commit we do export / import.
• For any subsequent updates, we:

1. Save a local copy of the validated app,
2. Click Edit on any app within your default environment,
3. Click File>Open>Browse Files,
4. Open the local file,
5. Check all connectors etc ok,
6. Save as and overwrite the production app (as you are opening that local file within default env)

We use SharePoint as a backend, so I'm in a similar situation - we only have 1x P2 license (my admin account) and the rest of the org has E3/F1 licenses. If you aren't going to use on-prem yet or premium connectors, then don't bother with P1's

https://flow.microsoft.com/en-us/pricing/ - if you have 500 users with E3 licenses (or other office licenses which include flow/powerapps), the flow runs are pooled, so you'll have 2000runs x 500 users = 1 million flow runs - unlikely you'll hit that monthly run rate of 2000 per user initially, and if by some miracle you do - you can buy an additional 50k runs for USD40

I'm going to go on record saying that it's too much hassle to do all of this dev/prod environment with PowerApps, (even though I do it because we require it) and the easiest way to handle dev/prod would be to name your apps DEV-Appname and VAL-Appname and Appname within the default environment and control access through App permissions. That way once you have done validation, you can just choose Save As and type Appname and that is then considered a push to live.

Sorry if I rambled on a bit there!

ManCat

[R3dKap]

Thank you @iAm_ManCat for your reply... Very interesting as well...

Indeed, I thought also of the solution to name my applications (and SharePoint forms) with different names but I'm scared it's going to become a mess very quickly.

So I'll stick to the use of multiples environments...

Thank you both for your suggestions, ideas and opinions.

Emmanuel

[wyotim]

If I may add a little to @iAm_ManCat's awesome comments, I use the "Save As" technique suggested at the bottom of his post and I really enjoy it. It is the most streamlined way I have found to move from development/test to production and has the benefit of keeping the production versions easy to sort through.

To help keep things organized (besides a naming convention) I chose an icon background color for all development versions, in my case yellow. Then I have set colors for different departments/levels of access (dark red for field supervisors, medium blue for general office apps, etc.). That way I always know which apps are development versions and who the target audience is of the release app based on the icon color. The app permissions should line up with the icon color and vice versa. Just thought I would share that tidbit in case it was helpful. 

[iAm_ManCat]

Thanks @wyotim - I hadn't thought of using the background colours as an indicator, that's a really good idea 🙂

[R3dKap]

Very interesting @wyotim... Thanks for sharing your technique with us...