Skip to content

Blog / Architecture and integration

Integration authentication: why syncs stop

A customer's connection expires on a Saturday and the sync stops without a word. Why customer integrations fail at sign-in and after it, and what to fix first.

A customer connects their Salesforce account on a Thursday. The approval screen shows a vendor name they don’t recognize, so they untick two permissions to be safe. The integration saves. It syncs contacts and fails on opportunities, because it can’t read them. Three months later, the admin who connected it leaves and their user is deactivated. The connection stops working that Saturday. The customer finds out on Monday, from a report.

Before an embedded integration can run, the customer has to connect their own account in the other app. Many setups stall at that step, and many working integrations stop there later.

What is integration authentication?

Integration authentication is how a customer gives your product access to their own accounts in other apps, usually by signing in through OAuth inside your product. The sign-in carries your brand. The access granted is checked against what the integration needs. The credentials are held for that customer only. And every connection is watched, so a broken one is caught before the next sync fails.

Why customer syncs stop at sign-in

  1. The sign-in shows someone else’s name. A customer asked to authorize an app they’ve never heard of hesitates, and some stop.
  2. Partial permissions pass. The customer unticks a permission, sign-in still succeeds, and the integration half works.
  3. The connection belongs to one person. It’s tied to the admin who set it up. When they leave or change their password, it stops.
  4. Expiry sends no error. A revoked or expired token fails at the next run, which may be days later.
  5. Fixing it takes a ticket. The customer emails support, support asks engineering, and someone sends instructions to reconnect.
  6. Your staff can read the credentials. Tokens stored where engineers can see them are a risk your customers’ security reviews will ask about.

What it costs

A setup that stalls at sign-in is an integration the customer paid for and never uses. A connection that breaks without warning is worse. The customer keeps trusting data that stopped updating, and finds out at the worst moment.

Each broken connection also becomes a support ticket for something the customer could have fixed in one click.

What to fix first

  1. Put the sign-in under your brand. Register your own OAuth app with each service and run the sign-in on your own domain, so the approval screen names your product.
  2. Check the access straight after sign-in. Make a call that proves the integration can do its job, and tell the customer which permission is missing if it can’t.
  3. Suggest a service account. Recommend that customers connect with an integration user, not a person who may leave.
  4. Hold credentials against the customer. Store them for that customer’s instance only, reuse them if the customer connects a second integration to the same account, and keep them unreadable by your staff.
  5. Check every connection on a schedule. Warn the customer before a sync fails.
  6. Put the fix in your product. Add a reconnect button to the warning, so the customer fixes it in a minute instead of a ticket.

The guide to letting customers connect their own accounts has the prompts for each step.

Where it fits

Field mapping reads from the connected account, so a missing permission usually shows up there first, as fields the customer can’t see. Expired connections are among the easiest failures for customers to fix themselves, which is why integration error alerts send them to the customer instead of to your team.

For the full life of an embedded integration, from choosing what to build to tracking who uses it, see the beginner’s guide to embedded integrations.