Overview
An app override lets one app be served with a few of its settings replaced, without copying the app. The override is a short list of "this setting, this value" entries stored against the app's id. When someone opens the app, those entries are laid over the app's saved configuration before the first page renders. The running app can show a different logo, name or theme colour, while every page, block and data source stays exactly as built.
Note: There is no screen in the builder for creating, editing or deploying an app override. The app reads an override that is already deployed and applies it. If you need one, ask whoever provisions your apps to set it up. Send them the app's Application ID (copy it from the app's Overview tab) and the list of settings to replace with their new values — for example the logo, the app name or the theme colour.
How an Override Finds Its App
An override is a separate record that names the app it applies to by that app's own id. It doesn't live inside the app record, and it isn't linked through the app's package. Two apps in the same package don't share an override, and an app with no package can still be overridden.
What an Override Changes
An override is a list, not a copy. Each entry names one setting in the app's configuration and the value to use for it — for example the favicon, the logo, the app name or the theme colour. Everything the list doesn't name stays as the app has it saved.
Later entries win. The list is applied top to bottom. If two entries name the same setting, the one further down takes effect.
New settings can be added. An entry can name a setting the app has never set; it is created rather than rejected.
Reshaped settings are skipped. If a newer release of the app changed a setting's shape, an entry that no longer fits is quietly skipped.
An override changes app-wide settings, not the contents of a page. To vary what is inside a page across placements, use a template component's inputs and its Component overrides list.
When an Override Takes Effect
There is no switch that turns overrides on for an app. The platform works out whether an app has an override, and it re-checks this on every deploy.
Once a deployed override exists for an app, the app is treated as overridden from that deploy onwards.
Remove the override and deploy again, and the app goes back to its own settings.
An override that exists but hasn't been deployed changes nothing.
A Broken Override Never Breaks the App
If the override can't be loaded, is malformed, or has an unusable entry, the app falls back to its own saved configuration and keeps running. Your users never see an error. The trade-off is that an ignored override looks exactly like no override at all, and there is nothing in the builder to inspect.
Checking That an Override Is Applied
Open the running app, not the builder, and check the settings the override names — for example the logo, the app name or the theme colour. If they show the override's values, it is applied. If the app shows its own saved values, the override isn't deployed yet or its entries were skipped. Ask whoever set it up to check it.
App Overrides vs. Package Settings
An app can belong to a package. A packaged app takes its security and public-or-private setting from the package, and its settings area shows Application Settings with a Package Settings button instead of the usual panels. That is about where settings are edited. An app override is about which settings are replaced when the app loads. The two are unrelated.
App Overrides vs. Component Overrides
Component overrides (eligible overrides) is a separate feature inside template components. The template's author marks specific inner blocks as overridable — from the Component overrides field in the template's page settings, or with Mark overridable in the layers tree — and whoever places the component can customise those blocks under Content → Child components. It has nothing to do with app overrides.
Related Pages
App Configuration — full reference for all Builder Settings sections.