FCA × Tap to Donate: the user provisioning problem

Problem statement only — no solution proposed here. Based on the June 8, 2026 call (Wil, Liza, Brandon × Paul, Scott, Ray, Karly). All quotes verbatim from the transcript.
TL;DR

1 · How the problem surfaced on the call

Wil proposed the simple path — FCA hands over staff emails, we bulk-create app accounts:

"…you guys provide us with all the staff members' email addresses that you have, and we could go ahead and bulk provision Tap to Donate specialist accounts for every single one of them."
— Wil Pope (18:05)

Scott rejected the model immediately — not the app, the account management model:

"That was, like, the first question I wrote down… what's the sustainability of giving and taking away accounts? We're over 3,000 people now, and it's not uncommon for people to come on and off and then back on again. Even if we were to give you a one-time flat file… that's not sustainable for anybody. And that's why we have APIs to let the computers do the work."
— Scott Lee (18:48)
"Flat files are great for a one-time thing or maybe once a day, but for us, we're really gonna need an API level integration. So unless you guys have… an API behind this, then I say I'm a bit cautious with this."
— Scott Lee (20:24)

2 · The problem, decomposed

a) Scale and churn make manual administration impossible

3,000+ staff (6,000 employees total), and the population is not static: people join, leave, return, and move between local orgs. Every change would require someone to edit users in our Dashboard.

b) Access is many-to-many and changes over time

"Each staff person may represent more than one org or more than one campaign. And then there's also sometimes staff members move and they have to transfer orgs. So it's not as easy as… I'm one staff, I represent one campaign or one org. It's more confusing than that."
— Scott Lee (20:04)

So the data model of the problem isn't "user → campaign", it's "user → a changing set of campaigns across orgs". Any one-time assignment goes stale.

c) Offboarding is a security requirement, with real incidents behind it

"One of our initiatives is to improve our offboarding procedures so that we don't leave accounts out there… you get some rogue ex-employee who will do something nefarious."
— Scott Lee (19:48)
"We've had a number of scenarios in the last couple of years where staff have left, we didn't have SSO set up, and they were still soliciting donations from people… it kinda put us in a really tricky situation."
— Paul Anderson (21:11)

A donation-collecting app in the hands of an ex-employee is a reputational and financial risk for FCA. This is why "we'll clean up accounts eventually" is not acceptable to them.

d) Their target operating model: identity managed on their side

"That would be potentially the solution to this if all of our staff hit the app… and it just prompted them to log in with their Microsoft credentials."
— Paul Anderson (20:45)
"We're trying to get SSO deployed to everything, obviously just from a security standpoint."
— Paul Anderson (21:33)

FCA standardizes on Microsoft Entra ID (formerly Azure Active Directory): an employee exists (or doesn't) there, and every connected service should follow automatically. They expect Fundraise Up to behave like the rest of their stack.

e) Account overhead already cost us adoption once

"That was why we didn't give everyone access to their own campaigns — because of the overhead associated with managing all those accounts. …There's so many great features in the platform that the fundraisers can see and use… but they're not getting the benefit of that because of the SSO."
— Paul Anderson (22:02)

The same problem has already blocked Dashboard adoption by FCA fundraisers — Tap to Donate just makes it acute, because now 3,000 people need accounts instead of a back-office team.