REPORT PORTAL 2.0 - DETAILED AUTHORISED MARKETING BRIEF
Updated 17 October 2026
Production order: after the active Manager Workspace / Employee Home packs and queued Talent Planning teaser. This expands the already saved Report Portal entry, without cancelling active work.

PURPOSE
Show why users can build useful visual reports themselves, return to saved work and continue other work while longer reports run. Make this a substantial, exciting product story with a strong practical introduction and closing, clear Synthesia narration, editable PowerPoint, supporting screenshots and Coming Soon/held At Launch marketing posts.
This is implemented-product content, not permission to invent missing features or redesign the report engine.

HEADER DEPENDENCY
The original development chat owns a narrow modern compact-header update on the actual Create New Report screen, traced from Report Portal. Coordinate before taking final images of that header. Preserve every report control, route and operation. The new marketing chat must not independently edit this header or application source.

SOURCE AUDIT BEFORE CLAIMS
Read the Report Portal skill and architecture/implementation references. Trace the live New Report route, datasource catalogue and permissions, join/field selection, shaping/grouping, filters/sorts, conditional formatting, chart configuration, report run/save/reopen and background queue/alerts.
The catalogue is dynamic: administrators publish supported sources which an authorised user can select. Explain the actual supported database/API source types. Do not promise unrestricted access to arbitrary sources, joins or data outside the user's permission scope.
Use actual field/key names from the chosen sources. Company code plus employee number is a composite employee join example; both sides must be properly company-correlated. Show cardinality/duplicate consequences rather than implying any pair of columns forms a valid key.

USER-REQUESTED SCENE COVERAGE
1. Strong opening: turn a people question into a useful report, without waiting for every layout change to become a development request. Show Report Portal's actual overview and New Report entry.
2. Create New Report: show the modern compact header and the real editor's controls.
3. Available published data sources: explain governed dynamic catalogue/configuration and permission scope. Choose two appropriate safe fictional sources.
4. Combine two sources: show adding the second source, selecting its verified company/employee relationship, and confirming the join. Use the actual source UI, supported join types and key labels. Explain how the relationship keeps records aligned.
5. Select fields: choose readable fictional names, positions/departments and useful supported HR values. Show adding/removing/reordering selected fields and any relevant aliases.
6. Shape the output: explain actual supported detail/grouping layout, Top 20 versus All rows, duplicate removal and the meaning of the selected shape. All rows remains subject to the real execution/export limits; do not imply unbounded free cost.
7. Presentation and summaries: show supported themes, column/section sequence, totals, grand totals and summary choices. Explain what is being summed/counted, with appropriate data types and units.
8. Filters and output order: demonstrate real filter definitions/operators and one useful ordering example. Distinguish design-time filters from run-time parameters where applicable. Show the resulting field order and row sorting separately.
9. Conditional formatting: configure one or two meaningful supported rules, then show the real resulting appearance. Avoid arbitrary ratings/traffic lights that imply unsupported business judgements.
10. Add charts: use more than one supported visual example with correct grouping, labels, series and units. Walk through actual chart settings and final report presentation with focused screenshots.
11. Run and save: execute the bounded fictional report, show its real result, save the report through the native workflow, return to the Report Portal dashboard and show it in the actual Saved Reports area. Reopen it. If the engine must save a definition before running, preserve that actual sequence rather than faking the requested narrative order.
12. Background reports: explain that longer-running work can be queued. Configure/select one or two appropriate local sample report definitions using the supported background option. Queue through the native UI, show genuine queued/running/ready states, continue another normal task, then show the real completion popup/prompt/alert and opening the result. Also show return access from the Report Portal Background Reports area. Verify the exact alert mechanism, availability, ownership, expiry and configured processing prerequisites before describing them.
13. Strong closing: users can answer questions, shape and reuse reports, and keep working while supported background work completes. End with a concise Coming Soon call to action. No invented time savings, client quotes or released-status claims.

PACING / VISUALS
Spend meaningful time on datasource relationships, field selection, shaping, filters, conditional formatting and chart steps. Use several focused screenshots, not one unreadable entire editor. Preserve native controls and real affordances.
Keep all narration aligned to the editable PowerPoint notes; keep recording directions separate. Timing is estimated until rendered voice is checked. Include source/section coverage and a real run-save-reopen continuity sequence.
Upcoming social copy clearly says Coming Soon. At Launch variants remain held drafts. Provide topic publishing sequence, graphic mapping and alt text; nothing is scheduled or published.

DATA AND OPERATIONS
All visible people, positions, titles, departments, teams, free text and example identifiers must be fictional Star Wars-related content. Review hidden originals, cached data, notes/alt text/metadata and actual visual data sources before rendering/export. Do not show real contacts, photos, emergency details, payroll or review records.
Additional targeted LOCAL demo-data/report-definition setup is authorised with retained portable scripts and private before-values. Existing seeds are already applied. Preserve account/security/company/reporting identity and unrelated records. No remote updates.
Use safe bounded read-only sample report queries and the native save/queue path. Do not deliberately create pathological SQL, artificial blocking or heavy workload merely to make a report appear slow. A fast completed background job is still valid evidence; capture authentic states and explain the same workflow honestly. Do not fake notification success when a worker/queue is unavailable. No email/outreach, approvals, payroll or unrelated transactions.

DELIVERABLES
Reviewed editable presentation; matching Synthesia scene script and notes; genuine cleared screenshots; Coming Soon posts/graphics plus separate held At Launch drafts; publishing sequence; topic guide/manifest; internal provenance and reusable local/dev replay scripts where records/definitions were added.
Render and inspect every final slide/graphic. No new unit or Playwright suites.
Canonical topic:
F:\CodexWork\2026-10-17\chatbot-coming-soon-refresh\outputs\2026.10.1.0\Report_Portal_2_0

HEADER READY / SOURCE NOTES
The compact header is now applied in Modules/HRF_Report_Builder/BuildReport/HRF_RB_CreateReport_Wiz.aspx. Source invariants and diff whitespace checks passed; no build/session restart occurred. Review actual light/dark appearance when capturing this topic.
Rows currently offers All rows, Top 10, 25, 50, 100, 500 and 1,000. The user's Top 20 example is not an implemented preset: use a real option and explain top-N. Quick sample is a separate limit.
Themes are HRF blue, Executive, Vibrant and Monochrome. Totals require grouping/aggregates. Report sequence is data-then-charts or charts-then-data. Preserve these distinctions.

17 October 2026 - Direct user instruction
All newly created marketing images, product screenshots and supporting graphics must use dark mode going forward. Apply this to Report Portal and subsequent topic packs. Keep natural product UI and genuine data context; do not fabricate dark application states. Existing delivered assets remain preserved unless the user requests revisions.
