We design and implement the broker layer that gates every file open with real SSO and per-record authorization, so nobody ever hands out a reusable link again.
Azure Files supports identity-based auth for SMB mounts, and OAuth-over-REST for tools like AzCopy — but nothing that maps one Salesforce user to one file, enforced the moment they click a link.
A raw file link just returns an auth error. Browsers can't attach the headers Azure's REST API requires — there's no page to redirect to, no prompt to answer.
Works, but it's one shared secret standing in for every user. No per-person audit trail, no revocation without breaking everyone, and a real credential if it leaks.
Grants admin-level access that bypasses directory and file ACLs, unless you've separately built out SMB-based identity ACLs most orgs never touch.
Real per-user RBAC — but only for domain-joined machines mounting a network drive. Irrelevant to anyone clicking a link from inside Salesforce.
The user's browser only ever talks to a small authorization service. It holds its own credential to Azure Files, checks who's asking and what they're allowed to see, then streams the file back — or it doesn't.
We implement this directly inside your Azure subscription and Salesforce org — nothing shared, nothing multi-tenant. Once it's live, we stay on to run and maintain it for a monthly fee.
We map your Salesforce object model to your Files layout, confirm your Entra tenant and SSO setup, and settle the authorization rule.
We stand up the broker Function, wire Easy Auth, provision managed identity access, and build the authorization logic — plus staging before production.
We go live, then stay on as the ones watching, patching, and evolving the broker — billed as a flat monthly fee on top of the build.
This is a narrow, technical engagement. It's a strong fit for some teams and the wrong tool for others.
Three engagement sizes, based on how many file types and authorization rules you need. Each tier includes the initial build plus a flat monthly fee for us to keep running it — patching, monitoring, and adjusting the authorization rules as your org changes.
One Salesforce object type maps to one file location, with a single authorization rule (e.g. "owner or their manager").
Multiple Salesforce object types, each with its own file location and authorization logic — the shape most real orgs actually need.
Your Azure Files share sits behind a private endpoint with no public access — the broker needs its own VNet integration to reach it.
Migration is scoped and quoted during discovery, based on how much data needs to move.