Stephanie Dlatt

A third party vendor needed a Salesforce integration built for their platform. Their lead engineer was sharp and thorough, but new to Salesforce entirely, and I never had a login, an admin panel view, or any direct visibility into their system across the several months we worked together.

Most of the early work was knowledge transfer: what a permission set is and how it differs from a profile, why "the object is accessible" and "the field has a value" are two separate promises, why a system user needs API access enabled at the profile level before anything else works.

But the harder half of the work wasn't admin configuration. It was schema design: how an application record relates to its reviewers, its grades, and its comments, and which identifier survives if an email address changes but a record cannot. It was an API architecture decision hiding inside a volume question: records moved through synchronous calls capped at two hundred each, or through an asynchronous bulk job built for larger loads. And it was a packaging decision most admins never touch: which org owns a Salesforce package once it's created, and what breaks for every future client if that ownership is wrong from the start.

The permission set itself was scoped tight on purpose: full access on the objects that belonged to the vendor, since they were the source of truth for that data, and read only access on a short list of named fields everywhere else. Two versions of the same permission set were built, one for clients licensing the connector as a full platform user, one for the cheaper API only integration license, since those two license types quietly support different permissions.

I never tried to reconstruct their platform in my head. When the engineer described how a record connected to another, I took the description at face value and reasoned from what Salesforce needed to receive, not from a guess about what their database looked like. My side of the integration, I verified myself, directly. Their side, I trusted them to be the expert on, because they were.

A production integration that installs the same scoped, tested package for every future client the vendor signs, and a vendor engineer who went from no Salesforce experience to shipping schema changes independently. He thanked me for being direct about timelines instead of vague. I'd take that over almost any other compliment the project produced.

Several membership organizations needed on the order of a hundred thousand legacy member records remapped from an old system's IDs to new Salesforce IDs, against a billing run that does not move because the work isn't finished. On one of them, authentication kept drifting. More than one attempt to patch the configuration had already failed to hold.

Instead of patching the same configuration a fourth time, I rebuilt that organization's Salesforce-side authentication from scratch: a new connected app, fresh credentials, nothing inherited from whatever state it had drifted into. Because this was the first time a mass production sync had run at this volume, I flagged the risk of skipping staging validation to save time and argued for keeping it, even with the deadline pressing. Partway through, a platform constraint surfaced that nobody had hit before: the billing system would only accept one relationship or role per member per batch. I filed it as a permanent fix rather than letting it become a one-off workaround someone would have to remember next time.

The migration held, and every organization behind it in the queue moved forward on my sign-off rather than ahead of it. The work got unsolicited recognition from leadership above my own manager, which does not happen for a quiet fix. The batch constraint I filed outlived the project: every mass sync at that volume since has run into the same limit, so the fix is permanent instead of tribal knowledge.

Most of the integrations I own started as relationships I inherited: an existing vendor, an existing agreement, my job to make the technical side hold up. This one I helped build from the ground up. A fintech partner had a product that filled a real gap for our client base, and the question was whether to bring it in as a company-level partnership rather than a one-off connector for a single client.

The technical integration turned out to be maybe a third of the work. The rest was evaluating whether the partnership actually made sense: what the product did that we could not, what it would cost our clients against what it would save them, and what the revenue-share terms needed to look like for both sides to still want the relationship past the first renewal. Once the deal was struck, I wrote and circulated the internal rollout plan myself, because a partnership that lives only in a signed agreement and nobody's calendar is not actually live yet. I have since written vendor-vetting criteria for another organization's partner program too, since the questions that matter (how they handle authentication, what happens when their side fails, who owns the data in a dispute) are the same questions regardless of whose logo is on the letterhead.

The partnership became a standing option across our client base rather than a single deal, and I still maintain more than two dozen partner and integrator relationships built the same way. The measure I actually care about: a vendor whose product had a real bug once fixed it because we found it and told them plainly, not because we made it their problem in public. That is what a relationship built to last past the first renewal looks like from the other side of the table.

As an archives intern at the Indiana Historical Society, I processed the records of a community organization I had also worked for: more than a hundred years of material, from 1900 to 2013. It arrived as more than forty boxes of documents, photographs, albums, slides, negatives, and videotapes, with no structure anyone outside the organization could follow.

The work was arrangement, description, and preservation: sort the material into series, consolidate it, rehouse what needed protecting, and then write the collection guide that tells a researcher what is in the boxes, how it is organized, and where to find the one thing they came for.

The hardest part was identity. The organization went by four different names between 1910 and 1980, and later merged into another. A researcher searching under any one of those names still needed to land on all of it, so the guide had to carry the full history of who the organization had been, not just what it was called when the boxes arrived.

Once or twice a week I also staffed the reading room, pulling material for researchers, members, museum visitors, and people tracing the history of their own town, and showing them how to handle it without damaging it. Watching strangers use guides like mine was the clearest possible feedback on whether a description actually worked.

More than forty boxes consolidated to fewer than thirty, described in two published collection guides that are still the public entry point to the collection: the main collection guide and its addition, both completed in spring 2015. It is the same problem I solve in Salesforce today: many records, several names for the same entity, and a user eight months from now who needs to find the right one without knowing who built any of it.

As Support Operations Team Lead, I managed three CRM client success managers, half of whose work was direct client member support alongside me. I built the structure underneath that: documentation, templated responses, and a full client-facing resource center so organizations could troubleshoot their own single sign on and Salesforce member support issues instead of opening a ticket every time. The measure of a good support structure is not how fast my team answers. It is how many questions never need to reach us at all.

In my second year, before my team had any ticketing system to log this kind of work, I drafted the first written distinction we used between a vendor, an integrator, and a partner, because the three words were being used interchangeably and it kept causing avoidable confusion with clients. That same distinction is still how the team categorizes outside relationships today. Across those same pre-system years, I delivered somewhere around twenty distinct third-party integrations, one client organization at a time, invisible anywhere except scattered internal notes until I went looking for the record myself years later. Not long into that stretch, a partner organization spent an afternoon training me on how to write documentation for the very resource center I now own outright. The trainer and the trainee are the same job, just at different points, separated by enough time that people forget which one you used to be.

Nobody put an OAuth scope audit on my calendar. I did one anyway, on integrations that were already live, and found two partner connections carrying identity permissions they did not need plus a misconfigured callback URL, the kind of gap that is invisible until the day someone finds it before you do. Both got closed before that day arrived. The permission-scoping decisions in the case study above are not a one-time exercise. They are a habit I apply to integrations nobody asked me to look at.

During a stretch where the team was stacked past what was sustainable, I told people directly how many hours I had and what each commitment actually needed, instead of quietly absorbing the overflow. My manager told the group afterward that's the mindset they want the whole team to run on. I do not think leadership has to wait for a title. I think it is what gets noticed before the title catches up.

I proposed a hard cutoff for new scope introduced late in a project, after watching it repeatedly stall timelines that were not just mine. My manager did not just agree. They built it into how they described the problem to the rest of the team a few minutes later, unprompted, and named where the idea came from.

I built training material aimed at three different roles across the company, not mine, because I had noticed I was the bottleneck people had to track down whenever the same question came up. The measure of whether it worked will not be whether I answer fewer questions. It will be whether the questions stop needing me specifically.

I have spent months pushing a product team on a data-model gap that mostly shows up for whoever is holding the actual client relationship when it breaks. A teammate backed the same point independently, without us comparing notes first, which is how I knew it was not just a me problem.

Earlier in my career, as program staff at a nonprofit federation, I planned and ran events ranging from intimate gatherings of about a hundred people to large-scale fundraising and cultural events drawing up to 3,700 attendees. Part of the role was staffing a board of directors and several volunteer committees, including a philanthropy committee and a next-generation engagement committee I helped build from the ground up: real governance, real budgets, and real competing priorities, just running through volunteers instead of employees.