Introduction
The General tab in the Power Apps Settings pane controls how your app saves, retrieves data, starts up, and moves between environments. This guide explains its six settings, covering what each does, its default, and when to change it, so you can avoid slow apps, missing records, and debug flags left on in production.
The General tab of the Settings pane in Power Apps Studio controls how your app is saved, how it handles data, and how it starts up. This guide covers all six settings, in the order they appear.
Correction: In my previous article I said the environment variable and App.OnStart settings sit under the Updates area. Your screenshots show they are on the General tab, so use this guide as the corrected version.
1. Auto save
What it does: Saves your changes every 2 minutes while you work in Studio.
Default: Off
Key detail: This is a browser-level setting. It applies to you in that browser, not to the app itself or to other makers. Saving is not the same as publishing, so end users won’t see anything until you publish.
When to turn it on:
- You work on large apps and don’t want to lose progress if the browser or connection drops
- You often forget to save manually
Things to consider: Auto save protects your work, but it doesn’t replace version history. Still publish deliberately when a version is ready.
2. Can be used offline
What it does: Lets the app run natively without a network connection. It works with Dataverse only.
Default: Off
When to turn it on:
- Field teams, inspectors, or sales staff who work with poor connectivity
- Apps whose data lives entirely in Dataverse
Things to consider: Offline mode needs extra setup, such as choosing which tables are available offline and how data syncs on reconnect. Leave it off if you use SharePoint, SQL Server, or other connectors.
3. Data row limit
What it does: Sets how many rows Power Apps retrieves from a server-based data source when delegation is not supported for a formula.
Default: 500 (maximum 2000). The screenshots show 2000.
Why it matters: With delegation, the data source does the filtering and sorting. When a formula can’t be delegated, Power Apps downloads only up to this limit and processes that subset locally. If a list has 5,000 records and the limit is 2000, a non-delegable filter sees only 2000 of them, so results can be silently incomplete. A blue delegation warning in the formula bar flags this.
Best practices:
- Prefer delegable functions and operators so the limit doesn’t matter
- Raise the limit only for non-delegable formulas on moderately sized data
- Remember that a higher limit means more data transferred and slower loading
4. Debug published app
What it does: Publishes debug information with the app so expressions and extra details appear in the Monitor tool when you troubleshoot the published version.
Default: Off
How to use it:
- Turn the setting On.
- Save and publish the app. The change only takes effect after publishing.
- Connect the Monitor tool to the published app.
- When finished, turn it Off and publish again.
Warning: This can hurt performance. Use it only while the app is under development or being investigated, and turn it off before production.
5. Automatically create environment variables when adding data sources
What it does: Creates an environment variable automatically whenever you connect to a data source. Environment variables let you change data sources within a solution without editing the app.
Default: Off
When to turn it on:
- The app is in a solution and will move across environments (Dev, Test, Production)
- You use ALM practices such as pipelines and managed solutions
Things to consider: Variables are created when you add a data source, so enable this before connecting your data. For a quick standalone app it adds little.
6. Enable App.OnStart property
What it does: Controls whether the App.OnStart property is available and runs when the app loads. It has traditionally held startup logic such as setting variables and loading collections.
Default: On in the screenshots
Why use caution: Everything in App.OnStart runs before the first screen appears, so heavy logic delays loading.
Better alternatives:
- App.StartScreen to choose the first screen with a formula
- Named formulas (App.Formulas) for values calculated when needed
- Screen.OnVisible to load data only when a screen opens
Best practices:
- Move logic out of
App.OnStartwhere possible. - Wrap independent operations in
Concurrent()so they run in parallel. - Use
App.StartScreeninstead ofNavigate()inOnStart. - Before disabling the property, check that nothing depends on variables set there.
Quick reference
| Setting | Default | Recommendation |
|---|---|---|
| Auto save | Off | On for large or long editing sessions |
| Can be used offline | Off | On only for Dataverse apps that need it |
| Data row limit | 500 | Keep as low as works; design for delegation |
| Debug published app | Off | Off in production |
| Auto-create environment variables | Off | On for solution-based, multi-environment apps |
| Enable App.OnStart | On | Use sparingly; prefer App.StartScreen |
Pre-publish checklist
- Debug published app is Off
- Data row limit is set deliberately and delegation warnings are resolved
- Offline mode is enabled only if required
- Environment variables are configured if the app moves between environments
App.OnStartis lean, or replaced withApp.StartScreenand named formulas

Conclusion
Review these settings before every release. Keep Debug published app off in production, design for delegation instead of just raising the Data row limit, and use App.StartScreen rather than heavy App.OnStart logic. Enable offline mode and environment variables only when your app needs them. Chosen deliberately, these settings make your apps faster and more reliable.







Join the conversation! Your thoughts help the community grow.