Viva Insights Prompt Library

Help me create a self-contained static HTML dashboard for people analytics and IT leaders that summarizes Copilot adoption trends and group differences from a Viva Insights person query export.
Start by loading the actual CSV and printing the row count, column names, data types, date range, and number of unique people, then map the real metric and HR columns from what is present.
Do not assume exact field names, and ask me to confirm the primary activity metric or any missing HR columns if the mapping is ambiguous.
Prefer Copilot Enabled User or Total Copilot enabled days for licensing. Under the documented native licensed-only M365 Copilot rules, null means unlicensed and zero activity means licensed but inactive. Without explicit licence fields, use a verified metric with those semantics. Do not apply this rule to unlicensed Copilot Chat or Consumption credits.
Confirm configured weekly grouping and metric windows. Date gaps do not establish cadence. Within a supplied complete query's configured scope, absent activity rows contribute zero. Failed joins, unavailable sources, out-of-scope periods and known coverage failures remain unresolved.
Build weekly adoption metrics using distinct people per week, then add useful group views from available HR attributes. If no suitable group field exists, skip those views and explain why.
Keep the overall dashboard even when no HR attribute is suitable for grouping.
The output must be a single self-contained static HTML file with inline assets and no server or external dependencies.
Suppress any group with fewer than 10 distinct people, or the stricter organisational minimum, and withhold breakdowns that could reveal suppressed cells. Do not publish individual rankings. Note skipped charts or missing segments.
At the end, list any assumptions you made about metric selection, licensing logic, or field mappings.

Use the viva-insights-analysis skill to create a self-contained static HTML report answering: how many people use the measured AI tools, which cohorts have the heaviest usage, and how tool use differs by organisational group.
Read the supplied queries from the workspace's data folder and save all generated files under its output folder. Do not write to filesystem-root /data or /output.
Use the weekly Person Query as the population spine. Prioritise Total Copilot actions taken, Cowork tasks submitted, User-initiated Cowork tasks submitted, Total GitHub AI Credits used from Consumption, and Conversational agent sessions from the Agent query.
Inspect actual headers and source configuration first. Follow https://microsoft.github.io/viva-insights-sample-code/query-join-guide/ for native keys, aligned weeks, aggregation before joins and scoped missing-row rules. Keep omitted sources and failed joins unresolved.
Report distinct observed users for each tool and the union across tools, never the sum of tool user counts. A known positive establishes observed use. Without any positive, classify as no observed use only when every selected source is resolved for that person-period, otherwise unknown. Withhold an overall rate if selected-source coverage is unresolved.
Keep actions, tasks, sessions, M365 credits and GitHub credits in separate units. Do not add User-initiated Cowork tasks submitted to Cowork tasks submitted without a verified disjoint definition. Positive GitHub credits establish metered usage, not every GitHub interaction.
Use distributions and metric-specific upper-decile cohorts to describe heavy usage. Show their aggregate group mix, never names, identifiers or person-level leaderboards. Do not infer productivity or value.
Use available HR fields for group comparisons and continue with overall results if none are suitable. Use a common reporting window and show denominators and missingness. Distinguish population reach from licensed adoption, which needs product-specific eligibility.
Use the stricter organisational minimum or 10 distinct people for every published cell, including high-usage cohorts, complements, charts, embedded data and downloadable aggregates.
Produce a summary-first report with tool reach, overlaps, separate usage-intensity panels, group comparisons and trends where supported. Include the source-to-metric mapping, skipped analyses and executed validation results. Embed assets locally with no CDN, external runtime or server dependency.

Help me produce a concise executive summary memo for senior leaders that explains Copilot adoption progress, risks, and recommended next actions from a Viva Insights person query export.
Start by loading the real CSV and printing row count, column names, data types, date range, and unique people so you can map the actual Copilot and HR fields.
Adapt the column names dynamically rather than assuming the defaults, and ask me for the file path, preferred output format, or any ambiguous field mapping before you proceed.
Prefer Copilot Enabled User or Total Copilot enabled days per person-week. Native licensed-only M365 Copilot nulls mean unlicensed and zero activity means licensed but inactive. A verified metric with those semantics is a valid fallback without explicit licence fields. Keep failed joins and genuinely unresolved licence status separate.
Read configured grouping, week start and metric windows. Date spacing is only a diagnostic. In a supplied complete query's configured scope, absent activity rows contribute zero. Unavailable sources, out-of-scope periods and known coverage failures remain unresolved.
Calculate every reported number directly from the data, with distinct-person denominators and an explicit person versus person-week estimand.
Compare recent adoption and usage trends using the amount of history actually available, and call out when the dataset is too short for the preferred comparison window.
Keep the tone balanced and executive-friendly, include specific numbers in findings and recommendations, and avoid unsupported claims.
Suppress groups below max(the organisational requirement, 5 distinct people), including complementary cells and embedded data. Use floor 10 if this memo is part of a dashboard or joined-query workflow. Never publish individual rankings.
Use only available HR attributes for group findings; if none are suitable, omit group comparisons and report overall results.
End by listing any assumptions you made about activity metrics, comparison windows, or segment mappings.

Help me build an ROI summary report for finance and IT leaders that estimates the value of Copilot usage from a Viva Insights person query export.
Start by loading the actual CSV and printing row count, column names, data types, date range, and unique people so you can identify the real Copilot and collaboration fields.
Adapt to the column names that are present, and ask me for the file path, hourly rate, license cost, or any ambiguous metric mapping instead of guessing.
Prefer Copilot Enabled User or Total Copilot enabled days per person-week. Native licensed-only M365 Copilot nulls mean unlicensed and zero activity means licensed but inactive. A verified metric with those semantics is a valid fallback without explicit fields. Omit licence-dependent estimates only if licensing remains genuinely unresolved.
Read configured cadence and measurement windows, not date spacing. Within a supplied complete query's configured scope, absent activity rows contribute zero. Failed joins, unavailable sources, out-of-scope periods and known coverage failures remain unresolved.
Use a recent multi-week average, distinct-person denominators and an explicit person versus person-week estimand. Assisted hours are not measured time saved: ask me to approve a realisation factor and any proxy conversion before estimating potential value, then make the break-even threshold explicit.
Include a sensitivity analysis under multiple hourly-rate and adoption scenarios, and be explicit that any licensed versus unlicensed comparison is observational and does not prove causation.
Report negative or uncertain value scenarios honestly. Suppress groups below max(the organisational requirement, 5 distinct people), using floor 10 for dashboard/joined outputs. Protect complementary cells and embedded data; never publish individual rankings.
Finish by listing every assumption you had to make about value realization, proxies, and segment definitions.

Help me create a segmentation and churn analysis for Copilot usage that classifies licensed users, tracks movement between segments over time, and highlights at-risk groups.
Start by loading the actual CSV and printing row count, column names, data types, date range, and unique people so you can map the real activity and HR fields.
Do not assume exact column names, and ask me for the file path, the main activity metric, or any unclear field mapping before you continue.
Prefer Copilot Enabled User or Total Copilot enabled days to establish licensing. For native licensed-only M365 Copilot metrics, null means unlicensed and zero activity means licensed but inactive. A verified metric with these semantics is a valid fallback without explicit licence fields.
Use `identify_usage_segments()` (vivainsights) to compute the five weekly usage segments. If it is unavailable, clearly label any alternative segmentation and print its thresholds.
Include both week-level segment trends and a stable user segment for group breakdowns, then build a week-to-week transition matrix only for users present in consecutive weeks.
If no suitable HR attribute is available, skip group summaries and focus on overall segment and churn results.
Independently of the rolling segments, define weekly activity from the observed action count. Churn means at least two consecutive active weeks followed by at least two consecutive inactive weeks; date it to the first inactive week once the second confirms it.
Identify currently at-risk users separately: they have one inactive week immediately after at least two active weeks and have not yet met the churn definition. Do not treat unknown or unlicensed weeks as inactive.
Flag if the time span is too short for reliable churn analysis.
Suppress below max(the organisational requirement, 5 distinct people), using floor 10 for dashboard/joined outputs. Protect complementary cells and embedded data, and never publish individual rankings.
Read configured weekly grouping and measurement windows, not date spacing. Within a supplied complete query's configured scope, absent activity rows contribute zero. Failed joins, out-of-scope periods and known coverage failures remain unresolved. Keep unlicensed weeks in the calendar so they break streaks and rolling eligibility windows.
End by listing any assumptions you made about thresholds, churn rules, or field mappings.

Help me generate an exec-ready PowerPoint deck that summarizes Copilot adoption for senior leaders from a Viva Insights person query export.
Start by loading the actual CSV and printing row count, column names, data types, date range, and unique people so you can map the real Copilot and HR fields before building slides.
Adapt field names dynamically, use the installed toolchain that best supports native PowerPoint charts, and ask me for the file path, template path, or any ambiguous metric mapping before you proceed.
Prefer Copilot Enabled User or Total Copilot enabled days for licensing. Native licensed-only M365 Copilot nulls mean unlicensed and zero activity means licensed but inactive. Use a verified metric with those semantics as a fallback without explicit fields. Omit rates only when licence status or licensed activity is genuinely unresolved.
Read configured cadence and measurement windows, not date spacing. In a supplied complete query's configured scope, absent activity rows contribute zero. Failed joins, out-of-scope periods and known coverage failures remain unresolved.
Create the deck directly as a .pptx file with native editable chart objects wherever the library supports them, and avoid HTML to PowerPoint conversion pipelines.
If a needed chart type cannot be created natively, simplify it to a supported native chart where possible and clearly note any remaining slide that must fall back to an image.
Use distinct-person denominators and state whether summaries weight people or person-weeks. Suppress groups below max(the organisational requirement, 5 distinct people), using floor 10 in dashboard/joined workflows. Protect complementary cells and embedded chart data; never publish individual rankings. Skip unavailable slides.
Use commentary-led slide titles and keep each number traceable to a local evidence ledger with dates, units, aggregation, bases and denominator. Related charts or tables can share a slide if labels and caveats remain readable.
If no suitable HR attribute is available, skip group slides and note why; continue with supported overall slides.
For an existing user-edited deck, save a rollback, preserve unrelated content and verify the source has not changed before replacement. Remove only comments whose requested edits have been verified.
Verify numbers, embedded chart data, privacy and actual rendering separately. Report unavailable visual checks honestly.
Finish by listing any assumptions you made about chart support, metric mappings, or optional slide substitutions.

Help me use the Copilot Causal Toolkit end to end by first configuring and running the right notebook for my data, then interpreting the outputs for a business audience.
Start by loading the actual CSV and printing row count, column names, data types, date range, and unique people so you can determine whether it is a Person Query or Super Users Report and map the real fields.
Do not assume exact paths or variables, and ask me for the CSV location, toolkit location, and business question if any of those are missing or ambiguous.
Keep the required two-part flow from this card, which means run and validate the analysis first, then interpret the generated outputs in a separate pass.
Do not change the treatment variable from Total_Copilot_actions_taken, do not edit shared helper modules, and warn me if the dataset is shorter than about 12 weeks.
When choosing or configuring the notebook, adapt subgroup, collaboration, and outcome variables to the columns that actually exist in my data.
Before execution, check the selected notebook's minimum subgroup requirements. The supplied notebooks require at least two suitable subgroup attributes for pairwise analysis. With zero or one, skip subgroup analyses and run overall analysis only if the notebook has a verified overall-only path. Otherwise return a readiness assessment and do not run it.
Before fitting, verify the notebook's actual grain, exposure/outcome windows, pre-exposure controls, overlap and identifying assumptions. DML is not itself an identifying design. If unresolved, return readiness or an agreed association rather than a causal claim; do not run every estimator.
Prefer Copilot Enabled User or Total Copilot enabled days for licensing. Native licensed-only M365 Copilot nulls mean unlicensed and zero activity means licensed but inactive. A verified metric with these semantics is a valid fallback. Read configured cadence, not date spacing. Absent in-scope activity contributes zero, while failed joins and known coverage failures remain unresolved. Check unlicensed Copilot Chat separately before assigning causal controls.
Publish only groups meeting max(the organisational requirement, 10 distinct people), protect complementary cells and embedded data, and never publish individual rankings.
When interpreting results, explain the ATE direction in business terms, include the sensitivity analysis, and avoid overstating causation or borderline significance.
Finish each phase by listing any assumptions you made about notebook choice, variable mappings, or output interpretation.

Use the viva-insights-analysis skill to build a self-contained static HTML report about workload signals relevant to employee wellbeing. Read the Person Query from the workspace's data folder and save all generated files under its output folder, not filesystem-root paths.
Answer: how common are elevated collaboration and connected-time signals, which groups show them more often, and which other recorded work patterns are associated with them?
Prioritise Collaboration hours, Active connected hours, After hours collaboration hours and Weekend collaboration hours. Inspect actual headers, configured cadence, metric windows and working-hours settings. Use only supported measures and actual organisational attributes.
Never describe telemetry as diagnosed burnout, health status, total working hours or measured lack of personal time. Use "elevated workload exposure" for the descriptive flag.
For a complete weekly panel, calculate each person's mean weekly value over a common reference window, requiring at least four complete weeks with all four primary measures observed. Give each person equal weight when calculating each metric's population 90th percentile.
Flag elevated exposure when at least two of the four person-level means are strictly above their respective fixed reference thresholds. Equality does not count. This is a proposed descriptive rule, not a validated risk model. Show the thresholds, missingness and sensitivity at the 85th and 95th percentiles. If all four measures or sufficient weeks are unavailable, omit the combined flag and keep component views.
Do not add overlapping hour measures. Do not fill missing behavioural hours with zero. Keep ineligible or incomplete observations separate from unflagged people.
Compare sufficiently sized groups using prevalence with explicit denominators and component distributions. Use other metrics only for exploratory associations, excluding the flag's defining metrics and their transformations from any claimed driver analysis. Do not present associations as causes or predictions of burnout.
Use the stricter organisational minimum or 10 distinct people for every published cell and its complement, including flagged cohorts, embedded data and downloads. No individual rankings or employee-level risk lists.
Produce a summary-first HTML report with group comparisons, compatible time trends, caveats, an evidence ledger and reproducible source. Embed all assets, verify offline desktop/mobile rendering, and record executed versus skipped checks.

Use the viva-insights-analysis skill to create a self-contained static HTML report on external collaboration. Read the Person Query from the workspace's data folder and save all generated files under its output folder, not filesystem-root paths.
Answer: what share of people collaborate externally, how much time external collaborators spend doing so, which internal groups have the most external collaboration, and how patterns differ across functions and over time.
Prioritise External collaboration hours and Collaboration hours, mapping the actual raw headers and imported names. Inspect configured grouping, metric windows, population, duplicates and missingness before calculating.
Define period participation as distinct people with positive External collaboration hours divided by distinct people with resolved external activity in that in-scope period. Report the full population and unresolved activity separately. For whole-window participation, count each person once and distinguish known positive, complete observed zero and unresolved coverage.
Report external hours among active external collaborators separately from the population-wide mean. Use comparable observation windows, show denominators and do not rank small or incomplete groups.
Compare internal groups by participation rate and mean external hours per active collaborator, showing total volume separately so large groups do not automatically appear most intensive. Use available function and other HR fields, omitting unsupported breakdowns.
The Person Query cannot identify external counterpart organisations or domains. Only add "who we collaborate with" views when suitable approved external collaboration data and verified keys are supplied. Otherwise state this question is unanswered. Do not infer counterpart identities from internal HR fields or scrape email domains.
Only calculate external hours as a share of Collaboration hours if their definitions and windows establish a valid subset relationship. Distinguish the ratio of sums from the mean of person-level ratios and omit undefined denominators. Do not sum stock metrics or overlapping windows.
Use the stricter organisational minimum or 10 distinct people for every cell and its complement, including active-collaborator cohorts, partner intersections, embedded data and downloads. Never publish person-level rankings.
Produce a summary-first HTML report with participation, active-collaborator intensity, group comparisons, compatible trends, an optional counterpart section and an evidence ledger. Embed all assets, verify offline desktop/mobile rendering, and log skipped analyses explicitly.

Help me reproduce or customise the Consumption and Ways of Working dashboard.
Recover choices already supplied, then ask only for missing checkout, demo versus real mode, output folder and intended changes.
Read frontier-analytics/skills/viva-insights-copilot-dashboards/SKILL.md in that checkout as workflow instructions, without requiring skill installation.
Use its Consumption manifest and the shared R runner; do not regenerate the dashboard from scratch.
For real exports, inspect locally, show supported and excluded panels, and get my approval before building.
If no suitable HR group field is available, set `group=false`, omit group breakdowns, and keep supported period/service results.
Do not invent tokens, licensing, coverage, identity mappings or causal conclusions.
Use max(the organisational requirement, 10 distinct people) for all published
and embedded data, protect complementary cells and never publish individual rankings.
Read configured grouping and measurement windows, not date spacing. Within a supplied
complete query's configured scope, absent activity contributes zero. Null credit
cells, failed joins, unavailable sources, out-of-scope periods and known coverage
failures remain unresolved. Do not apply licensed-only M365 Copilot null semantics to credits.

Help me reproduce or customise the Developer Experience and Copilot dashboard.
Recover choices already supplied, then ask only for missing checkout, demo versus real mode, output folder and intended changes.
Read frontier-analytics/skills/viva-insights-copilot-dashboards/SKILL.md in that checkout as workflow instructions, without requiring skill installation.
Use its GitHub manifest and shared R runner; preserve coverage, privacy and synthetic labels.
For real GitHub files, inspect only and explain the missing contract evidence; v1 has no verified real build adapter.
Do not infer productivity, code quality, burnout, licensing or non-use from activity alone.
Use max(the organisational requirement, 10 distinct people), protect complementary
cells and embedded data, and never publish individual rankings. Read configured cadence
and measurement windows, not date spacing. Within a supplied complete query's configured
scope, absent activity is zero. Unresolved GitHub nulls, failed joins, out-of-scope
periods and known coverage failures stay unknown. Licensed-only M365 Copilot null
semantics do not establish GitHub licensing. This does not enable the missing real build adapter.

Help me parse a raw Microsoft Purview audit log export into a clean flat dataset and data dictionary that are ready for downstream analysis.
Start by loading the actual file and printing row count, column names, data types, date range if available, and sample records with direct identifiers such as UserId, UPNs and email addresses masked so you can inspect the real schema before assuming any mappings.
Do not assume exact Purview or AuditData field names, and ask me for the file path or any known Copilot operation names if the mapping or filter logic is unclear.
Parse AuditData defensively with error handling, count malformed rows, and adapt extracted columns to the structures actually present in the data.
Flatten nested JSON only one level deep, keep deeper structures as JSON strings, standardize final names to snake_case, and avoid exposing raw UserIds in printed output.
If the file is large, process it in chunks, then produce both a full cleaned output and a Copilot-focused output when the filter finds relevant events.
Also generate a data dictionary that records source, type, null rate, and examples for each final column so downstream users can understand the schema.
End by listing any assumptions you made about field mappings, event classification, or anonymization.

Help me produce an exploratory report on Copilot agent and extension usage from Microsoft Purview audit logs for program, security, and analytics stakeholders.
Start by loading the actual file and printing row count, column names, data types, date range, and sample records so you can inspect the real schema before analyzing anything.
Do not assume exact Purview field names, and ask me for the file path or confirmation of the user, timestamp, operation, workload, or AuditData fields if the mapping is ambiguous.
Use a broad first-pass filter for Copilot-related operations and workloads, show what matched, and refine the logic based on the values actually present in the data.
If AuditData exists, inspect it carefully before extracting agent or extension details, and skip that section with a clear note if those fields are unavailable.
Use static charts in a standalone HTML or notebook output, protect privacy by avoiding raw email addresses or other direct identifiers in printed output, and sample only for exploration if the dataset is very large.
Call out system-generated events, duplicates, or other schema quirks that could distort the analysis.
End by listing any assumptions you made about field mappings, Copilot filters, or agent identification.