CLM Dashboard Governed Refresh Design

Tag: S-2026-07-26-clm-governed-refresh Type: own-writing Author(s): Paul Miles Date of source: 2026-07-26 Date ingested: 2026-07-27 Authority weight: high — first-party design note authored by Paul, the decision-maker; it is the spec the production-UI swarm implements. Raw file: _ClaudeWorkspace/09 Taxonomy Tool/CLM Dashboard Governed Refresh Design.md

What it claims

The note proposes a governed refresh mechanism for the interim CLM Taxonomy Dashboard v2 so client staff can republish the Teams tab from the governed workbook with no Python and no local tooling, while keeping the hard validation gate and an audit trail. It is explicitly scoped to the interim v2 dashboard, not the production Taxonomy Knowledge Tool.

First decision — externalise the data. The current pipeline injects data into a __DATA__ placeholder and rebuilds the whole HTML. The note proposes instead that the dashboard fetches a sibling glossary_data.json from the same SharePoint library at load time, so the flow writes a small JSON file rather than string-replacing a ~250KB HTML body. A comparison table weighs bake-into-HTML (high flow complexity, Teams tab may need re-pinning) against fetch-JSON-at-load (low complexity, tab never changes, but CORS/auth behaviour is tenant-dependent). The note says to test the SharePoint sibling-fetch behaviour before committing, with a fallback of flow-rebuilding the HTML from dashboard_template.html.

Flow shape. Manual trigger, not on-modify (“an automatic refresh on every workbook save is not a governed one”). A mermaid flowchart shows: governed workbook → steward triggers flow → run script from SharePoint library (parse + validate) → branch on validation → fail stops and notifies (live dashboard unchanged) → pass goes to approval (requester ≠ approver) → approved writes glossary_data.json via SharePoint connector → audit row appended → Teams tab reads new JSON on next load.

Four controls, all standard connectors. (1) Port validate_glossary.py into the Office Script so the flow branches on pass/fail and nothing publishes on failure. (2) Approval before publish with the flow enforcing requester ≠ approver (four-eyes). (3) Audit row to a SharePoint list per attempt (who triggered, source file version, term and reg counts, validation outcome, approver, timestamp); list versioning on, delete permissions off. (4) Provenance in the banner — render “data as at X, source version Y, approved by Z” from the JSON so the published tab self-evidences.

Apps, licences and toggles. Excel (Automate tab), OneDrive for Business / SharePoint, Power Automate (seeded in commercial M365), SharePoint (workbook, output JSON, audit list). The Run script action is on the Excel Online (Business) standard connector, so seeded M365 rights cover it. Cost trap: adding SQL, Dataverse, a custom connector or raw HTTP flips the flow to premium. Three admin toggles to confirm: Office Scripts availability/sharing/run-from-Power-Automate; org-wide sharing links enabled; whether the Excel Online connector is blocked or Office Scripts restricted. Platform constraints: 5MB connector cap, no ISO-strict xlsx, external calls from scripts via Power Automate are blocked, no concurrent writes.

Traps that become audit findings. Store the script via “Run script from SharePoint library”, not personal OneDrive (dies with the leaver). Flow ownership: service account with co-owners, not one steward’s personal flow.

Open question — the demo overlay. The v2 workflow statuses and owners are a deterministic demo overlay computed from Term ID. The note asks whether to turn it off for the published tab and keep it glossary-only, or make the banner caveat unmissable, because wrapping a governed, approved, audited refresh around partly illustrative content is a mixed message.

Next actions (open checklist): test SharePoint fetch-sibling-file behaviour; confirm the three admin toggles; port validate_glossary.py to TypeScript; build the flow; create the SharePoint audit list; add provenance rendering to the banner; decide the demo-overlay question. Estimated effort ~2–3 days for the script port and flow, plus whatever the admin toggles take.

Notable quotes

“Manual trigger, not on-modify. An automatic refresh on every workbook save is not a governed one.” (§2)

“Store the script via Run script from SharePoint library, not personal OneDrive. Otherwise the refresh mechanism lives in an individual’s drive and dies with the leaver.” (§5)

“Wrapping a governed, approved, audited refresh around partly illustrative content is a mixed message to a credit risk audience: the governance wrapper implies the content is real.” (§6)

What’s speculative vs. asserted

Asserted as decision/proposal (Paul’s own design): the externalised-JSON approach; the manual-trigger flow shape; the four governed controls; the standard-connector-only constraint; the script-in-library and service-account-ownership traps; the demo-overlay open question. These are the author’s design choices, not empirical claims — they are asserted as the intended architecture.

Asserted from platform documentation (claimed, not independently verified here): the 5MB connector cap; Run script not supporting ISO-strict xlsx; external calls from Power Automate scripts being blocked; the standard-vs-premium connector boundary; E1/F3 running but not authoring scripts; controls migrating to Microsoft 365 Cloud Policy. These are presented as platform facts the note relies on; the note itself says to verify the toggles in-tenant.

Speculative / explicitly unconfirmed: whether the SharePoint-hosted page can fetch a sibling file cleanly in the client tenant (“headers and auth vary by site configuration”) — flagged as “test before committing”. Whether the three admin toggles are set favourably — flagged as “confirm with the tenant admin”. The “~2–3 days” effort estimate is a rough projection, not a measured outcome. The demo-overlay question is left open — neither option is picked.

Topics this feeds

• CLM Taxonomy Dashboard — Production UI — the productionisation effort this note specifies.
• CLM Data Taxonomy Governance — the parent engagement whose dashboard refresh this governs.
• Taxonomy Knowledge Tool — the production portal that will supersede this interim refresh path (the note explicitly scopes itself as the stopgap, not that).

Open questions raised

• Whether the SharePoint-hosted page can fetch a sibling glossary_data.json cleanly in the client tenant (CORS / auth behaviour), or whether the template-rebuild fallback is needed.
• The state of the three admin toggles (Office Scripts availability/sharing/run-from-Power-Automate; org-wide sharing links; Excel Online connector DLP) in the client tenant.
• The demo-overlay question: turn it off for the published tab (glossary-only), or make the banner caveat unmissable? (Resolved in the production-UI swarm: the v3 dashboard removes the demo overlay entirely and renders workflow data from the source JSON only.)
• When the production Taxonomy Knowledge Tool retires this interim path.