How to build a scalable architecture for document management on Salesforce & AWS

The Problem

Legal teams hit a breaking point with Salesforce document storage when costs balloon, performance lags, and reliability falters. What should be a simple workflow becomes an expensive headache:

• Costs: At $5+/GB/month, storing PDFs in Salesforce blows up your budget fast.
• Performance: Case loading times suffer when every file drags on Salesforce compute.
• Reliability: Bulk uploads from big cases push you past org limits overnight.
  

You typically face 3 options:

1. Buy more Salesforce storage: Fast but expensive.
2. Offload to S3 without integration: Cheap but painful for users.
3. Install an off-the-shelf DMS: Adds a silo that doesn’t fit your intake or litigation flow.
   

If you’re running high-volume, document-heavy intake on Salesforce, none of these work. You need an approach that fits your workflows and your budget.

That’s where a composable storage architecture comes in:

• Deep Salesforce integration for users
• Low-cost cloud storage behind the scenes
• Reliable, scalable workflows built for legal teams
  

For the full problem breakdown, see The Hidden Legal Document Crisis: A CTO’s Guide to Salesforce Storage Costs. This playbook shows you how 👇.

The Built-for-Purpose Architecture

This business challenge can be tackled with a pragmatic custom solution that does not require a highly-skilled team to maintain. The mantra of this approach is to build solutions that last, while upskilling your current team.

Below is a recommended reference architecture implemented across various customers in the legal sector.

Architectural Components

‍Salesforce

• Stores metadata about documents (e.g., name, type, associated record)
• Exposes custom LWC/Visualforce components or flows to upload/download documents
  

Amazon S3

• Stores actual document files
• Configured with private access only
• Versioning and lifecycle policies enabled for retention and cleanup
  

AWS Lambda

• Generates presigned URLs (short-lived, secure links to upload/download from S3)
• Enforces access controls via custom logic
• Invoked by Salesforce via HTTPS (API Gateway)
  

AWS IAM

• Roles and policies strictly scoped to allow Lambda access to specific S3 prefixes (e.g., /org-id/user-id/file-id)

Amazon API Gateway

• Exposes REST API to Salesforce for:
  • Upload URL generation
  • Download URL generation
  • Delete operation (optional)
    

Workflow

Uploading a Document

1. User initiates upload from Salesforce UI.
2. Salesforce makes a call to POST /generate-upload-url (API Gateway).
3. Lambda:
   • Validates request (e.g., user identity, associated record)
   • Constructs the S3 object key with tenant-safe hierarchy
   • Generates a short-lived presigned URL using the s3:PutObject action
4. Salesforce uses this URL to directly upload the file to S3 via HTTP PUT.
5. Salesforce updates the record with the S3 object metadata.

Downloading a Document

1. User clicks “Download” in Salesforce.
2. Salesforce calls GET /generate-download-url?fileId=…
3. Lambda:
   • Validates access
   • Generates a presigned URL for s3:GetObject
4. Salesforce redirects the user to that URL or opens the file in a new tab.

Deleting a Document

1. Salesforce calls DELETE /delete-file?fileId=…
2. Lambda checks permissions and deletes the object in S3.

Security Considerations

• Authentication & Authorization
  
  • Lambda validates that the authenticated Salesforce user has permission to access the requested file.
  • Presigned URLs are time-limited (e.g., 5 minutes) and single-use.
  • Object keys follow a hierarchical path structure to isolate tenants/users (e.g., orgId/userId/documentId.pdf).
• Bucket Configuration
  
  • Block public access to bucket and objects
  • Enable bucket policies to enforce only access via presigned URLs
  • Use Server-Side Encryption (SSE-S3 or SSE-KMS) for file encryption at rest
  • Enable logging and object-level access audit (via CloudTrail and S3 Access Logs)‍
• Presigned URLs
  
  • Do not expose raw bucket/object names to the front end
  • Sign URLs server-side only
  • Keep URLs short-lived and tied to strict permissions (per record, user, etc.)
  • Optionally log URL generation and usage events for traceability

Salesforce Considerations

• Metadata Model: Create a custom object like Document__c. Add fields like S3_Key__c, Parent_Record__c, and Uploaded_By__c.
• ‍Upload UX: Use LWC to trigger upload, get presigned URL, and PUT the file to S3.‍
• Apex Integration: Call Lambda/API Gateway using HttpRequest and Named Credentials for secure callouts.

The Metrics That Prove ROI

These are the results we've seen at Perfected Claims.

Financial Impact:

• Storage cost reduction: $10,000/month → $400/month
• Emergency upgrade costs: Eliminated
• Payback period: 8 months
• ROI: 80% over 12 months
• IRR: 70.5% annualized
  

Operational Impact:

• Case load times: 8 seconds → 1.2 seconds
• Document upload speed: 45 seconds → 6 seconds
• Custom Features: Built for your intake, not forced into someone else’s template.

Technical Impact:

• System performance restored to optimal levels
• System capacity: 2.3TB limit → Unlimited
• API limits no longer block innovation

Struggling with a similar problem? 

We can help. Book a call and we'll get straight to discussing:

• What makes your document workflows unique?
• Which integrations matter most?
• What custom features would give your firm an edge?
• How do we future-proof your architecture for your next stage of growth?