License changes are supposed to be the boring, cost-saving kind of Salesforce admin work. Move a system account to a cheaper, purpose-built license, free up a seat, done. Then the next scheduled backup job runs, and a chunk of objects that backed up fine last week suddenly fail — with no obvious change to the automation itself.
This happens more often than most admins expect, and it traces back to a specific interaction between Salesforce's Integration User license and the access requirements backup tools rely on. Here's what actually causes it and how to fix it without giving up the license savings entirely.
Salesforce's Integration User license is a lower-cost, API-only license built for system-to-system connections, restricted to a narrower profile and permission set than a standard user license. When you switch the account that runs your backup automation to this license type, some Salesforce objects the backup service needs to read may no longer be accessible, and those objects will start failing on the next backup run. Salesforce's own backup product documents this exact scenario as a known exception code. The fix is to identify which specific objects failed, determine whether they need a licensed permission set to restore access, and decide object by object whether the coverage is worth the added license cost. Vantage Point resolves these license-and-permission conflicts through its managed services and ongoing support.
Salesforce introduced the Integration User license (delivered through the Salesforce Integration API permission set license) as a purpose-built, lower-cost option for accounts that exist only to run system-to-system integrations — middleware, backup services, or other automation that authenticates as a dedicated account rather than a human user. It's restricted to the Salesforce API Only System Integrations profile, which is deliberately narrower than a standard Salesforce user license.
The appeal is straightforward: if an account only ever calls the API and never logs into the UI, paying for a full user license is unnecessary overhead. Moving that account to an Integration User license frees up license cost or count, which is exactly why teams make this change.
Backup services need read access to a broad range of objects — including Salesforce system objects most admins never think about, like Feed Items, Feed Comments, Flow Orchestration Logs, Decision Tables, and Announcements. Under a full standard-user license and profile, that access is often present without anyone configuring it explicitly. Under the narrower Integration User profile, several of those objects fall outside what the profile and its available permission sets can grant.
Salesforce's own backup product documentation confirms this is a recognized failure mode, not an edge case: its list of troubleshooting exception codes includes one specifically for "the integration user doesn't meet one or more of the required access conditions to back up all objects in the service." In other words, this is expected behavior given the license's design, not a bug — which means it will recur for any account moved the same way, on any Salesforce backup tool, not just one specific product.
After a license change, review the backup job's per-object results rather than only its overall pass/fail status. In a typical case, the large majority of objects — often 90% or more — continue backing up successfully, because most standard business objects remain within the Integration User profile's reach. The failures cluster around:
That distinction matters: some failures are genuinely low priority, and others are a configuration gap you can close without changing the license back.
| Situation | Recommended approach |
|---|---|
| Failed object is low-value/unused (Feed Items, Topics, etc.) | Document and accept the gap; revisit only if the object becomes relevant later |
| Failed object needs a custom permission set the Integration User can hold | Build and assign a scoped custom permission set covering just that access |
| Failed object requires a licensed permission set (e.g., Financial Services Cloud) | Weigh the added license cost against the original savings — it may not be worth it |
| Object access looks fine in profile and permission set review, but still fails | Escalate to the backup vendor; the tool's permission-analysis job may be evaluating a different condition than actual object access |
That last row is worth taking seriously. Some backup tools run an automated "analyze permissions" style check that can flag access as insufficient even when a manual review of the profile and permission set shows the access is actually present. Treat automated permission analysis as a signal to investigate, not a final verdict — and don't assign an unnecessary license just to satisfy a check that may itself be evaluating the wrong condition.
A common sequence plays out like this: an admin identifies that a backup automation's service account has been running on a full standard-user license for years, purely out of habit, even though it never logs into the UI. Moving it to an Integration User license is an easy, defensible cost-saving change, and it goes through without incident for weeks — until the next full-object backup run.
At that point, a handful of objects that previously backed up without issue start failing. A quick review shows the large majority of objects — often more than 90% of the total in scope — are still backing up correctly. The failures cluster in a predictable pattern: Salesforce system objects related to feeds, flow orchestration, and decision logic, plus any objects tied to a licensed add-on product the org uses.
At the same time, a related but separate issue often surfaces: other permission or access alerts for the same integration user, covering objects that seem like they should already be accessible. A careful review of the assigned permission set and profile can show the access appears correctly configured — which points toward the backup tool's own permission-analysis logic evaluating a different condition than actual API-level object access, rather than a genuine gap. Distinguishing between a real access gap and a false-positive check is a big part of resolving these incidents efficiently instead of over-provisioning license access defensively.
Vantage Point audits Salesforce license and permission changes before they go live, including their downstream effect on backup coverage, integration users, and system objects most admins don't think to check. Our managed services and ongoing support team resolves object-level access gaps after a license migration, and our Salesforce implementation and advisory services plan license changes so cost savings don't come with hidden coverage gaps. We are employee-owned, with 400+ engagements for 150+ clients, a 4.71/5.0 average engagement rating, and 95% client retention — senior consultants only, no junior handoffs; the experts you meet are the experts who deliver.
Vantage Point can audit the downstream impact before you switch, so your backup coverage and automations don't break silently. Talk to Vantage Point about your Salesforce license setup.
Moving the account that runs your backup automation to a Salesforce Integration User license restricts it to a narrower, API-only profile. Some objects your backup service previously accessed under a full user license may fall outside what that narrower profile and its permission sets can grant, causing those specific objects to fail on the next run.
It's a documented, expected behavior of the Integration User license's design, not a bug in any one product. Salesforce's own backup product lists a specific exception code for integration users that don't meet the access conditions needed to back up all objects, confirming this is a recognized interaction rather than an edge case.
Not necessarily. In most cases, the large majority of objects continue backing up successfully, and the failures cluster around low-priority system objects or objects that need a specific permission set. The license change is still worth it if the failed objects are low-value or fixable without an added license.
Often, yes. A scoped custom permission set assigned to the integration user can restore access to some failed objects. Objects gated behind a licensed permission set — such as certain Financial Services Cloud objects — may require that license regardless, which is worth weighing against the original savings.
Treat an automated permission-analysis flag as a signal to investigate manually rather than a final answer. Some tools evaluate a different condition than actual object access, so a manual review can show access is fine even when the automated check disagrees. Escalate to the vendor if the discrepancy persists.
Inventory every automation authenticating as that account, run a test against the new license and profile before touching production, and compare the full object-level backup result — not just pass/fail — against the previous run.