What can an analyzer check?

• Controls & screens
• Power Fx formulas
• Variables (Set, UpdateContext)
• Collections (Collect, ClearCollect)
• Navigation (Navigate, Back)
• Cross-references & dead code
• Components
• App-level (OnStart, Formulas, StartScreen)
• What the analyzer can’t see
• Writing a good prompt

Controls & screens

The analyzer gets a flat list of every screen, component definition, component instance, and control in the app — same hierarchy you see in the Studio tree view. For each one you know:

• The control’s name (as it appears in formulas, e.g. btnSubmit).
• Its type — Button, Gallery, Label, ComboBox, Screen, CanvasComponent, etc. Classic and modern (Fluent) variants are both recognized.
• Which screen it lives on and the YAML file that defines it.
• Its parent and children — you can walk the tree.
• Whether it’s a locked template (e.g. a gallery row template), a component definition, or a component instance.

Ask things like:

• “Find screens with more than 50 controls.”
• “Flag controls whose name doesn’t follow a three-letter-prefix + camelCase convention.”
• “Find Button controls that have no AccessibleLabel set.”
• “List every classic control (not Fluent) on each screen.”

Power Fx formulas

Every property that starts with = in the YAML is captured as a formula — that includes OnSelect, Items, Visible, Text, Default, OnStart, BorderColor, and everything else. The analyzer sees:

• The full formula source, per control and property, grouped by screen and file.
• Short snippets around key function calls, ready to show in the report.
• Every identifier that appears in any formula — so it can answer “is this name ever mentioned?” without reparsing.

Ask things like:

• “Find any formula that calls LookUp or Filter on a non-delegable column (e.g. StartsWith, Mid).”
• “Flag If expressions nested more than three levels deep.”
• “Find OnSelect properties that are empty, whitespace, false, or just Select(Parent).”
• “Detect hardcoded color literals (Color.RGBA / ColorValue) instead of a theme variable.”
• “Find Patch calls that are missing an error handler (IfError).”

Variables — Set() and UpdateContext()

Every Set() (global) and UpdateContext() (context / screen-scoped) call is already parsed and grouped by variable name. For every variable you get the list of places it’s written, and a separate flag for whether it’s ever read in any formula.

Ask things like:

• “Find variables that are Set but never read (dead state).”
• “Find context variables that are updated on more than one screen — they should probably be global.”
• “Detect boolean-looking variables (starts with is, has, can) that are assigned non-boolean values.”
• “Flag Set calls inside a loop-y ForAll.”

Collections — Collect() and ClearCollect()

Same story as variables: every collection mutation is grouped by collection name, and the analyzer knows whether that collection is consumed anywhere (as a gallery Items, in a LookUp, ForAll, CountRows, and so on).

Ask things like:

• “Find collections that are Collected or ClearCollected but never read — the app is filling them for nothing.”
• “Find collections used on only one screen — they could be a local With record instead.”
• “Flag Collect calls inside a gallery template.”

Navigation — Navigate() / Back()

All Navigate() calls are parsed and grouped by destination screen. You also know the App’s StartScreen formula. That’s enough to answer “which screens are reachable?”.

Ask things like:

• “Find screens that are never the target of a Navigate() call and aren’t referenced by StartScreen — they’re orphaned.”
• “Flag Navigate calls that always use the same transition — we standardized on ScreenTransition.Fade.”
• “Find screens with no Back() or home-navigation handler anywhere on them.”

Cross-references & dead code

The analyzer builds a reverse index of which controls are referenced where, including:

• Dot access — TextInput1.Text, Gallery1.Selected (the strongest signal a control is actually used).
• Function targets — Select(btnSubmit), Reset(txtEmail).
• Bare identifiers — a control name mentioned in a formula without a property.

Ask things like:

• “Find controls that are never referenced — likely dead UI.”
• “Find Select(X) / Reset(X) calls where X no longer exists as a control (stale reference).”
• “Find named formulas in App.Formulas that nothing calls.”
• “Detect labels that are only ever set to a literal — they could be replaced with the literal at the use site.”

Components (definitions & instances)

Canvas components are seen in two forms: the definition (with its custom input/output properties) and every instance placed on a screen. The analyzer knows which definition each instance belongs to, so it can cross-check the two.

Ask things like:

• “Find component definitions that have no instances anywhere — unused library components.”
• “Flag components whose input properties are never overridden by any instance (the defaults are doing all the work).”
• “Find instances that override the same input with the same hardcoded value everywhere — that could become the new default.”

App-level hooks — OnStart, Formulas, StartScreen

The App node exposes its own formulas just like any other control: OnStart, OnError, Formulas (named formulas), StartScreen, etc. Named formulas are indexed by name so you can tell which ones are actually referenced.

Ask things like:

• “Flag OnStart longer than 30 statements — it’s a startup bottleneck.”
• “Find Set() calls in OnStart whose value is static (no table reads, no User(), no Now()) — they could be named formulas.”
• “Find named formulas in App.Formulas that no formula ever references.”
• “Flag a complex If in StartScreen — routing logic belongs in a named formula.”

What the analyzer can’t see

The analyzer works against the unpacked Canvas app source — so anything that lives outside that is off-limits. Be sure your prompt doesn’t ask for:

• Runtime state or data values — actual record contents, API responses, variable values. The analyzer reads source code, not a running app.
• Dataverse / SharePoint / connector schemas — only formula text and declared data source names are available.
• Power Automate / cloud flows — any flow behavior outside the app itself.
• Resolved theme values — if the app uses a theme record, the analyzer sees the theme’s formula source but doesn’t evaluate it to a final color.
• User interaction timing — there’s no way to know “was this OnSelect slow?”. Static patterns only.

Writing a good prompt

• Be specific about the signal. “Find bad formulas” is too vague. “Find Filter calls on a SharePoint list that use StartsWith or Search without delegation” gives the AI enough to generate useful code.
• Say which object you mean. Name the control type, the property, the function, or the variable pattern. If you just say “look at OnStart”, you’ll get something, but naming the exact pattern is better.
• Describe what counts as a hit. Include examples of the “bad” case and, ideally, a “good” counter-example the AI can exclude.
• State the confidence. “High confidence if the variable is never read anywhere; medium if it’s only read inside the same screen it’s set on” produces better badges and better reports.
• Ask for columns. “Show the control name, the screen, and the first 80 characters of the offending formula” — the generator will put those in the resultSchema and the report table.