Auth and Token Management Isn't an Integration

When a customer team says they need to "integrate with Salesforce," that sentence can mean a dozen different things. It could mean storing an OAuth token so the product can pull contact records. It could mean syncing opportunity data on a schedule. It could mean creating a new case inside Salesforce when a customer flags an issue in your product, with the right custom fields populated, the right record type selected, and the right automation triggered downstream.

All of these get called "integration." The word does a lot of work while communicating very little.

Integrations are table stakes now

Buyers stopped being impressed by integration counts a while ago. A product page listing 200+ integrations tells a buyer almost nothing about what those integrations actually do. The question moved from "do you connect to my tools?" to "what can your product do inside my tools?"

In competitive evaluations, nobody gets credit for having an integration. That's assumed. What separates winners from losers is whether the integration can read custom objects, write data back to the source system, respect field-level permissions, and hold up under real production load with real customer configurations.

If you sell to teams that run their business in Salesforce, HubSpot, or Workday, your integration logo gets you into the conversation. It does not get you through the evaluation. Buyers will open the integration, point it at their actual org, and see what happens. Can it handle their custom fields? Does it write back correctly? Does it break when it hits a validation rule nobody documented?

What people used to mean by "integration"

For most of the SaaS era, "integration" meant something fairly narrow. You authenticated a user's account via OAuth, stored a refresh token, and periodically pulled data from their system into yours. Maybe you displayed that data in an embedded view. Maybe you synced it into a warehouse. In the most impressive examples, you could do a CRUD operation in one app that would percolate into the connected system.

These integrations weren't trivial to build. Engineers had to implement token refresh logic, pagination handling, schema mapping, retries, and sync scheduling. Teams built entire internal services around credential management and data pipelines.

But the outcome was fundamentally about access. The product could see data from another system. The connected system was a data source. The integration was plumbing that moved data from point A to point B.

Why that definition stopped holding up

AI changed what software is supposed to do. Not gradually. The shift from "show the user information" to "do the work for the user" happened fast, and it raised the bar for every system connected to the product.

When your product can reason about a user's request and pull context from multiple sources, a read-only Salesforce connection feels broken. Users don't want to see the data and then go finish the job themselves. They expect the software to finish it.

Salesforce made the expectation explicit. The Agentforce architecture defines three requirements for agents to get work done: data, reasoning, and actions. A product that authenticates with Salesforce and reads data has satisfied one of those three. The other two are where the actual product value lives.

Access is not capability

Storing OAuth tokens and syncing records is infrastructure. Necessary infrastructure, absolutely. Without authentication, nothing else works.

But infrastructure is not the user-facing outcome. Consider a recruiting product that integrates with an HRIS. If the integration can read employee records but cannot create an onboarding task, update a hire status, or write to a custom field that triggers downstream workflows, the user still has to leave your product to do the actual work. The integration saved a copy-paste step. It did not change the workflow.

A product that reads from Salesforce is referencing another system. A product that creates, updates, and manages records in Salesforce, with the right field mappings, object types, and operational constraints, is operating inside that system. That difference determines how much of the user's job the product can actually absorb.

An integration should let your product operate inside another product

The bar for a production-grade integration is that your product can do meaningful work in the connected system. Not display data from it. Not link out to it. Do work in it.

If your product manages sales workflows, "integrating with Salesforce" should mean your product can create opportunities, update custom fields, associate records correctly, and handle the object model that the customer's Salesforce admin has configured.

Writing data back to an external system is a fundamentally different engineering problem than reading from one. It requires understanding the target system's object model, field validation rules, required fields, rate limits, error handling, and retry behavior. A write that succeeds in a default Salesforce org may fail in a customer's org because they added a required custom field or changed a record type's page layout.

This operational depth is where most "integrations" fall short. The auth works. The read works. But the product cannot reliably operate inside the other system because it was never built to understand that system's specifics.

The last generation of integration tooling got this wrong

Most integration tooling in the last decade optimized for the connection, not the capability. Get the token. Sync the object. Show a green checkmark on the integrations page.

That was fine when the product experience stopped at "here's your data from Salesforce." It is not fine when users expect your product to create records, trigger workflows, and operate with full awareness of the customer's specific configuration. The tooling was designed around auth and read access. Write support, custom object handling, field-level validation, and system-specific behavior were afterthoughts, if they existed at all.

What users expect from integrations now

Two expectations have converged, both driven by how AI products have reshaped what "good software" feels like.

Users expect your app to do what they could do themselves in the other system

If a user can create a deal in HubSpot, update a case in Salesforce, or modify a compensation record in Workday, they expect your product to do those things too. The integration raised an implicit promise: these systems are connected. The user's expectation follows logically: if they're connected, the product should be able to act, not just observe.

This expectation accelerates as more products adopt AI-driven interfaces. When a user asks an AI assistant to "update the opportunity stage and add a note about the pricing discussion," they aren't thinking about which system holds that record. They expect the software to figure it out and execute. Salesforce's Agentforce 2.0 announcement reinforced this, noting that organizations have "a low tolerance for inadequate solutions that provide generic responses" and that existing copilots "cannot take action on their own."

The tolerance for "we show you the data, you go do the work" is gone.

Users expect software to combine context and execute across systems

Users expect software to pull context from one system, combine it with data from another, apply reasoning, and take action in the right place. A sales product that reads from both a CRM and a conversation intelligence tool should be able to update the CRM record based on what happened in the call, without the user manually bridging the two.

When the interface layer of software moves from forms and buttons to intent and execution, every integration that stops at auth and token storage becomes a dead end. The software has permission to enter the building but no idea which rooms exist or what it can do inside them.

Why unified APIs fall short here

Unified APIs emerged as a reasonable response to a real problem: building and maintaining dozens of individual integrations is expensive. Instead of building a Salesforce integration, a HubSpot integration, and a Pipedrive integration, you build one integration against a common CRM model and the unified API handles the mapping.

The tradeoff is structural, and it's a bad one for where the market is going.

Treating every CRM, HRIS, or ERP the same removes the details that make integrations useful

A common model works by reducing each system to a shared set of fields and objects. That reduction is what makes the abstraction possible. It's also what removes the details that matter in production.

Salesforce has custom objects, record types, validation rules, and workflows that vary by org. HubSpot has its own property model, association types, and pipeline configurations. Workday has tenant-specific configurations and business process definitions. A unified "Contact" or "Deal" object can capture the intersection of these systems, but the intersection is the least interesting part.

The useful parts of an integration live in the specifics: the custom field a customer added to track deal source, the record type that determines which automation fires, the association between a contact and a custom object that only exists in that customer's instance. A common model flattens these into a generic shape or drops them entirely.

For read-only sync use cases, unified APIs can work well enough. The moment your product needs to write data, create records with the right type, populate custom fields, or trigger system-specific behavior, the abstraction breaks down. And that moment arrives fast when your product is expected to do real work.

What modern integration architecture needs to do instead

If auth and token management are the foundation, and data access is the first floor, modern integration architecture needs to build several more stories.

A product integration needs to support reads and writes against the real object model of each connected system, including custom objects and fields. It needs to handle the operational realities of each API: rate limits, pagination schemes, error codes, retry strategies, and async processing.

Ampersand's approach shows what this depth looks like concretely. Write actions in Ampersand support creating, updating, and deleting records in a customer's SaaS instance, including custom objects, inherited field mappings, batching, and async operations. Ampersand handles API idiosyncrasies, rate limits, error handling, and retries for each connected system rather than abstracting them away. Integrations are declarative, composable, and version-controllable, so the integration definition can evolve as the target system changes or as customers configure their instances differently.

Agents need to understand the specifics of each system they can use

The more your product relies on AI reasoning and agentic workflows, the more your integration layer needs to encode system-specific knowledge. An agent that can "create a Salesforce opportunity" in the abstract is less useful than one that knows this customer's Salesforce org uses a custom record type, requires a specific field for deal source, and triggers an approval workflow when the amount exceeds a threshold.

Generic awareness of a CRM category is not enough. The agent needs to understand what objects exist in the specific instance, what fields are required, what values are valid, and what side effects a write operation will produce. Without that knowledge, the agent either fails at execution time or produces results the user has to clean up manually. Neither outcome is acceptable when the whole point of the agent is to save the user work.

Takeaway

Most products that claim to "integrate with Salesforce" have stored a token and can read some records. That is not an integration. That is a connected account.

An integration means your product can operate inside another system. It can create records, update fields, respect validation rules, handle custom objects, and trigger the right downstream behavior. It can do what the user would do if they opened that system themselves.

The market is moving fast toward software that combines context from multiple systems, reasons about what to do, and executes. Products that stop at auth and synced data will lose to products that can actually finish the job. Buyers will not give you credit for a green checkmark on your integrations page. They will test whether your product can do real work in their systems, with their configurations, under their constraints.

Auth grants access. Integration enables work. The products that confuse the two will keep losing deals to the ones that don't.