Zendesk's Salesforce Integration Now Expires After 30 Idle Days

From 9 November 2026, the connection between Zendesk and Salesforce expires if it goes 30 consecutive days without being used. Zendesk announced it on 6 November. If your agents look at Salesforce data in tickets every day, nothing changes for you. If your sync only runs at quarter-end, or only when something has already gone wrong, this one is for you.

What exactly changes

Zendesk's announcement describes the mechanism in two sentences:

"The Salesforce integration uses a secure token to keep Zendesk connected to your Salesforce org. From November 9, 2026, that token expires if the integration goes 30 consecutive days without being used. Each time the integration is used, the 30-day clock starts again."

The part that matters is what counts as "used". Zendesk lists three things:

Data sync between Zendesk and Salesforce runs
An agent opens Salesforce data in the ticket view
An agent uses the Salesforce sidebar app

Any one of them resets the clock. Zendesk is explicit that "only connections that sit idle for more than 30 days are affected."

This is Salesforce's rule, not Zendesk's

It would be easy to read this as Zendesk deciding to cut connections. That is not what happened. Zendesk's own explanation:

"Salesforce now requires apps that connect to its platform to expire unused access after 30 days of inactivity. Under this requirement, unused connections can't stay active indefinitely, which reduces the risk of unauthorized access to your Salesforce data."

So the requirement comes from Salesforce, the platform that holds the data, and Zendesk is complying with it. Expiring access nobody is using is a sensible security default: an old, forgotten token is exactly the kind of credential that turns up in an incident report. Any app that connects to Salesforce under the same requirement has to behave the same way.

Not the same as the Zendesk API-token deadlines

If you follow our Zendesk coverage, this will sound familiar, so it is worth being precise. In August we wrote about Zendesk retiring its own API tokens in favour of OAuth (what changes after 27 October 2026), and our migration calendar covers the phases of that change.

This is a different token on a different clock. The API-token deadlines are about how scripts and integrations authenticate to Zendesk. The 30-day timeout is about the token Zendesk holds for your Salesforce org, and it exists because of a Salesforce requirement. It does not move or add to any of the API-token dates.

Who this actually affects

Zendesk says it plainly: "For most customers, no action is required." A team whose agents open the Salesforce sidebar daily will never come near 30 idle days.

The teams to think about are the ones whose use is real but irregular:

Seasonal businesses whose Salesforce-linked workflows run hard for a few months and then go quiet.
Quarterly or annual syncs, such as account reviews or renewal checks that pull Salesforce data into tickets once a quarter.
Fallback and disaster-recovery setups, where the integration exists so that it works on the one day the primary process fails.
Sandboxes and secondary brands that someone connected once and has not touched since.

Our migration calendar described this kind of failure in August: "The failure mode is not a warning at renewal time; it is a script that worked in March failing silently in July." The same logic applies here. An integration you only test when you need it will work every time you test it during a busy month, and may have lapsed on the quiet month you finally need it.

If it stops working: the fix

Zendesk gives the recovery steps in the same announcement:

In Zendesk Admin Center, disconnect the Salesforce integration.
Reconnect it and sign in to Salesforce again.

And an important note, in their words: "Settings are saved following reconnection, you'll just need to re-enable the features you want to use." So a lapsed connection costs you a reconnect and a check of which features were on, not a rebuild. If reconnecting does not fix it, Zendesk asks you to contact its support team.

What to do this week

Find out whether you are in the irregular group. Ask who owns the Salesforce integration and how often it really runs, not how often it is supposed to.
Write down the feature list now. Since features must be re-enabled after a reconnect, record which ones are switched on today, while everything works.
Put the reconnect steps in your runbook, next to wherever your team looks when Salesforce data stops appearing in tickets.
Decide whether to keep it warm. For a fallback integration, a monthly reminder for an agent to open Salesforce data in a ticket counts as use under Zendesk's definition and resets the clock. The cost is that someone has to own that reminder.

The wider pattern

Expiring unused access is becoming a standard security practice across SaaS platforms, and it is a reasonable one. The practical consequence is that "set it up once and forget it" no longer describes an integration. Every connected app is now something with a clock, and the clocks belong to different vendors with different rules.

We build DeskLeap, a helpdesk with ticketing, live chat and a knowledge base, so we are not neutral about helpdesks. On this particular change, though, the honest advice is simple: if your team uses the Zendesk–Salesforce integration regularly, you need do nothing. If it runs only occasionally, spend ten minutes this week writing down its settings and the reconnect steps.

Source

All quotations are from Zendesk's announcement, read in full on 8 November 2026:

Announcing a 30-day inactivity timeout for the Salesforce integration (Zendesk Help Center, announced 6 November 2026, rollout 9 November 2026)

If Zendesk updates the announcement and we have missed it, tell us and we will correct this page.