Your SharePoint lists are map layers now. New

The utility already keeps its pole inspections, damage reports, vegetation work orders, and site surveys in SharePoint. The Microsoft Graph connector turns any list into a live spatial layer — FeatureLayer, dynamic vector tiles, or OGC API Features — and lets staff edit it in place, with every write attributed to the signed-in identity and gated by SharePoint's own item-level permissions.

Microsoft Entra IDAuth Code + PKCEMSAL.NET Microsoft GraphFeatureLayerDynamic vector tiles OGC API FeaturesDelta sync

List → layer

Connect once, serve three ways

Pick a site, pick a list, and the connector materializes it into a local DuckDB snapshot served at the same FeatureServer path every other connector uses. All three facades work: ArcGIS FeatureLayer, dynamic vector tiles, and OGC API Features — so the inspection list renders beside the feeders and structures it describes.

Guided connect dialog — paste your tenant and client IDs, sign in with Microsoft in your own browser, search for the site, pick the list. Geometry detection is automatic, with a manual override.
Full first pull, delta forever after — the initial sync walks every page (5,000 items per Graph page); subsequent refreshes use Graph's delta token and fetch only the rows that changed.
Refresh on demand — from the ConnectorsManager UI or POST /api/sharepoint/profiles/{id}/refresh, with ?full=true for a complete re-pull after a schema change.
Status at a glance — last sync time, row count, signed-in state, and last error from a single status endpoint.

graph.microsoft.com · localhost

// edits flow back through Microsoft Graph
POST   /sites/{site}/lists/{list}/items   → add row
PATCH  .../items/{id}                     → edit cell
DELETE .../items/{id}                     → delete marked

// served locally like any other layer
GET  /api/spatial/{profileId}/FeatureServer/{layerIndex}
POST /api/sharepoint/profiles/{id}/refresh?full=false
GET  /api/sharepoint/profiles/{id}/status

● signed in as operator@tenant · delta sync active

Geometry auto-detection

Five column shapes, detected for you

SharePoint lists store location five different ways. The connect dialog recognizes all of them — and you can override the detection when a column needs to be forced into a different mode.

📍

Latitude + Longitude

Two numeric columns become point geometry — the most common shape for field-collected inspection lists and form-driven data entry.

🌐

Native Geolocation

SharePoint's built-in Geolocation column type, flattened from its {Lat, Lon, Alt} structure into map-ready coordinates.

📝

WKT text column

POINT(...), POLYGON(...), and friends — full geometries, not just points, parsed straight from a text field. Right-of-way segments and work areas, not just pins.

🧩

GeoJSON text column

A GeoJSON geometry stored as text renders directly — handy for lists populated by other systems and integrations.

🏠

Free-text address

Address columns — customer sites, service locations — are geocoded through the in-app OpenAddresses/Nominatim geocoder, with results persisted to a secondary GeoPackage registered as its own SpatialSource.

🎛️

Manual override

Detection picked the wrong column? Override the shape and column in Step 5 of the connect dialog — for example, forcing Address mode on a Location column.

Edit-in-place

Edit on the map, land in SharePoint

The Attribute Table, in-map Editor widget, and FeatureTable widget all hit the FeatureServer edit verbs, which detect the SharePoint-backed dataset and delegate every add, update, and delete to Microsoft Graph. Close out an inspection record or log storm damage from the map, and after each write the affected row refreshes in the local snapshot — no full re-pull.

Adds, updates, deletes — Graph POST, PATCH, and DELETE against the list's items endpoint; per-field edits are batched per row.
Native Geolocation writes, handled — Graph can't reliably write Geolocation columns, so the write path transparently falls back to the SharePoint REST API with the SP.FieldGeolocationValue shape, using the same bearer token. Routing is decided per-write.
Attributed edits — the signed-in user's userPrincipalName appears in SharePoint's item history. No service-account smudging on inspection and work records.
Permissions follow the user — item-level permissions are respected end to end: if someone can't see an item in SharePoint, they can't see it on the map either.

Entra ID · delegated auth

// one-time tenant setup — no client secret, ever
flow       Auth Code + PKCE (MSAL.NET, browser sign-in)
redirect   SPA → http://localhost
scopes     Sites.ReadWrite.All · User.Read (delegated)

token      DPAPI-encrypted (CurrentUser scope)
writes     attributed to signed-in operator
perms      SharePoint item-level ACLs enforced

● consent granted · 429s handled by Polly backoff

Security model

Delegated identity, encrypted at rest

Built on Microsoft Entra ID delegated authentication — the signed-in user's identity, not an app secret, is the credential for everything. The governance posture utility IT already audits.

🔐

No client secret on disk

The Auth Code + PKCE flow replaces the secret with a one-time code. Sign-in happens in the user's own browser; nothing secret is needed beyond their session.

🗄️

DPAPI at rest

The MSAL refresh token — the only long-lived credential — is DPAPI-encrypted to the Windows user account. Copying the profiles file to another machine or user grants nothing.

✍️

First writable connector

Every other external database connector is READ_ONLY at the DuckDB ATTACH boundary. SharePoint is the first where writes leave the local perimeter — by design, gated on the user consenting Sites.ReadWrite.All.

One-time Entra ID app registration per tenant (shareable across users); an admin grants consent once. Delta tokens expire after ~30 days — the snapshot then transparently rebuilds. MSAL's cached sign-in uses a 90-day sliding window before an interactive re-sign-in is requested.