Build a Consistent Power Apps UI Across Screens: Themes, Components and Responsive Layouts

A consistent canvas app does not come from copying the same header onto twelve screens and hoping nobody changes one of them.

It comes from a small design system:

1. a theme and a short set of design tokens;
2. reusable components for repeated interface patterns;
3. responsive containers and layout formulas;
4. explicit data and navigation contracts between screens;
5. accessibility and device tests that prove the result.

Power Apps gives you several ways to build that system. They solve different problems. Modern themes can help with control styling inside an app. Named formulas can hold declarative values. Components remove repeated structures. Component libraries can distribute components across apps. None of those features, by itself, creates an instantly synchronised or automatically accessible tenant-wide UI.

The practical architecture

Use the lightest layer that matches the scope of the change.

Need	Best starting point	Important boundary
Consistent colour and control styling in one app	Modern theme and design tokens	Classic and modern controls do not expose identical styling behaviour
A repeated header, navigation rail or status card in one app	Canvas component	Keep its inputs and outputs deliberate
A maintained component used by several apps	Component library	Apps must receive and accept published component updates
Layout that adapts to window/device size	Horizontal and vertical containers plus responsive formulas	“Scale to fit” is not true responsive layout
Shared values calculated declaratively	App.Formulas named formulas	They are not mutable state variables
Behaviour that belongs to one screen	Screen formulas and scoped context	Do not make screens reach into one another without a reason

The rest of this guide builds those layers in that order.

1. Start with a small design contract

Before opening Power Apps Studio, define the decisions makers are meant to reuse:

• primary and secondary colours;
• surface, text, success, warning and error colours;
• type sizes and weights;
• spacing increments;
• border radius and focus treatment;
• page header, navigation and command patterns;
• responsive breakpoints or layout states;
• accessibility rules such as contrast, keyboard order and meaningful labels.

Do not create fifty tokens because a large design system has fifty. Start with the decisions that are genuinely repeated. Every token becomes something the team must name, document and test.

2. Use modern themes where they fit

Modern themes apply a style system to supported modern controls in a canvas app. They are useful when you want a coherent Fluent-based starting point without manually setting every colour property.

Microsoft’s modern theming documentation also contains the boundary that many tutorials omit: some modern controls are generally available, while the broader feature set still includes preview capabilities. Preview behaviour can change and may not be appropriate for a critical production app without your own acceptance process.

Modern and classic controls are not one styling surface

A theme does not guarantee that every classic control, custom component and PCF control will update identically. Mixed-control apps need a transition plan:

1. inventory the controls used on each screen;
2. apply the theme in a development copy;
3. compare default, hover, pressed, selected, disabled and error states;
4. check controls that still use explicit colour formulas;
5. test high contrast, zoom, keyboard focus and the devices in scope;
6. publish only after the visual and functional differences are understood.

Do not claim that a generated palette is accessible because it looks balanced. Contrast and interaction states still need testing.

3. Put stable app values in named formulas

The Formulas property on the App object defines named formulas. Microsoft describes these as Excel-like declarations whose values are available throughout the app and can be recalculated when their dependencies change.

They are a good home for a small immutable token record:

ThemeTokens = {
    ColorPrimary: ColorValue("#005A9E"),
    ColorSurface: ColorValue("#FFFFFF"),
    ColorText: ColorValue("#242424"),
    ColorDanger: ColorValue("#A4262C"),
    SpaceSmall: 8,
    SpaceMedium: 16,
    SpaceLarge: 24
};

A supported control can then refer to ThemeTokens.ColorPrimary instead of repeating a hex value.

Microsoft’s App object reference and guidance for large canvas apps explain the named-formula model.

What named formulas are not

They do not replace state.

Use a variable or another appropriate state mechanism when a value must change because the user selected a record, opened a panel or changed a preference. A named formula is a declaration, not a mutable global variable with a new spelling.

Do not move every App.OnStart action into App.Formulas mechanically. Data loading, side effects and state transitions need their own design. Make the change because the value is declarative and the app benefits from that dependency model—not because a percentage-saving claim told you to.

4. Build repeated UI as a local component

A canvas component is the right next step for a repeated header, footer, navigation rail, empty state, field group or status banner inside one app.

Microsoft’s canvas component overview documents reusable components and their custom properties.

Treat a component like a small product with a contract.

Inputs

Inputs tell the component what to display or how to behave, for example:

• page title;
• current navigation item;
• user name or avatar;
• whether the back button is visible;
• a table of menu items;
• a design-token record.

Outputs and events

Outputs or event properties tell the host app what happened, for example:

• selected navigation key;
• retry requested;
• menu opened;
• record selected.

Avoid burying screen-specific data calls inside a generic visual component. A reusable header should not secretly know the name of OrdersScreen or query an environment-specific list unless that dependency is explicitly part of its contract.

Components and navigation

Microsoft documents an app-scope access setting for components, but that does not make broad scope the best default. A component that directly references app screens and global objects is harder to reuse and version.

Prefer a clear event or selected-key output where practical, and let the host screen decide what navigation or business action follows. If you enable app-scope access, document the dependency and test imported/library updates carefully.

5. Use a component library for cross-app reuse

Copying a component between apps creates separate copies. A component library is the supported route when several apps should consume a maintained component.

Microsoft’s component library guide explains the update lifecycle: a maker publishes a new library version, consuming apps can detect an available update, and the app maker reviews and accepts it.

That means a library is not magical tenant-wide instant propagation. The controlled update step is a feature: a component change can affect navigation, formulas and layout, so each consuming app needs regression testing before its new version is published.

A workable library process

1. Give the library an owner and a change log.
2. Use semantic, human-readable release notes even if the platform does not enforce semantic versioning.
3. Keep a sample/test app that exercises every state of each component.
4. Publish one bounded change at a time.
5. Notify consuming app owners.
6. Import or accept the update in a development environment.
7. Test screens, responsive states, accessibility and data contracts.
8. Promote the consuming app through its normal application-lifecycle process.
9. Retain a rollback route to the previously working app version.

If you cannot identify the consuming apps or their owners, you do not yet have a component library—you have an unmanaged dependency.

6. Build responsive screens with containers

Making a phone layout larger is not the same as making an app responsive.

Microsoft recommends horizontal and vertical containers, dynamic formulas and deliberate display settings. Its responsive design guidance says to turn off Scale to fit for true responsive behaviour and to manage aspect-ratio and orientation settings intentionally.

Start with a root container that fills the screen, then let nested containers manage flow and alignment. For example:

Width = Parent.Width
Height = Parent.Height

For a control that changes width at different screen sizes, Microsoft shows formulas using Parent.Size and the ScreenSize enumeration. One simplified pattern is:

Parent.Width *
Switch(
    Parent.Size,
    ScreenSize.Small, 0.5,
    ScreenSize.Medium, 0.3,
    0.25
)

Use the numbers as design decisions, not universal defaults. A data-entry form, dashboard and inspection app need different small-screen behaviour.

Prefer layout states over dozens of tiny exceptions

Define a few useful states such as:

• compact: one column, secondary navigation collapsed;
• medium: one or two columns depending on task;
• wide: navigation and content visible together.

Then test the transitions. A formula that technically fits every control can still produce an unusable reading order or a button too small to operate.

Microsoft’s full responsive canvas app walkthrough is a better base than copying fixed X and Y values across screens.

7. Reduce cross-screen references

A cross-screen reference is a formula on one screen that reaches into a control on another screen, such as reading TextInput1.Text from a different screen.

Microsoft lists cross-screen references among the issues that can force screens and their controls to load earlier than expected. It recommends avoiding the pattern where it harms performance and maintainability. See Microsoft’s Power Apps performance guidance.

This is not a rule that every cross-screen reference instantly breaks an app. It is a prompt to make the data flow explicit.

Better options include:

• pass a record or value with Navigate context;
• store genuine app state in an appropriate variable;
• bind several screens to the same data record rather than to another screen’s control;
• use component input/output properties;
• calculate reusable declarative values in named formulas.

For example, pass the selected record rather than making the destination screen inspect a gallery control on the source screen:

Navigate(
    DetailsScreen,
    ScreenTransition.None,
    { SelectedOrder: ThisItem }
)

The destination screen can use SelectedOrder without loading or depending on the source gallery’s control tree.

8. Treat accessibility as a testable requirement

Good control names help makers maintain an app. They do not, by themselves, provide accessible names to users.

Review the properties and behaviour that users and assistive technology actually encounter:

• accessible labels and instructions;
• logical tab order and keyboard operation;
• visible focus;
• sufficient text and non-text contrast;
• error identification that does not rely only on colour;
• touch target size and spacing;
• zoom and reflow;
• screen-reader reading order;
• meaningful headings, button labels and status announcements.

Test with the platform accessibility checker, keyboard-only operation and the assistive technologies your users rely on. A component should be tested in every important state: default, hover, focus, pressed, disabled, error, loading and empty.

9. Know when not to use PCF

Power Apps Component Framework controls can solve requirements that canvas components cannot: specialised rendering, advanced interaction or integration with a JavaScript control ecosystem.

They also introduce code, packaging, solution deployment, security review, browser support and lifecycle management. A PCF control is not inherently faster or more accessible because it is custom code.

Use PCF when a documented requirement survives a simpler-control evaluation and the team can own the component through testing, deployment and platform changes. Do not use it merely to centralise a colour or repeat a header.

A repeatable implementation sequence

For an existing multi-screen app:

1. Inventory repetition. Find copied headers, navigation, colours, spacing and formulas.
2. Choose a baseline screen. Fix one representative screen rather than editing every screen at once.
3. Define a small token set. Use theme capabilities and named formulas where appropriate.
4. Extract one repeated structure. Turn the header or navigation into a local component.
5. Make the baseline responsive. Introduce root and nested containers; test compact, medium and wide states.
6. Remove harmful cross-screen references. Pass records/state explicitly.
7. Run accessibility tests. Include keyboard, focus, labels, contrast and reflow.
8. Apply the pattern to the next screen. Improve the component contract when a real second case exposes a gap.
9. Move to a library only when cross-app reuse is real. Add owners, release notes and update testing.
10. Measure the result. Track defects, change lead time, app-start behaviour and accessibility findings using your own apps—not invented benchmark percentages.

Frequently asked questions

Should I use a theme or a component for consistent styling?

Use a theme for supported control styling and a component for a repeated interface structure or behaviour. Many apps need both.

Do component-library changes update every app instantly?

No. The library version is published, then consuming apps review and accept available component updates before their own tested app versions are published.

Should named formulas replace every global variable?

No. Named formulas are declarative values. Use variables or another state mechanism for values that genuinely change during user interaction.

Are cross-screen references always bad?

No, but Microsoft warns that they can force extra screens to load and make an app harder to maintain. Prefer explicit data flow where practical.

Does a modern theme make a canvas app accessible?

No theme removes the need to test contrast, labels, focus, keyboard operation, reading order, zoom and real user journeys.

Build the system, not another copied screen

The Power Apps Builders Space brings current platform changes, practical build patterns and troubleshooting into one maintained place.

Consistency is not “every screen has the same blue”. It is a controlled relationship between tokens, components, layout, state and tests. Build that relationship once, then let each screen express the task it exists to support.