West Yorkshire Combined Authority / Pilot Learner Destinations System

Questions

Open questions and queries to resolve as the commission gets under way — mostly for WYCA or the Thrive team. Added to as they arise.

← Back to Destinations Index
Open questions
  1. 1 Does WYCA have existing brand and reporting assets they want reused, so the dashboard and outputs match house style from the start?
    • Logo(s) and any usage guidance
    • Brand / style guide
    • Colour palette — Pantone references and hex codes
    • Fonts / typography
    • An existing Power BI .pbix report or theme template (JSON theme) to build the dashboard on
    For: WYCA · Relevant to: live dashboard (D2)
  2. 2 Which tenants will be used for development and for handover, across each platform?
    • Power BI
    • Azure
    • Azure DevOps
    • Active Directory / Entra ID
    For: WYCA / Thrive · Relevant to: dev environment & handover (system transfers to WYCA at completion)
  3. 3 How will Learning Providers access the dashboard — identity and Power BI licensing?
    • Identity (Active Directory / Entra ID): how are provider users authenticated?
    • Power BI licence: will providers bring their own Power BI Pro licence, or do we provide access?
    How this could work — providers as guests in our domain:
    • Guest (B2B) access: invite each provider user as an Entra ID B2B guest into our tenant, so they sign in with their own organisational account — no new credentials for us to create or manage.
    • Data isolation: each guest sees only their own provider's learners — handled by row-level security (see Q4 for the mechanism).
    • Licensing options:
      • the guest uses a Power BI Pro licence from their home tenant (works cross-tenant); or
      • we assign Pro to the guest in our tenant; or
      • we host the report in a Premium / Fabric capacity workspace (F64+ / P SKU) so guests need only a Free licence to view.
    For: WYCA / Thrive / providers · Relevant to: dashboard access & licensing (D2)
  4. 4 Row-level security — where is the user-to-provider mapping stored and maintained?
    • RLS needs a mapping of each dashboard user (guest UPN / email) to their Learning Provider, so the report filters to their own learners only.
    • Where does this mapping live (e.g. a table in the analysis dataset), who owns it, and how are provider users added or removed as staff change?
    How this could work — Dynamic RLS: a single row-level-security role with a DAX filter on USERPRINCIPALNAME() — the signed-in user's UPN — matched against the user-to-provider mapping table. The model then filters every fact to that user's provider automatically. One role covers all providers, so onboarding a new provider user is just a row in the mapping table (plus a guest invite and licence — see Q3), not a report change. This is what makes "each provider sees only its own learners" scale to 45,000+ learners without rework.

    Note: the mapping stores provider staff identities (email / UPN) mapped to a provider code — not learner personal data, so it sits outside the pseudonymised-feed boundary. It still needs a named owner and an onboarding / offboarding process.

    For: Thrive · Relevant to: dashboard RLS (D2)
  5. 5 What is the definitive list of the 8 participating learning providers?
    • Provider names (the confirmed 8, vs the ~15 illustrative organisations in the bid)
    • Which provision types each delivers (Essential Skills / ESOL / Construction)
    • Expected learner volumes per provider (Luminate ESOL ~3,400 noted)
    For: WYCA (Amy) · Relevant to: provider dimension, RLS, min-cell suppression (D2)
  6. 6 Will there be multiple dashboard users per provider?
    • How many users each provider needs access for (drives the Power BI Pro licence count and guest invites)
    • Confirms the RLS mapping is many users → one provider (see Q4)
    For: WYCA / providers · Relevant to: dashboard access, licensing, RLS (D2)
  7. 7 Are there up to 3 separate initial and follow-up interviews per learner?
    • i.e. one initial (baseline) + one follow-up (outcome) survey per course, capped at 3 courses — so up to 3 matched pairs per learner
    • Confirms the survey grain is learner × course, and that the "no more than 3" cap applies per course (not to total touchpoints)
    For: WYCA / Thrive · Relevant to: data model grain, matched-pair counting (D2)
  8. 8 Is the ~14,500 figure unique learners or course enrolments?
    • Changes the funnel denominator that the targets are measured against (2,900 baseline, 698 matched pairs)
    • If per-course enrolments, the number of surveys issued may differ from the number of people (a person can hold up to 3)
    For: WYCA · Relevant to: funnel denominator, response-rate tracking, matched-pair targets (D2)
  9. 9 Where is the unique identifier assigned, and is it per student or per enrolment?
    • At what point in the flow is the unique identifier created (e.g. on intake into the survey platform, before pseudonymisation)?
    • Is it one identifier per student (persisting across all their courses) or one per enrolment (course)?
    • Needed to enforce the 3-survey cap per person and to link a person's multiple course surveys.
    For: Thrive / IBP · Relevant to: matching, de-duplication, data-model grain (D2)
  10. 10 Are we having development environments — in the survey software, and dev / test / production?
    • Survey software (Snap): a dev / test environment to build and test surveys before issuing live?
    • Data platform: separate dev / test / production environments (Fabric workspaces, pipelines, Power BI)?
    For: Thrive / IBP · Relevant to: environments, deployment, testing (D2)

Add new questions to the list above as they come up.