From Governor-Limit Failures to Reliable Large-File Uploads — One Chunked Architecture.
An enterprise Salesforce client needed to move large files directly from Salesforce records into structured Google Drive folders — but Apex heap limits, Base64 ceiling errors, and Visualforce restrictions made uploads fail beyond ~16 MB. Twopir designed and built a resumable chunked upload architecture in Salesforce that eliminated failures, extended upload capacity to handle files far beyond platform limits, and automated Google Drive folder creation — all without touching Salesforce storage.
Six Governor-Limit Problems That Blocked Every Large Upload — and Six Fixes That Resolved Them
Five Phases That Took the Client From Governor-Limit Failures to Zero Upload Errors
Mapped Every Governor Limit Before Writing a Line of Code
We started by documenting the exact failure points — synchronous heap at 6 MB, Base64 string ceiling at 12,000,000 characters, Visualforce at ~16 MB, and the callout limits affecting chunked API calls. Understanding the full constraint map before implementation meant we could design an architecture that stayed inside every boundary.
Replaced Visualforce with Lightning Web Components to Remove the Upload Ceiling
We rebuilt the upload interface as a Lightning Web Component — eliminating the Visualforce 16 MB upload restriction and giving users a clean, modern file-selection UI directly inside Salesforce records. The LWC handles file chunking at the browser layer before handing off to Apex.
Built the ~2 MB Chunk Pipeline with Async Apex and Resumable Session Handling
We implemented Queueable Apex to process each ~2 MB chunk asynchronously — staying inside both heap and callout limits. Each job initiates or continues a Google Drive Resumable Upload session, POSTing the chunk to the session URL and triggering the next Queueable job until the full file is assembled on Drive.
Created Lynx Content Map Object to Solve the Validation Rule Conflict
Storing the Google Folder ID directly on the Opportunity record triggered validation rules we couldn't modify. We created a custom object — Lynx Content Map — that stores the Salesforce record ID alongside its Google Folder ID, allowing the mapping to be reused across any object without touching existing validation logic.
Wired Google Drive Folder Creation to Salesforce Record Names — Zero Manual Steps
We built the folder-creation logic so that when a user uploads from a Salesforce record, the system automatically creates a correctly named Google Drive folder (based on the record name), stores the folder ID in Lynx Content Map, and uploads the file directly into that folder. Salesforce users never leave their record to manage Drive.
The original upload kept failing on anything over 10 MB — every large file was a risk. After Twopir rebuilt the architecture, we stopped thinking about upload limits entirely. The chunked approach just works, and the automated Drive folder creation saves the team from a lot of manual organising.
— Twopir Project Lead · Enterprise Salesforce Client · 2024What Changed — In Numbers and in Practice
Upload failures eliminated for large files
The chunked resumable architecture removed the recurring upload crashes that previously affected every file above ~5–10 MB, giving users complete confidence in the upload process.
Precision chunk size stays inside every Apex governor limit
Each chunk is processed asynchronously, Base64-encoded without hitting string limits, and uploaded to Google Drive's resumable session URL — sequenced correctly every time.
Visualforce fully replaced with Lightning Web Components
The legacy Visualforce upload page — which imposed a hard ~16 MB ceiling — was replaced with a modern LWC interface that handles file chunking at the browser level before Apex ever sees the data.
Lynx Content Map cleanly handles all Salesforce-to-Drive mappings
A single custom object now stores Salesforce record IDs alongside their Google Folder IDs — reusable across any object, conflict-free, and extensible as the client adds more record types.
Google Drive folders created and named from Salesforce record data automatically
Users trigger an upload from inside a Salesforce record; the system creates the Drive folder, names it from the record, stores the mapping, and uploads the file — with no manual folder management required.
Queueable Apex architecture is scalable and non-blocking
Because uploads run as chained Queueable jobs, the Salesforce UI never locks — users can continue working in the record while the file uploads in the background, chunk by chunk, until complete.
Running into Salesforce Governor Limits on File Uploads or Storage?
We'll audit your current upload architecture — identifying every limit you're hitting, every failure risk, and the fastest path to a reliable, scalable integration. Free audit. Findings delivered in 5 business days. No commitment required. We cover US EST, UK GMT, and AEST time zones.
The Tools and Techniques Behind This Engagement
Related Case Studies
Salesforce Integrations That Actually Stay Inside the Limits — Delivered by Engineers Who've Seen Every Failure Mode.
Twopir has spent 12+ years solving the integration problems that standard Salesforce documentation doesn't warn you about — governor limits, async architecture, API session handling, and the custom data models needed to make it all stick. With 500+ clients across the US, UK, Australia, UAE, and Canada, we've built the patterns that scale.
12+ Years · 500+ Clients · Salesforce Gold Partner · HubSpot Gold Partner · US · UK · Australia · UAE · Canada
