NDISP Case Study Series - Building a Calm Power Platform

Series status: Live now • Posting Case 1 today, the rest rolling out over the coming weeks
Scope: End‑to‑end build of the NDISP property listings and applications portal + supporting ops and automation
Stack lens: Power Pages, Dataverse, Liquid/JS, Bootstrap/SCSS, SharePoint, Power Automate, Model‑Driven App

Why this series exists

The short version: we shipped a portal that helps eligible SDA participants and support coordinators find suitable properties and apply without email ping‑pong. It’s built on the Power Platform, but the interesting bit is how the UX, data model, security, and automation agree on what “good” looks like.

This series breaks the project into six digestible chapters. Each chapter has artifacts (screens, snippets, diagrams) and a punchy narrative you can read over coffee.

Promise: honest trade‑offs, minimal buzzwords, clear hand‑offs from design to build. No invented metrics.

TL;DR (for skimmers)

• Auth‑gated search: Users sign in and confirm eligibility before search. Friction kept low; consent handled cleanly.
• Server‑side first: Power Pages + Liquid for predictability; JS only where it pays off.
• Dataverse with slugs: Clean URLs via alternate keys, tight table permissions.
• Calm operations: A model‑driven app that prevents half‑published listings.
• Images that don’t break: SharePoint + flows + a tiny hydration script keep galleries sane.
• Short runway, clear lessons: Business wound down soon after launch, so we share what shipped and the plan we had ready.

Series index (and what each part covers)

1) Case Study 1 - UX & Flow (Auth‑Gated, Human‑Friendly)

A story of designing the first minute that matters:

sign‑in → quick eligibility → search → cards → detail → apply.

Accessibility first, plain‑language microcopy, and a journey that respects consent.

Read It

2) Case Study 2 - Theme & Components (Power Pages + Liquid) | Coming soon

How a small Bootstrap/SCSS layer, Figma tokens, and Liquid partials kept the portal clean and fast. Cards, filters, detail sections—each with one job.

3) Case Study 3 - Dataverse Schema & Security | Coming soon

Tables that match the screens: Property, PropertyImage, Feature (M:N), Location, Application. Alternate‑key slugs, table permissions, and field security so URLs are clean and PII stays private.

4) Case Study 4 - Model‑Driven App (Back Office That Won’t Let You Fail) | Coming soon

Views that surface what’s risky, forms that reduce guesswork, and command‑bar actions like Publish and Assign to me.

5) Case Study 5 - Automation & Assets (SharePoint + Flows + Hydration) | Coming soon

Folder provisioning, upload normalization, alt text from titles, and a nightly repair job. On the page, Liquid emits JSON and a tiny script hydrates images in order.

6) Case Study 6 - Launch Snapshot & Portable Lessons | Coming soon

What shipped, what we validated, and the measurement plan we prepped but didn’t get to run. A tidy hand‑off for anyone picking up the torch.

Who this is for

• Power Platform teams who want to see how UX, schema, and automation fit together.
• Product folks who like pragmatic trade‑offs and clear guardrails.
• Designers/devs curious about using Liquid and Dataverse slugs without hating life.

What’s different about this build

• Gated search with consent: respectful eligibility check, clear privacy stance.
• Clean URLs: alternate‑key slugs instead of GUID soup.
• Ops that self‑correct: repair job keeps galleries and heroes from drifting.
• Minimal JS: accessibility and performance by default.

Artifacts you’ll see along the way

Screens (desktop + mobile), Mermaid diagrams (journey, state, ERD), code crumbs (Liquid, FetchXML), and checklists (a11y, go‑live). Every part links to its own artifact bundle.

FAQ

Do you have hard numbers?
The business closed shortly after launch, so we don’t claim long‑tail metrics. Each case shows launch‑window checks and the measurement plan we had queued.

Is the Access Management app part of this series?
It’s a separate internal tool built in the same tenant, with an embedded React/TypeScript SPA for ZKTeco integration. Not part of this six‑part series, but we’ll reference it where relevant and may publish a standalone write‑up.