← Back to Policy Tracker guide
Final Pass QA, Everything Found
Full read-through of a fresh export of all 6 screens plus OnStart and Formulas. Confirmed first: every fix from every earlier guide this project (all 10 pre-launch items, the Owner fix, the Thursday picker, the Duplicate modal) is correctly present, nothing has regressed. What follows is everything new found on top of that.
1. Three dead global variables CLEANUP, NO RISK
varSelectedDate, varSaveMode, and varFormSaved are all set once in OnStart and never read anywhere in any of the 6 screens — confirmed by searching every file, not just these three. Safe to delete, nothing references them.
App.OnStart, full replacement (only those three Set() calls and their now-orphaned // Selection variables / // Date type comments are removed, everything else identical):
Set(
varSelectedState,
"Current"
);
Set(varTypeFilter, "");
Set(varFilterOwner, false);
ClearCollect(
colBossButtonUsers,
{Email: "allan.hamilton775@mod.gov.uk"},
{Email: "dan.smith391@mod.gov.uk"}
);
Set(
varShowSearch,
false
);
Set(
varSelectPolicy,
"Empty"
);
Set(
varHistoricLimit,
30
);
Set(varSelectedItem, Blank());
Set(varSelectedLink, Blank());
Set(
varShowDuplicateModal1,
false
);
Set(varSaving, false);
Set(varUnsavedChanges, false);
Set(varParentSaved, false);
Set(varLoadingLinks, false);
Set(varDeletingItem, false);
Set(
varDuplicating,
false
);
// Boolean flags (global)
Set(
varShowLinkModal,
false
);
ClearCollect(
colChoiceColors,
ForAll(
Choices('Policy Proof Tracker'.'Document Type'),
{
ChoiceValue: Value,
ColorCode: Switch(
Value,
"📄 MoD Policy", RGBA(28, 32, 48, 1),
"📗 Manual", RGBA(0, 130, 60, 1),
"📄 CFI", RGBA(0, 100, 200, 1),
"📄 CFSO", RGBA(130, 0, 180, 1),
"📕 SOI", RGBA(190, 30, 30, 1),
"📖 Regulation", RGBA(0, 150, 150, 1),
"📄 CBN", RGBA(210, 100, 0, 1),
"📄 ACSO", RGBA(0, 60, 130, 1),
"📑 Internal Document", RGBA(90, 90, 110, 1),
"📜 Newsletter Item", RGBA(160, 120, 0, 1),
RGBA(150, 150, 150, 1)
),
ColorCodeFaded: Switch(
Value,
"📄 MoD Policy", RGBA(28, 32, 48, 0.1),
"📗 Manual", RGBA(0, 130, 60, 0.1),
"📄 CFI", RGBA(0, 100, 200, 0.1),
"📄 CFSO", RGBA(130, 0, 180, 0.1),
"📕 SOI", RGBA(190, 30, 30, 0.1),
"📖 Regulation", RGBA(0, 150, 150, 0.1),
"📄 CBN", RGBA(210, 100, 0, 0.1),
"📄 ACSO", RGBA(0, 60, 130, 0.1),
"📑 Internal Document", RGBA(90, 90, 110, 0.1),
"📜 Newsletter Item", RGBA(160, 120, 0, 0.1),
RGBA(150, 150, 150, 0.1)
),
SortOrder: Switch(
Value,
"📄 MoD Policy", 1,
"📄 ACSO", 2,
"📖 Regulation", 3,
"📄 CFSO", 4,
"📄 CFI", 5,
"📄 CBN", 6,
"📗 Manual", 7,
"📜 Newsletter Item", 8,
"📕 SOI", 9,
"📑 Internal Document", 10,
99
)
}
)
);
Set(
colTypeCounts,
Filter(
'Policy Proof Tracker',
'Planned Publish Date' >= Today() &&
'Planned Publish Date' <= DateAdd(Today(), 28, "Days") &&
(varFilterOwner = false || Owner.Email = User().Email)
)
);
// Theme
Set(
AppTheme,
{
palette: {
themePrimary: RGBA(11, 74, 54, 1),
themeSecondary: RGBA(9, 60, 44, 1),
themeTertiary: RGBA(7, 48, 36, 1),
neutralLight: RGBA(237, 237, 237, 1),
neutralDark: RGBA(50, 49, 48, 1),
white: RGBA(255, 255, 255, 1)
},
semanticColors: {
buttonBackground: RGBA(11, 74, 54, 1),
buttonBackgroundHovered: RGBA(9, 60, 44, 1),
buttonBackgroundPressed: RGBA(7, 48, 36, 1),
buttonText: RGBA(255, 255, 255, 1)
}
}
);2. Overview lightbox — checked live, not actually a bug FALSE POSITIVE, CONFIRMED RESOLVED
Checked directly in the live editor: this was a false alarm. conLightboxBody1's properties in Studio already exactly match what this guide proposed, FillPortions: =1 included — it just didn't show up in the exported YAML text. The lightbox itself works correctly and always has.
Worth understanding why, since it affects how much to trust a property being "missing" from an export generally: Studio's export apparently doesn't always write out every property verbatim, in this case a live, explicitly-set FillPortions: =1 was silently dropped from the text. The reasoning in the original write-up (matching galThursdayOptions1's proven pattern, the suspicious Height: =550 matching the parent's total height) was sound given what the export showed, but the export itself wasn't a complete picture here. No change needed — leaving this section in place rather than deleting it, as a record that it was checked and cleared, not just skipped.
3. Historic's type chips aren't in the canonical order MINOR CONSISTENCY
galTypeChips2's Items is just colChoiceColors directly, no Sort applied, so the chips render in whatever order ForAll(Choices(...)) happens to return — not the MoD Policy→ACSO→Regulation→...→Internal Document order Main and NewsletterPack both use via colChoiceColors.SortOrder.
galTypeChips2.Items, full replacement:
=Sort(colChoiceColors, SortOrder, SortOrder.Ascending)
4. Search delegation limit — awareness only NOT URGENT
Both Historic's search (lblHistoricCount2, galHistoricMonths2) and Main's search overlay filter with Lower(x) in Lower(Title), which SharePoint can't delegate. In practice this means the search only actually searches the first 500–2000 rows Power Apps has loaded locally (exact number depends on the app's delegation setting), not the whole table.
Not a problem at your current table size. Worth remembering specifically for Historic, since it's an archive that only ever grows — if it ever gets large enough to hit that limit, older items could silently stop showing up in search results with no error or warning. No fix proposed here since it's not causing a real problem yet; flagging so it's a known, not a surprise, if it ever comes up.
5. Historic vs Main link-loading — inconsistency, not a bug FYI
When you click an item on Main, the click handler calls BuildLinksForSource itself before navigating to ViewItem. When you click an item on Historic, it doesn't — it just clears colLinks and sets the loading flag, then lets ViewItem.OnVisible's own fallback do the actual fetch.
Both work correctly. Historic's version is arguably the better one — Main's redundantly fetches the same links twice (once from the click handler, once from ViewItem.OnVisible), Historic's fetches once. Not proposing a fix, just flagging the inconsistency in case you want the two screens to match exactly — if so, the cheap fix would be trimming Main's click handlers to match Historic's leaner version, not the other way round.
= with nothing after it. Most are LayoutMaxHeight/LayoutMaxWidth, which is normal and harmless. A handful of Text/OnSelect/Default ones were checked individually and are all genuinely blank on purpose (icon-only buttons, an empty search box). None of this is an active bug — the app runs fine with them today. It matters for the renaming project specifically, since Studio's YAML importer needs an explicit ="" rather than a bare = when pasting new screen YAML, confirmed in the Bible already. Something to normalise as part of that work, not something to fix today.