Projects

NDISP Case Study Series - Building a Calm Power Platform

Author

Andrew

Date Published

Format: Six short, artifact‑rich case studies

Why I’m writing this

I built a portal that helps the right people find the right Specialist Disability Accommodation — fast — and I did it inside the Power Platform without turning the browser into a theme park of scripts. The twist: people don’t just sign up and start searching. New visitors join the community first; Intake verifies eligibility; then an account is issued so they can log in, search, and apply. That pre‑approval step changed everything downstream, including how Apply becomes mostly pre‑filled.

This series breaks the work into six small chapters you can read over coffee. Each stands alone, but they play better together.

TL;DR

  • Pre‑approval onboarding: New visitors complete a multi‑step join flow; Intake verifies; approved users receive accounts to log in and search.
  • Pre‑filled Apply: Registration carries forward so people confirm rather than re‑type.
  • Server‑side first: Power Pages + Liquid for predictability; only a pinch of JS for image hydration and niceties.
  • Dataverse done right: Clean URLs with slugs, participant‑only access via Table Permissions; PII behind Field Security.
  • Calm operations: A model‑driven app that blocks half‑published listings and clarifies ownership.
  • Images that behave: SharePoint foldering, Flow‑based ordering/alt text, nightly repair, and lazy‑loaded galleries.
  • Short runway, clear lessons: The business wound down soon after launch, so I show what shipped and the measurement plan I had queued.

Series index

1) Case Study 1 — UX & Flow: Pre‑Approval → Search → Pre‑Filled Apply

How I designed the first minutes to matter: a welcoming Join the community flow, Intake‑verified onboarding, and a post‑login catalogue that’s fast, accessible, and honest. Apply is calmer because the hard questions are answered once.

Read

2) Case Study 2 — Theme & Components: Power Pages, Worn Well

Figma tokens became SCSS variables; Bootstrap behaved; Liquid components did the heavy lifting. One tidy CSS file; predictable markup; accessible defaults. No heroics just disciplined pieces that fit.
[image: Case 2 preview — tokens → components diagram, alt: mapping from color tokens to card UI]

3) Case Study 3 — Dataverse: Slugs, Permissions, and a Schema that Matches Screens

Tables mirror the UI: Property, PropertyImage, Feature (M:N), Location, Application. slug as an alternate key for clean URLs. Participant‑only reads to published listings; Applications’ PII under Field Security. FetchXML filters server‑side so nothing leaks.

Coming Soon

4) Case Study 4 — Model‑Driven App: Guardrails, Not Guesswork

Ops needed calm. Focused views, a Publish command that refuses to ship half‑baked records, and triage tooling that makes ownership explicit. Fewer errors; fewer rituals to remember.

Coming Soon

5) Case Study 5 — Automation & Assets: Self‑Healing Galleries

Humans upload images in surprising ways. Flows provision folders, sort by filename, pull alt text from SharePoint Title, and run a nightly repair. On the page, Liquid emits JSON and a tiny script hydrates images without layout shift.

Coming Soon

6) Case Study 6 — Launch Snapshot: What Shipped and What I Planned Next

Launch checks, early signals, and the measurement plan I was ready to run (time‑to‑first‑result, filter usage, apply drop‑off). The business closed soon after, so this is the tidy hand‑off I left behind.

Coming Soon

Side note: in the same program I also rebuilt NDISP’s marketing site to match the portal’s voice. It’s out of scope here, but worth a nod.

Who this is for

Power Platform teams who care about UX, schema, and ops agreeing. Designers/developers who want to see Liquid and SCSS used calmly. Product folks who prefer trade‑offs over buzzwords and appreciate seeing what shipped vs what was parked.

What’s different about this build

  • Gated by design: Access follows verification, not vibes. Only issued accounts (treated as participants, including those applying on someone’s behalf) reach the catalogue.
  • Clean by default: Slugs for URLs, field names that echo the UI, and permissions that make sense to humans.
  • A11y without drama: Keyboard paths that actually work, contrast that actually passes.
  • Minimal JS: Just enough to keep images smooth; everything critical renders server‑side.

Artifacts you’ll see

Screens (desktop + mobile), Mermaid diagrams (journey, state, ERD), snippets (Liquid, FetchXML), and checklists (a11y, go‑live). Each case links to its own bundle, so you can skim or dive.

FAQ

Do you have hard numbers?
Short runway means no long‑tail metrics. I include launch‑window checks and the measurement plan I had ready.

Is the Access Management app part of this series?
No. It’s an internal tool with an embedded React/TypeScript SPA for ZKTeco. I reference it where relevant and will publish it separately.

Did you also rebuild the marketing site?
Yes — mentioned for context. It’s its own story.

Start where the story starts: Read Case Study 1