Click a node to navigate. Scroll to zoom. Drag to pan.
Loading graph...
Document Management
Four decisions define document management architecture: where files live, how they are generated, how knowledge is published, and how signatures are captured. Each requires balancing native platform simplicity against the richer capabilities of external document management systems.
Document Management Options
Figure 1. Document management architecture spans four independent decision areas. Each area has a native Salesforce option, a hybrid option, and a fully external option, and each is evaluated separately rather than as a single all-or-nothing platform choice.
A 500-user Enterprise org gets 10 GB + (500 x 2 GB) = ~1,010 GB of file storage. That sounds generous. But a document-heavy organization processing hundreds of files per day can consume terabytes within a few years. Always model file volume growth against 3-year projections.
External DMS Comparison
Factor
Salesforce Files
SharePoint
Box
Google Drive
Native integration
-
Medium (API + Lightning)
Strong (managed package)
Medium (API)
Version control
Basic
Advanced
Advanced
Advanced
Collaboration
Limited (Chatter)
Full (Office 365)
Full
Full (Google Workspace)
External sharing
Limited
Advanced
Advanced
Advanced
Advanced permissions
Salesforce sharing model
SharePoint permissions
Box permissions
Google permissions
Compliance (DLP, retention)
Shield
Microsoft Purview
Box Shield
Google Vault
OCR / AI
Limited
Microsoft AI
Box AI
Google AI
Cost
Included (within limits)
Microsoft 365 license
Box license
Google Workspace license
Offline access
Limited
OneDrive sync
Box Drive
Google Drive
When to Use External DMS
Signal
Why External DMS Wins
Heavy document collaboration
Multiple users editing documents simultaneously
Advanced version control
Branch merging, check-in/check-out workflows
Large file volumes
Terabytes of documents exceed Salesforce storage economics
Significant user base that never touches Salesforce
Advanced compliance
eDiscovery, DLP, information barriers, sensitivity labels
Document-centric workflows
The document is the primary work object, not a Salesforce record
When to Keep Files in Salesforce
Signal
Why Salesforce Files Wins
Record-centric attachment
Files are attachments to CRM records (proposals, contracts on Opportunities)
Simple requirements
Upload, view, download - no collaborative editing
Mobile access
Field users need files through Salesforce Mobile App
Security simplicity
File access should follow CRM sharing model exactly
Low volume
File volumes well within Salesforce storage limits
No external DMS exists
Customer does not have SharePoint, Box, or Google Workspace
Files Connect
Files Connect gives users access to external files (SharePoint, Google Drive, Box, OneDrive) from within Salesforce without migrating anything.
How Files Connect Works
Figure 2. Files Connect acts as a bridge between Salesforce and external document management systems. Files remain in their source system with no storage duplication, while Salesforce users can browse, search, and attach external file references directly to CRM records within their normal Salesforce workflow.
Aspect
Detail
File storage
Files remain in external system (not copied to Salesforce)
Access
Browse and search external files from within Salesforce
Linking
Attach external file references to Salesforce records
Authentication
OAuth-based, per-user or admin-configured
Search
External file content searchable through Salesforce global search
Editing
Open in native app (Word, Google Docs) - not edited in Salesforce
Files Connect as the bridge
Files Connect works best when a customer has an established external DMS and wants those documents visible in Salesforce without migration. No duplicate storage costs, the DMS collaboration features stay intact, and Salesforce users get visibility.
Files Connect Limitations
Files are not stored in Salesforce - if the external system is unavailable, files are inaccessible
Performance depends on external system responsiveness
Search indexing of external files may lag
Not all metadata from the external system is preserved in Salesforce views
Requires appropriate external system licenses in addition to Salesforce
Knowledge Management
Salesforce Knowledge
A built-in knowledge base for creating, managing, and publishing articles.
Feature
Detail
Article types
Multiple record types for different content categories
Lifecycle
Draft, Published, Archived with approval workflows
Hierarchical categorization and visibility control
Feedback
Article ratings, view counts, case association
Lightning Knowledge
Single article record type with multiple page layouts
Knowledge Article Lifecycle
Figure 3. Salesforce Knowledge article lifecycle showing version-controlled publishing. Editing a published article creates a new Draft version rather than modifying the live article directly, which preserves the published version until the update is approved. This is critical for service teams who rely on articles during case resolution.
Articles can be published to multiple channels simultaneously: Internal (agent-facing in Service Console), Customer (self-service portal via Experience Cloud (formerly Community Cloud)), and Partner (partner portal). Data categories control which articles are visible in each channel.
When Salesforce Knowledge Excels
Service agents need articles while working cases
Customer self-service portal with case deflection
Knowledge articles closely tied to products or services in Salesforce
Article visibility needs to follow Salesforce data category and sharing rules
Experience Cloud CMS
A headless CMS built into Experience Cloud for creating and managing content in digital experiences.
Document generation questions in CTA scenarios typically involve complex proposals, contracts, or compliance documents. If the scenario mentions “generate a 20-page proposal with dynamic sections based on selected products,” that points to a third-party solution like Conga. Native Salesforce document generation cannot handle that level of complexity.
E-Signature
Salesforce E-Signature
Native e-signature capabilities are now available directly in Salesforce.
Feature
Detail
Integration
Native within Salesforce
Workflow
Send for signature from records
Tracking
Status tracking on Salesforce records
Templates
Reusable signature templates
Mobile
Sign on mobile devices
DocuSign vs Adobe Sign
Factor
DocuSign
Adobe Sign
Salesforce integration
Managed package (deep)
Managed package (deep)
Market share
Largest
Second largest
Feature depth
Extensive
Extensive
Adobe ecosystem
No
Yes (Acrobat, Creative Cloud)
Pricing model
Per-envelope or per-user
Per-transaction or per-user
Bulk send
Yes
Yes
Conditional routing
Yes
Yes
Compliance
SOC 2, HIPAA, FedRAMP
SOC 2, HIPAA, FedRAMP
In-person signing
Yes
Yes
E-Signature Decision Factors
Factor
Native Salesforce
DocuSign / Adobe Sign
Volume
Low-medium
High volume, enterprise
Complexity
Simple signing workflows
Complex routing, conditional fields
Existing investment
No existing e-sig tool
Already using DocuSign or Adobe
Compliance
Basic
Advanced (21 CFR Part 11, eIDAS)
Integration depth
Native
Deep Salesforce integration + other systems
Cost
Included or add-on
Separate license
File Storage Optimization
Strategies to Reduce Salesforce File Storage
Strategy
How It Works
Savings
External DMS + Files Connect
Keep files external, reference in Salesforce
Major
Archival policy
Move old files to external storage
Moderate
Compression
Compress files before upload
Minor
Duplicate detection
Prevent duplicate file uploads
Minor-Moderate
Version cleanup
Limit retained versions
Minor
Content delivery network
Use Asset Files for public content
Indirect (offloads serving)
File Architecture Decision
Figure 4. File storage decision flow using three-year volume projection and collaborative editing as the primary decision gates. When volume stays within Salesforce limits and collaboration is not required, Salesforce Files is sufficient. Collaborative editing or volume overrun both route to an external DMS paired with Files Connect, with the specific DMS determined by the organization’s existing productivity tooling.