Microsoft certification badges banner
Headshot of Michael Korting

Blog

Microsoft 365 • Security • Automation

Building a Serverless Data Dashboard with Azure Functions and SharePoint

A real-world build story: how a usable cloud application came together in three focused weekends.

Why this matters

It is easy to discuss cloud architecture in abstract diagrams. It is much more valuable to see how a real solution comes together under time constraints, incomplete information, and evolving requirements.

This application was built in roughly three weekends (about 6 total hours). The goal was not perfection—it was to deliver something functional, secure, and usable using modern Microsoft cloud services.

Architecture overview

Manual Data Entry
        ↓
Structured List
        ↓
Serverless API
        ↓
Static Web App
        ↓
Live Dashboard

What makes this interesting is not the architecture itself, but how each layer emerged incrementally over time.


Weekend 1 (≈ 2 hours): Foundation and validation

The first session focused on answering a simple question:

Can each layer of the system exist independently and be validated?

Data layer (list design)

  • Created a dedicated site as the system of record
  • Built a structured list aligned to real-world data
  • Carefully selected column types (text, choice, number, date)

Early schema decisions mattered. A clean structure later reduced API complexity and transformation logic.

Hosting layer

  • Provisioned static web hosting
  • Deployed a basic HTML splash page
  • Validated CI/CD pipeline behavior
  • Configured custom domain + HTTPS

At this stage, nothing was connected—but everything worked independently.

Key takeaway

Separating concerns early reduced complexity later. Each failure could be isolated to a single layer.


Weekend 2 (≈ 3 hours): API, identity, and real complexity

This is where the real engineering effort surfaced—not in writing code, but in making systems work together securely.

API layer

  • Created HTTP-triggered Azure Function
  • Designed JSON response structure
  • Mapped platform data into normalized output

Identity and access

  • Configured app registration in Entra ID
  • Implemented client credential flow
  • Scoped permissions using Sites.Selected

This portion consumed the majority of the time.

The API itself worked quickly. Identity and permissions required the real effort.

PnP PowerShell and site scoping

To enforce least privilege, access was granted using PnP PowerShell with certificate-based authentication. This ensured:

  • Access restricted to a single site
  • No tenant-wide exposure
  • Read-only behavior aligned to the use case

Challenges encountered

  • Permission mismatches causing API failures
  • Environment variable misconfigurations
  • Deployment/runtime inconsistencies

These were not code issues—they were configuration and identity boundaries surfacing in real time.


Weekend 3 (≈ 90 minutes): Turning backend into product

With the backend stable, the frontend came together rapidly.

Before

  • Working API returning JSON
  • Structured data available
  • No user visibility

After

  • Live dashboard rendering data
  • Interactive filtering and sorting
  • Real-time usability

Frontend capabilities

  • Summary cards for quick insights
  • Search across multiple fields
  • Filtering by category and source
  • Sorting across text, numeric, and date fields
  • Loading and error handling states

The transformation was immediate:

API endpoint → usable product
A stable backend removes uncertainty and enables rapid frontend development.

Development disciplines encountered

  • Data Modeling – schema design and normalization
  • Frontend Development – HTML, CSS, JavaScript rendering
  • Serverless API Design – functions, routing, JSON
  • Identity Engineering – app registration, permissions
  • Security Design – least privilege and scoping
  • DevOps – CI/CD pipelines and troubleshooting
  • Configuration Management – environment variables
  • UX Design – filtering, feedback, usability

None of these were planned as isolated efforts—they naturally surfaced as the system evolved.


The real takeaway

The code was the smallest part of the effort. Integration, identity, and configuration drove the complexity.
  • Infrastructure was quick to deploy
  • Security required deliberate thought
  • Integration revealed hidden dependencies

Final thought

Idea
 → Data
 → API
 → Product

In just a few focused sessions, this project evolved into a real, usable application. That is the power of modern cloud-native development: small efforts can produce meaningful outcomes when layered correctly.