Great questions. These are exactly the challenges that arise when integrating Salesforce with AppSheet (or Google Sheets) in large-scale environments. Let's break both questions down:
1. Large Data Tables — Do All Solutions Have a 100k Row Limit Like Google Sheets?
Short answer: Not necessarily — it depends on the data source.
Google Sheets:
100,000 cell limit (not rows!) per worksheet, with other practical performance limitations starting around 10,000–50,000 rows, especially with formulas or images.
Not designed for enterprise-scale data.
Salesforce Connector (in AppSheet):
No explicit row limit mentioned in docs, but real-world performance degrades significantly as row count increases.
Most users report slow syncs, timeouts, or errors above 10–20k rows due to the Salesforce API throttling and pagination.
Better Alternatives:
Verdict:
If you’re scaling past 20k+ rows, Google Sheets is out, and even Salesforce’s direct connector might struggle. A SQL-based mirror or custom API bridge gives better long-term control.
2. What Happens with Conflicts — AppSheet vs. Salesforce Updates?
This is the classic data sync conflict problem. Here's what would happen:
In Your Scenario:
Salesforce connector (or synced Google Sheet) pulls data every 4 hours.
AppSheet users edit data in the meantime.
When the sync occurs, Salesforce data overwrites the stale data in the Sheet — erasing user changes.
No built-in conflict resolution exists in AppSheet for third-party source syncs like Salesforce.
Why This Happens:
AppSheet sees the Salesforce-connected Sheet as the “truth.”
Changes from Salesforce overwrite local values, even if they are more recent on AppSheet.
Solutions for Two-Way Read/Write:
Option A: Use a SQL Clone of Salesforce (via Mirror Tool or ETL)
Tools like Heroku Connect, Skyvia, or CData replicate Salesforce into a SQL database.
AppSheet connects to the SQL database.
You get real-time read/write performance with better conflict handling.
Salesforce still remains the system of record, but you have more control over sync timing and resolution logic.
Option B: Build a Custom API Layer (Middleware)
Create a small backend (Node.js, Firebase, or Make.com) to:
Handle real-time writes from AppSheet to Salesforce.
Listen for Salesforce webhook events (CDC) and push changes to AppSheet or SQL.
Allows true bi-directional sync with logic to manage conflicts.
Option C: Use AppSheet Webhooks to Trigger Salesforce API Writes
Not real-time, but immediate writes can be done.
You can create actions or automation bots in AppSheet that POST to Salesforce on record change.
Combine with a frequent pull (every hour) for data updates.
Conclusion / Recommendation
If you're serious about:
Writing back to Salesforce
Scaling beyond 10–20k rows
Maintaining conflict resolution and speed
Then:
Google Sheets is not viable long-term
Use a SQL mirror of Salesforce data or
Set up a custom API/middleware to mediate two-way sync and reduce delay-based overwrites.
LinkedIn
Twitter
