Skip to content
DCS
PR

What this prototype covers

A working walkthrough of the DCS Client Insights PRD, built with generated data so the structure, rules and workflow can be reviewed before any integration work starts.

Every figure in this application is generated from a fixed seed. Nothing here touches Microsoft 365, a customer tenant, the ticketing system or SQL. Customer names, users, tickets and assets are fictional.

Modules you can open

Each link opens the working screen

ModuleWhat it shows
Home and customer searchSearch by name, account number (HAR015) or domain, portfolio KPIs, attention list
My weekOne account manager’s chase list, renewals, new findings and stale data
Customer directoryServed by the read API — server-side search, filters, sorting and paging
Overview dashboardKPI cards, user trend, licence mix, adoption, support and asset charts, health drawer
Microsoft 365Users, licensing, email, Teams, OneDrive, SharePoint and security behind one set of tabs
Security and MFARegistration coverage, licensed capability and contracted security cover
Support and SLAQuote/project/install exclusions, response, resolution, SLA, categories
Assets and equipmentType mix, age, OS, warranty, contract cover per machine, audit exports
Contracts and renewalsAgreement type, contract lines, notice periods, renewal to pipeline
Renewals (portfolio)Every contract reaching its end date across the book, nearest first
Alert centreEvidence, rule version, approve/dismiss/snooze with memory
OpportunitiesCustomer view of the sales pipeline, convert findings once
Sales pipelineTwo-colour rows from the workbook, orders and lost, chase list, win and loss reasons
TimelineAggregated events across sync, licensing, assets, findings and packs
Meeting pack generatorTemplates, section picker, classification, branded printable output
DocumentsRegister of contracts, diagrams and plans — links to where files actually live
Customer groupsTrusts and holding companies with every member site side by side
Customer settingsMaster data, connection state, contacts, logo upload and branding that persists
Cross-customer insightsPortfolio aggregates, common findings, service performance
Sync statusCollection passes, auth mode, relationship state, results, sanitised diagnostics
AdministrationRules, role matrix, audit log, data quality, read API catalogue
Brand and exportsDCS logo, colours and a live preview of the export cover and charts
Agents and sourcesWhat Microsoft 365 agents can ask, and where the data comes from
Read APIThe JSON contract behind every screen — the directory, pipeline and renewals are its clients

Business rules demonstrated

Appendix B of the PRD, visible in the running app

BR-001 / BR-002Account number maps the SQL side; an immutable internal CustomerId is the primary key.
BR-003Quotes, projects and planned installs never affect response, resolution or SLA figures.
BR-003aSLA is a flat 8-hour response target measured logged to responded, and applies to contract calls only. Time-and-materials work is counted and shown, but never scored.
BR-003bSupport performance is grouped by the person who logged the call, not the engineer who took it — that is how DCS read it with the customer.
BR-004Week, month, quarter, year, all-time and custom filtering throughout, with snapshot and event measures kept apart.
BR-005Branding is saved once and reused for dashboards and packs.
BR-006The overview shows a finding count and a link, never the alert list.
BR-007Suggestions appear once and remember dismissal, alternatives and snooze dates.
BR-008Missing data is excluded from the health score rather than penalised.
BR-009Pipeline values are role-gated and excluded from customer-facing packs.
BR-010Findings recommend a category — security review, hardware refresh — never a specific supplier product.
BR-011Microsoft 365 and SQL freshness are always shown separately.
BR-012No screen lets Sales or Agents edit imported figures.
BR-013Contract lines are priced per unit — standard amount, discount, amount and quantity — and terminated lines stay on the record with the date they ended.
BR-014A contract amount is always shown with its billing period. Hardware is billed quarterly or six-monthly, and the annual figure is derived from the invoice, never assumed.
BR-015Invoiced maintenance across a contract reconciles to that contract amount. In-service machines off maintenance are valued at standard rates; spares and retired kit are excluded, not counted as a gap.
BR-016The software register reconciles to its own support contract the same way. Bespoke support is negotiated rather than rate-derived, so it is excluded from the reconciliation instead of forced to tie.
BR-017Every export carries both identities — the DCS brand and the customer’s — with the initials used only when no logo has been uploaded.
BR-018Agent actions are read-only. An agent can report a renewal, a maintenance gap or a quiet opportunity; it cannot change any of them. Pipeline values are marked internal and omitted from the customer brief.
BR-019A collection pass that loses one dataset degrades that customer to partial rather than failing the pass, and a failed pass never overwrites good figures with zeros.
BR-020Identity is decided from the request, not the browser. Entra group membership maps to a platform role, being in the directory without an entitling group is rejected, and a service identity is always read-only.

Deliberately not built

What a production build still needs

  • Real Microsoft Graph, GDAP or app-consent authentication — the collector is out of scope for a prototype and needs the proof of concept in PRD section 13.
  • Real contract records — the contracts and renewals module is modelled on how the SQL contract data is expected to look, and needs the actual schema before it can be trusted.
  • The DCS internal API and SQL read models — support and asset data here is generated, not read from a source system.
  • The Entra ID sign-in journey itself — the reverse proxy owns the redirect. The platform reads the validated claims it passes and maps groups to roles; the header role switcher remains only while the demo data is in use.
  • Server-side PDF generation — the pack renders in the browser and prints to PDF.
  • File storage — the document register holds links and classification; the files themselves stay in SharePoint or on the file server.
  • Health scores and findings are computed on every request. On a 300-customer estate they should be materialised once per sync and read back, which is a change to the collector rather than to any screen.

Things worth trying

  • • Build an Equipment Audit pack from Reports, or export the audit CSV from Assets.
  • • Filter the pipeline, save it as a view and star it — it opens that way next time.
  • • Dismiss a finding in a customer's alert centre, then look at that customer in the directory — the findings count and health score change, because the decision was recorded on the server.
  • • Open a group to see which member sites are on contract and which are not.
  • • Open Renewals and add one to the pipeline — the annual value comes across as the opening figure.
  • • Upload a customer logo in Settings → Branding — it appears in the header, every list and the meeting pack.
  • • Switch role to Agent and reopen the pipeline — values disappear, stages stay.
  • • Dismiss a finding in the alert centre with an alternative recorded, then reload: it stays suppressed.
  • • Change a lead status to Ordered on the pipeline — the row moves to the orders table immediately.
  • • Generate an Internal meeting pack, then a Customer-facing one, and compare the pipeline section.
  • • Open a customer with a failed sync (Halcyon Architects) to see the stale-data behaviour.
  • • Turn off Phase 2 in any customer's Settings to see the Phase 1 “awaiting SQL integration” state.