The most common Salesforce implementation challenges are low user adoption and dirty data. Heavy customization, disconnected systems and three releases a year follow close behind. For a SaaS company, those last three decide whether your integration works. Every customer org is its own implementation. Its validation rules, duplicate rules, automation and API traffic all apply to every record your product writes.
This page is for founders, CTOs and product leaders who ship the native Salesforce integration or managed package their enterprise customers asked for. You build the integration, a customer installs it, and their implementation choices start running against every record you write. A sync that passes in your test org fails in the org with a required field you never saw. If you are rolling out Salesforce for your own sales team instead, a Salesforce implementation partner is the better guide for that project. Appnigma's done-for-you integrations service exists for the vendor side of this: "Build your product. We'll build the integrations," with a named integration engineer and ongoing maintenance per customer connection.
Updated October 2026. Checked against Salesforce's Apex Developer Guide, API limits documentation and second-generation packaging guide (Winter '27, API version 68.0). This update replaces the earlier generic list of ten implementation tips. It removes failure statistics that have no primary source and corrects the CRM market share to the figure Salesforce publishes. It also corrects the status of Workflow Rules and Salesforce Optimizer, and adds what each customer implementation choice does to a vendor's integration.
Which customer implementation choices reach your integration
Most implementation advice is about people and process, and none of that touches your code. Five kinds of customer choices do, because Salesforce enforces them on every record an API call or a package writes.
| Customer implementation choice | What it does to your integration | What to build |
|---|---|---|
| Validation rules and required fields added after go-live | Inserts and updates from your sync fail with field errors | Per-record error handling that names the field and the rule |
| Duplicate rules set to block | Records you create are rejected as duplicates | Upsert on an external ID, and a matching step before insert |
| Restricted picklists and record types | Values your product sends are refused | Read picklist values from describe calls, never hardcode them |
| Other integrations sharing the org's API allocation | Your calls run out when someone else's job spikes | Change events instead of polling, and a usage check before bulk work |
| Locked-down profiles, sharing and field-level security | Your integration user can't see or edit what it needs | A documented permission set and an install check |
Every row comes from a customer org you can't see. That is why the hardest Salesforce integration challenges show up after install, in the customer with the most customization, which is usually your largest account.
What runs when your integration saves a record
Salesforce runs the customer's logic on your records in a fixed order, documented in Triggers and Order of Execution. For a record that arrives through the API, Salesforce first checks foreign keys, field formats and lengths, and restricted picklist values. Then it runs before-save flows and before triggers, and after that it checks that required fields have values and "runs any custom validation rules." Duplicate rules come next. If a matching duplicate rule "uses the block action, the record isn't saved."
Legacy automation still runs too. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, but existing rules keep firing, and the Winter '27 order of execution still lists the step "Executes workflow rules." A field update from a ten-year-old workflow rule can overwrite the value your sync just wrote.
Two details trip up most vendor teams. A value outside a restricted picklist fails with INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST, which the core data types page defines as "an invalid or null value for a restricted picklist." And the duplicate rule header doesn't override a block. In SOAP, the DuplicateRuleHeader allowSave property lets you "bypass alerts and save duplicate records," and alerts are all it bypasses. REST has the same control through the Sforce-Duplicate-Rule-Header.
What this means for the product is simple to state and hard to build. Treat every write as one that can fail for a reason the customer created. Return the field, the rule and the record to the customer's admin in words they can act on. A generic "sync failed" status becomes your support ticket. Appnigma's integration infrastructure page names the same problem from the vendor side, where each new customer's "custom objects, field mappings, and workflows need to fit without rebuilding the integration for everyone."
How much API capacity one customer org gives your integration
The daily API allocation belongs to the customer's org, not to you. Salesforce enforces the limit against all API calls to the org in a 24-hour period. The API Request Limits and Allocations page adds that limits are "not on a per-user basis." Its own example is an Enterprise Edition org with 15 Salesforce licenses. That org gets "115,000 requests (100,000 plus 15 licenses x 1,000 calls)."
A worked example from those documented numbers shows how quickly that goes. Say your product polls five objects every five minutes. That is 288 polls per object per day, or 1,440 queries before a single record moves. Now say a customer changes 20,000 records a day and your sync writes each one with a single-record call. Those two jobs together use 21,440 requests, about 19% of the 115,000. The customer's marketing automation, data warehouse connector and CPQ tool draw from the same pool, and when the pool runs out, every integration in the org stops until the 24-hour window moves on.
Two more limits matter for vendors. Production orgs allow 25 concurrent requests that run for 20 seconds or longer, and over that the API returns REQUEST_LIMIT_EXCEEDED. And Salesforce's data replication guidance says that "to get real-time notifications of Salesforce record changes, use Change Data Capture instead" of polling. Subscribing to change events instead of polling removes most of that 1,440, and it scales with change volume instead of with your schedule. Our Salesforce API rate limits guide covers the other limits a sync runs into.
How customer customizations hit a managed package
A managed package, the versioned bundle a customer installs from AppExchange, runs inside the customer's implementation, so it inherits every choice above. Salesforce's Resolve Apex Test Failures page says it directly: "If a subscriber creates a validation rule, required field, or trigger on an object referenced by your package, your test might fail." Tests that insert a bare Account with only a Name pass in your packaging org and fail at install in a customer org with three required fields. Our AppExchange development challenges post covers the packaging side in more depth.
Governor limits are shared with the customer's code too. A certified managed package, one that has passed AppExchange security review, gets its own count for most per-transaction limits. The Execution Governors and Limits page lists exceptions such as "the limit on maximum CPU time," which is shared across all namespaces. So a customer's slow trigger on Opportunity spends CPU time your package needs in the same transaction. And "Namespaces in non-certified packages don't have their own separate governor limits," which means an unreviewed package shares everything.
Access rules changed in 2026 as well. "In API version 67.0 and later, Apex runs in user context by default," per Set an Access Mode for Database Operations. Code that relied on system context will see only what the running user's profile and sharing allow, and that differs in every customer org. Use explicit WITH USER_MODE or AccessLevel.USER_MODE, since Salesforce's secure coding guide says "WITH SECURITY_ENFORCED isn't allowed in AppExchange packages."
Customers can also change parts of what you ship. Salesforce marks some properties as editable after install, and the editable properties page says this "prevents a package upgrade from overwriting changes made by the subscriber." Your next version lands on top of the customer's edits, not over them, so don't assume an upgrade resets a page layout or a list view.
Release cycles and API versions to plan for
Salesforce ships a major release "three times a year," per the scratch org release page. Sandboxes get each release first. The 2GP release targeting page lists the Spring '27 preview as January 10 to February 20, 2027, and Summer '27 as May 9 to June 12, 2027. Those windows are when customers' sandboxes run a release their production orgs don't have yet, so test your package and API calls against a preview sandbox in each one.
For pushing your own upgrades, Salesforce's push upgrade best practices set "a higher bar to ensure the new version of your app works well in all customer configurations." They also say to "wait 3-4 weeks after a major Salesforce release before you push major upgrades."
API versions retire on a schedule, and integrations built years ago are the ones that break. Per the SOAP API End-of-Life Policy, versions 21.0 to 30.0 were retired in Summer '25, and calls to them return 500:UNSUPPORTED_API_VERSION. The API End-of-Life Policy lists versions 31.0 to 40.0 as "Deprecated and unsupported from Summer '27. Retired from Summer '28." Salesforce supports each version "for a minimum of 3 years from the date of first release," so a hardcoded version string in your client is a dated failure, not a hidden one. Search your code for it now.
New integrations also authenticate differently. "Connected apps creation is restricted as of Spring '26," per External Client Apps and Connected Apps, so a new customer-facing integration starts from an External Client App.
Do half of Salesforce implementations really fail?
No primary source supports that. Figures such as "49% of CRM projects fail" and "55% of CRM implementations fail" circulate without a report anyone can open, and an earlier version of this post repeated them. We removed them. Salesforce's own published number is about the market, not about failure. Its June 2026 announcement says IDC ranked it first, and that "in 2025, Salesforce led all CRM vendors with a 20.0% market share," per Salesforce News.
For a SaaS company, the more useful question is narrower. How many of your customers' implementations contain something your integration doesn't handle? Required fields, blocking duplicate rules and shared API pools are documented platform behavior, so you can test for every one of them before a customer finds it.
Mistakes that turn a customer's implementation into your support ticket
These are the patterns we see most often when a vendor integration meets real customer orgs.
- Testing only in a clean org. Seed your test org with a required custom field, a validation rule, a blocking duplicate rule and a restricted picklist on every object you write.
- Hardcoding picklist values and record type IDs. Record type IDs differ in every org. Read both from describe calls at runtime.
- Polling on a timer. It spends the customer's shared allocation even when nothing changed. Use Change Data Capture where it fits.
- Running as a full admin user. Salesforce offers a Salesforce Integration user license that grants "full org access while limiting them to API-only operations," per Supported Editions and Required Permissions. Pair it with a permission set you ship and document.
- Reporting "sync failed" with no detail. The customer's admin can fix a validation rule quickly once they know which rule fired on which record.
- Recommending Salesforce Optimizer. It was retired in Winter '26, and Salesforce's admin blog points admins to Org Check instead. Update any onboarding guide that still names it.
Frequently Asked Questions
What are the most common Salesforce implementation challenges?
User adoption, data quality, over-customization, disconnected systems and release management. For a SaaS vendor, customization and API usage matter most, because they decide whether your integration's writes succeed in a customer org.
Why does an integration work in one Salesforce org and fail in another?
Each org runs its own validation rules, required fields, duplicate rules and automation on every API save. A record that saves in a clean org can be rejected in a customized one.
How many API calls can my integration make in a customer's org?
The customer's whole org shares one 24-hour allocation. An Enterprise Edition org with 15 licenses gets 115,000 requests, split across every integration it runs.
Can Appnigma build and maintain our Salesforce integration?
Yes. Appnigma's done-for-you service builds customer-facing integrations for SaaS companies, with a named integration engineer and ongoing maintenance. If you need a native app and listing instead, see marketplace apps.
About the author
Sunny Chauhan is the co-founder and CEO of Appnigma AI, which builds and maintains customer integrations and native Salesforce and HubSpot apps for B2B SaaS teams. Before Appnigma, he was on Salesforce's AppExchange team, where he worked with more than 300 SaaS partners. He has spent close to a decade on the Salesforce platform, including work at Zennify, and holds Salesforce certifications including Platform Developer II, Platform App Builder, Administrator, Data Cloud Consultant, and AI Associate.
Related Articles
- Governor Limits for Certified Managed Packages
- Salesforce Managed Package Guide, 1GP vs 2GP
- External Client Apps in Salesforce
- Salesforce Integration Patterns and Best Practices
- Challenges in AppExchange App Development
- Will a Managed Package Help or Hurt a Salesforce Org?
- Platform Events vs Change Data Capture
- How to Build a Salesforce Native App
Sources
- Salesforce Developers, Apex Developer Guide, Triggers and Order of Execution
- Salesforce Developers, SOAP API, Core Data Types Used in API Calls
- Salesforce Developers, SOAP API, DuplicateRuleHeader
- Salesforce Developers, REST API, Duplicate Rule Header
- Salesforce Developers, Limits Quick Reference, API Request Limits and Allocations
- Salesforce Developers, API Guidelines, Data Replication
- Salesforce Developers, Second-Generation Packaging, Resolve Apex Test Failures
- Salesforce Developers, Apex Developer Guide, Execution Governors and Limits
- Salesforce Developers, Apex Developer Guide, Set an Access Mode for Database Operations
- Salesforce Developers, Secure Coding Guide, Protect Your Application from CRUD/FLS Vulnerabilities
- Salesforce Developers, Second-Generation Packaging, Editable Properties After Package Promotion or Installation
- Salesforce Developers, Salesforce DX, Select the Salesforce Release for a Scratch Org
- Salesforce Developers, Second-Generation Packaging, Target a Specific Release During Salesforce Release Transitions
- Salesforce Developers, Second-Generation Packaging, Push Upgrade Best Practices
- Salesforce Developers, SOAP API, SOAP API End-of-Life Policy
- Salesforce Developers, Tooling API, API End-of-Life Policy
- Salesforce Developers, Mobile SDK, External Client Apps and Connected Apps
- Salesforce Developers, REST API, Supported Editions and Required Permissions
- Salesforce News, IDC CRM market share ranking 2026
- Salesforce Admins, Optimizer Is Sunsetting, Learn How To Use Org Check
- Salesforce Help, Salesforce Workflow Rules and Process Builder End of Support
