[Keith McGrane (Keithland89)]

For 0.6.8. Keith decides the merge.

Summary

This does what Keith decided for the 0.6.8 plan's decision 13: option (a) only, plus the wording.

The bug. The "Chat + Agent Org Data" query renamed the first column whose name normalises to department to Organization, without checking whether Organization already exists. The org table always has Organization, and the Workday org data adds any column the table lacks. So a Workday export with a Department column made the rename collide with Organization, and the refresh failed. On Fabric it cleared once the column left the export. On Azure it didn't, because publish never drops a column. This was found by reading the code; the refresh hasn't been run (see Validation).

The fix (a). The query renames Department to Organization only when there's no Organization column:

-    // Rename Department to Organization (if exists)
+    // Rename Department to Organization only when there's no Organization column: renaming
+    // onto an existing one fails the refresh. The table can have both when a Workday export
+    // adds a Department column, and Organization is then left as it is.
     RenamedColumns =
-        if colDepartment <> null then
+        if colDepartment <> null and not Table.HasColumns(RenamedPersonId, "Organization") then

• A table with both columns refreshes, and Organization is left untouched. The model doesn't declare a Department column, so it isn't loaded.
• A table with Department and no Organization still gets it renamed, as today.
• A blank Organization isn't filled from Department. That's option (a+), which Keith rejected.
• Patched templates: fabric/ValueLens - Fabric.pbit, fabric/ValueLens - Fabric OneLake.pbit and fabric/Add Agent Evaluator/Agent Evaluator.pbit. The change is in DataModelSchema, plus the Agent Evaluator's UnappliedChanges copy. fabric/Add Credit Consumption/Consumption Central - Fabric.pbit has no such rename.
• The installer builds the Fabric and Azure models from ValueLens - Fabric.pbit, so Azure gets the fix through the same template. A new installer test checks the query in the built Fabric, Azure and Agent Evaluator models.
• tests/test_consolidated_release.py pins the DataModelSchema hashes of the two core templates, so the two pins are updated, as Power BI model: faster active-user counts, synced from ValueLens #132 did. Main's templates still give the old pins, so the new ones reflect only this change.
• Workday standalone mode: when the export has no Organization, the Workday load adds one, from Job_Family_Group or null. That's the notebook on Fabric and its port, valuelens_core.workday, on Azure. So a standalone export with Department failed too. It now refreshes, and Organization keeps the Workday load's value rather than taking Department.

The wording. Workday only adds columns, and nothing suggests it any more to people without a department.

• Installer: the Workday data source (installer/src/uploads.js) and the Workday pipeline activity (installer/src/transform/pipeline.js) said it "adds or overrides" org fields. They now say it adds the columns the org data doesn't have, and doesn't change or fill in existing ones. The department check after the first load (installer/src/steps/run.js) no longer suggests Workday.
• Org data load: the low-coverage message in core/valuelens_core/org.py and its copy in fabric/notebooks/Copilot_Org_Data_Direct_Ingester.ipynb no longer suggest Workday. The two stay identical.
• App: DEPARTMENT_ADVICE and the by-organization empty state (app/src/lib/department-coverage.ts) no longer suggest Workday.
• Docs: docs/DATA-DICTIONARY.md says the rename happens only without an Organization column, and that Workday doesn't fill in a missing department.
• CHANGELOG.md: two entries under ## Unreleased.
• Tests that asserted the old text now assert that the advice doesn't mention Workday: tests/test_valuelens_core_collectors.py, installer/test/steps.test.js and app/src/lib/department-coverage.spec.ts.

Scope

Parts affected (installer / app / Fabric notebooks and pipeline / Azure infra, jobs or web / core / Power BI models): Power BI models (3 templates); installer (wording, plus a test); app (wording); Fabric notebooks and pipeline (one message, one activity description); core (one message); docs.

Source contracts, optional inputs, install record or deployed item names changed: none. The Workday export format, the copilot_org_data columns and every deployed item name are unchanged. Only the description text of the Workday pipeline activity changes.

Validation

• Ran python -B -m pytest tests -q and recorded results below.
• Ran npm test (and npm run typecheck for the installer) in each changed Node project.
• Updated directly related documentation and checked changed links.
• No credentials, tenant exports, prompts or customer names are included.
• If .pbit files changed, documented the rebuild method and Desktop refresh / visual checks.

Results, skipped checks and limitations:

• python -B -m pytest tests -q -p no:cacheprovider at the repo root: 1,068 passed, 1 failed, 5 skipped, 12,168 subtests passed. That took 27 minutes on this shared machine.
  • The run started on the commit before the pin update, and its one failure was that pin check (tests/test_consolidated_release.py), which caught the template change as intended.
  • On a2b45ce, python -B -m pytest tests/test_consolidated_release.py -q -p no:cacheprovider passes (3 passed). So a2b45ce is 1,069 passed, the same as its CI run.
  • The 19 test files that read a template, org data or Workday data also pass on a2b45ce: 317 passed, 12,048 subtests passed.
• npm test in installer/, on the branch rebased onto b902e58: 941 of 944 passed. None of the 3 failures involves this PR's changes:
  • test/script.test.js:115, the known local failure: this machine's execution policy blocks generate.ps1. I didn't bypass it. CI skips this test, because it needs Windows PowerShell and cmd.exe.
  • The two exitWhenDone tests in test/helpers.test.js (lines 154 and 174) timed out because the CPU was at 100%. They give a child Node process 15 or 20 seconds to exit; run directly, it exits with the expected code in 3 to 5 seconds. They test src/auth.js, which this PR doesn't touch, and they passed here before the rebase onto b902e58 (908 of 909). In CI on fd6187d they pass in 1.8 and 3.3 seconds.
• npm run typecheck in installer/: passed.
• app/: npm ci fails on this machine because its npm feed returns E404 for caniuse-lite-1.0.30001816.tgz, and I didn't switch registries.
  • Instead, I ran the real src/lib/department-coverage.spec.ts under Node 24's type stripping with a minimal vitest shim: 7 passed. As a check, the new spec against main's department-coverage.ts fails exactly the 2 changed assertions.
  • The regex in src/screens/executive/attention-stage.spec.tsx:124 still matches the new text.
  • The full app suite, lint, tsc -b and build:fabric weren't run locally. CI's app job runs them all.
• The local runs above were all made before the rebase onto 0fdad40.
  • The rebase changed none of this PR's files except CHANGELOG.md. It also changed nothing that tests/test_consolidated_release.py, tests/test_org_department_rename.py or the app spec reads.
  • It did change what the full pytest and installer suites read: main's own changes since b902e58, such as App: count agents in use and people with an organization at once, so the Executive summary loads sooner #139's measure tests and Azure: tell the app which modules are off, so it skips their checks #143's ARM template and Azure infra. CI on fd6187d ran both suites, below.
• CI on fd6187d: all green.
  • pytest: 1,069 passed, 5 skipped, 12,172 subtests passed.
  • installer: 941 of 945 passed, 4 skipped (Windows-only), 0 failed, plus npm run typecheck.
  • app: 3,464 tests in 145 files passed, including department-coverage.spec.ts (7) and attention-stage.spec.tsx (5).
  • app lint: 0 errors. Its 2 warnings were already there, in files this PR doesn't touch.
  • app tsc -b and build:fabric: passed.
  • Also green: arm-drift, valuelens-web, both image builds and the three CodeQL analyses.
• New tests:
  • tests/test_org_department_rename.py (5 tests, passing). They check that the templates are current, that every copy of the query has the guard, and that the script covers every template with the rename. They also run the rename steps of each template's M through the repo's M evaluator (tests/m_eval.py), with stub Table functions that fail on a rename onto an existing column, as Power Query does:
    • Department only: renamed to Organization;
    • both: both columns and their values left as they are, including a blank Organization;
    • the old query text with both columns: fails with "'Organization' already exists".
  • installer/test/model.test.js: the Fabric, Azure and Agent Evaluator models the installer builds all have the guard (passing).
• Rebuild method: python scripts/Update-Org-Department-Rename.py patches the templates in place, and --check exits 1 if any is stale. It's idempotent. It edits only the org query, in DataModelSchema and (when the template has one) UnappliedChanges, and it refuses to write if any other model field or ZIP member would change. The Agent Evaluator's lastLoadedAsTableFormulaText already differed from its query, so it's left as it is: the script updates it only when it matched, as scripts/Update-Model-Refresh-Fixes.py does.
• The refresh itself wasn't run. It needs Power Query or a live model, so it can't be run offline, and I made no cloud or tenant changes. Here is the live check. It needs Keith's approval, and I haven't run it:
  1. In Power BI Desktop, open the patched ValueLens - Fabric.pbit against a lakehouse whose copilot_org_data has both Organization and Department, for example after a pipeline run with a Workday export that has a Department column. Refresh. It succeeds, and Organization matches copilot_org_data.Organization.
  2. Point it at a copilot_org_data with Department and no Organization, and refresh. It succeeds, and the Department values show as Organization.
  3. On Azure, run Repair or change on an install whose org table already has a Department column. The model refresh succeeds.

Compatibility

• Repair or change redeploys the semantic model from the patched template on both Fabric and Azure. The definition's hash is part of the deployed model's signature (installer/src/steps/model.js), so existing installs pick up the fix with no migration. An Azure org table that already has a Department column refreshes again, without dropping the column.

• Org data without a Department column, or with Department and no Organization, behaves exactly as before.

• Existing Fabric pipelines keep the Workday activity's old description until their next pipeline update. That's the installer's Update, which always offers to replace the pipeline, or a Repair or change that changes what the pipeline runs, such as turning Workday on or off. New installs get the new text.

  • pipelineSignature (installer/src/steps/fabric.js) is built from the modules, flags and model IDs, not from activity text, and PIPELINE_VERSION (7) isn't bumped.
  • That's deliberate. A bump would ask every install to replace its pipeline, including any activities added to it by hand, for a text-only change. The activity runs the same notebook either way.

• Left unchanged on purpose:

  • filling a blank Organization from Department (option a+);
  • the Workday notebook and Azure's Workday load (option b);
  • Consumption Central - Fabric.pbit, which has no rename;
  • the archived templates;
  • the CHANGELOG's history.

• The ValueLens templates need a matching change. That's a follow-up, not part of this PR. On ValueLens main, the same unguarded rename is in:

  • 1. Fabric/Manual setup/ValueLens - Fabric.pbit, ValueLens - Fabric OneLake.pbit and Add Agent Evaluator/Agent Evaluator.pbit;
  • ValueLens - Power Automate + Dataverse.pbit;
  • ValueLens - SharePoint.pbit;
  • ValueLens - Local CSV.pbit.

  Its Consumption Central templates have none. Those variants have no Workday load, but org data with both columns would fail the same way. The patch script here has this repo's paths only.

Overlaps with open PRs

This branch is rebased onto main 0fdad40, which also has #142, #138, #139 and #143, merged since a2b45ce. Only CHANGELOG.md changed, by main's new entries; the code is byte-identical to a2b45ce. The survey of open PRs below was made at a2b45ce, while those four were still open. Main already had #141 (Azure: Workday org data by CSV) and #126, both merged after this was planned.

• Azure: Workday org data by CSV #141's Azure Workday load has no Department special case, so this model fix covers it as it is.
• Azure: Workday org data by CSV #141's note in azure/README.md, that the export "doesn't fill in a missing department", agrees with this fix.

I checked every open PR with gh pr diff <n> --name-only. None touches a .pbit file, and the only file any of them shares with this PR is CHANGELOG.md.

• CHANGELOG.md only: Azure: tell the app which modules are off, so it skips their checks #143, App: preload the start-up code, so it downloads while the config loads #142, Azure: Agent Evaluator model on Azure SQL, with org-scoped access (W2, 2 of 3) #140, App: count agents in use and people with an organization at once, so the Executive summary loads sooner #139, App: the Executive summary's headline figures don't wait for saved task times #138, Azure: Agent Evaluator jobs collector, parser and V008 (W2, 1 of 3) #133, Installer: recommend Azure and start new installs on it #128, Add an Azure by-hand setup path #115 and Managed app: one command sets it up by hand #114 (draft). Each appends to ## Unreleased.
• Dry merges of this head with each open PR's head (git merge-tree --write-tree), CHANGELOG.md included:
  • Clean: Azure: tell the app which modules are off, so it skips their checks #143 (3d7e3bc), App: preload the start-up code, so it downloads while the config loads #142 (84c0e27), Bump the github-actions group with 3 updates #135, Bump the npm group across 2 directories with 7 updates #134 and Bump python from 3.12-slim-bookworm to 3.14-slim-bookworm in /azure/jobs #45. Also clean: App: preload the start-up code, so it downloads while the config loads #142 with App: the Executive summary's headline figures don't wait for saved task times #138 and App: count agents in use and people with an organization at once, so the Executive summary loads sooner #139 rebased on top of it (ce04d01, a local stack that isn't pushed).
  • Azure: Agent Evaluator model on Azure SQL, with org-scoped access (W2, 2 of 3) #140, App: count agents in use and people with an organization at once, so the Executive summary loads sooner #139, App: the Executive summary's headline figures don't wait for saved task times #138, Azure: Agent Evaluator jobs collector, parser and V008 (W2, 1 of 3) #133, Installer: recommend Azure and start new installs on it #128, Add an Azure by-hand setup path #115 and Managed app: one command sets it up by hand #114 as they stand are 7 to 19 commits behind main and already conflict with it. This PR adds no conflicting file to any of them. If CHANGELOG.md conflicts after their rebase, keep both.
• Azure: Agent Evaluator model on Azure SQL, with org-scoped access (W2, 2 of 3) #140 (Azure: Agent Evaluator model on Azure SQL) builds the Azure Agent Evaluator model with buildAgentEvaluatorModel from Agent Evaluator.pbit, so it picks up this fix. Neither PR needs a change for the other.
• Azure: Agent Evaluator jobs collector, parser and V008 (W2, 1 of 3) #133 and Azure: Agent Evaluator model on Azure SQL, with org-scoped access (W2, 2 of 3) #140 don't change buildAgentEvaluatorModel, loadTemplateModel or buildModel, the installer's test/fakes.js, installer/test/model.test.js or any .pbit. So this PR's new installer test still holds after they rebase.
• No overlap: Bump the github-actions group with 3 updates #135, Bump the npm group across 2 directories with 7 updates #134 and Bump python from 3.12-slim-bookworm to 3.14-slim-bookworm in /azure/jobs #45.

Please don't merge. Keith OKs the merge separately, and it lands before rc.1.