MMS and File Sharing in Salesforce SMS: Images, PDFs, and Attachments
A picture can clarify damage, a PDF can provide approved instructions, and an inbound attachment can give a service team the evidence needed to move work forward. Adding media to Salesforce SMS, however, is not as simple as putting a file beside a text. The organization must determine whether the destination can receive MMS, whether that particular file should travel as an attachment, and how the resulting message and file remain connected to the correct Salesforce record.
A dependable file-sharing workflow treats every media send as a governed business event. It identifies the exact file version and recipient, validates format and content, chooses MMS or a secure link, rechecks consent and current record state, handles delivery outcomes, and routes inbound media without guessing. This article shows how to build that operating model for SMS and MMS in Salesforce.
Important: carrier, provider, country, sender, device, file-type, size, privacy, and industry rules vary. Treat the examples as implementation guidance, not legal or carrier advice. Validate the exact production route and have the appropriate compliance, privacy, security, records, accessibility, and business owners approve every use case.
Start with the Business Purpose, Not the Upload Button
First classify why a file is being exchanged. Common examples include a product image, appointment map, event pass, approved instruction sheet, service photo, signed form, invoice copy, or visual proof. The purpose determines which record owns the exchange, who may send it, whether the recipient is eligible, what information is acceptable, and whether direct MMS is appropriate.
For each approved use case, define a media event contract in Salesforce:
- Context: the Case, Contact, Lead, Opportunity, order, appointment, claim, or custom record that authorizes the exchange.
- Recipient: the verified person, normalized mobile number, consent purpose, language, timezone, and sender route.
- File: the exact Salesforce file and version, checksum, type, size, classification, owner, and approval status.
- Decision: direct MMS, authenticated link, ordinary SMS without media, or a blocked request requiring review.
- Evidence: eligibility result, content version, provider identifiers, delivery events, reply, file association, exception, and resolution.
This model prevents a user interface choice from silently becoming a policy decision. It also lets one controlled send service support one-to-one messaging, Salesforce Flow, and approved bulk use cases without changing the rules between entry points.
Choose MMS or a Secure Link at Send Time
Direct MMS is useful when the recipient benefits from seeing a small, low-sensitivity image or supported file in the conversation. A secure link is usually better when the content is sensitive, large, frequently revised, time-limited, or dependent on authenticated access. The right choice can also vary by sender, carrier, country, file type, and device.
Make the decision from live configuration instead of a global assumption. The send service should inspect the destination, provider capability, approved file types and sizes, business classification, access requirements, and fallback policy. If the route is unsupported, do not relabel a failed attachment as a successful SMS. Create the approved fallback or an actionable exception.
A link should use an organization-controlled domain, avoid confidential values in the URL, expire according to policy, and resolve only to the authorized file version. Record when it was created, delivered, opened if permitted, expired, revoked, or replaced. A public URL is not a secure fallback merely because it is short.
Practical rule: use MMS for a safe visual that belongs in the conversation; use an authenticated, revocable link when the document needs access control, reliable versioning, or a stronger audit trail.
Lock the Exact Salesforce File Version Before Sending
Salesforce Files can contain multiple versions, and a record can have several similarly named documents. A delayed Flow or queue should never select “the newest PDF” at delivery time. Between approval and send, a user could upload a revision, rename a file, move a relationship, or change the underlying business record.
Create an immutable media request when the business event is approved. Store the ContentDocument and exact ContentVersion identifiers or their equivalent, file checksum, original filename, detected type, size, classification, intended recipient, record, purpose, template version, and approving context. Recompute or revalidate the checksum immediately before delivery. Block the request if the file, recipient, ownership, consent, or business state no longer matches.
Keep the authoritative Salesforce file separate from the transport copy created for delivery. If a provider needs a temporary fetch URL or staged copy, apply least-privilege access, encryption, short expiration, cleanup, and logging. Preserve enough evidence to show which approved version was sent without creating uncontrolled duplicates.
Validate Media Before It Reaches the Messaging Provider
Do not trust a filename extension or browser-declared content type. Inspect the actual file signature, verify allowed formats, enforce the configured size limit, scan for malicious content, and reject password-protected or active content when the approved process cannot inspect it. Images may also require dimension, color-mode, animation, or metadata checks.
Apply a file policy for each use case rather than one permissive list. A marketing image and an inbound service document have different risks. Consider whether to remove unnecessary metadata, normalize orientation, generate a safe derivative, preserve the original under restricted access, or require manual review. Log the policy version and validation result with the media request.
A conversion is a new file version. Record the source, transformation, output checksum, and tool result; then verify that the output still communicates the intended information. Never change a legal, financial, medical, identity, or signed document merely to make it fit MMS without a separately approved process.
Design Images and PDFs for Real Phones
An image that looks clear on a desktop can become unreadable after carrier processing or on a small screen. Favor simple compositions, large essential text, strong contrast, correct orientation, and enough padding around important content. Avoid putting the only call to action, disclaimer, account detail, or accessibility-critical information inside an image.
PDF behavior is not uniform across routes and devices. Some recipients may see a preview, a download, a link, or a failure. Test representative production destinations before approving PDFs for direct MMS. When predictable access matters, send concise SMS context plus an authenticated web destination that can present an accessible document and clear support path.
Keep the accompanying text useful on its own: identify the approved sender, explain why the media was sent, state the safe next step, and provide a reply or support option. Do not include unnecessary personal or record details merely to compensate for uncertain media presentation.
Recheck Consent, Content, and Record State Before Delivery
MMS is still business texting. Recheck the recipient, messaging purpose, consent or other approved basis, suppression state, sender, timing window, content classification, file approval, and current business event immediately before every send or retry. A person who is eligible for a service update is not automatically eligible for promotional media.
Define cancellation conditions when the media request is created. Stop a queued send if the recipient opts out, the number changes, the Case closes, an appointment is canceled, an order is withdrawn, the file is superseded, the document is revoked, or the owner marks the content inaccurate. A retry must repeat the same checks instead of assuming the original decision remains valid.
Use an idempotency key built from the business event, recipient, media request, and approved version. This prevents duplicate automation events and provider callbacks from producing repeated attachments or multiple Salesforce history records.
Associate Inbound Images and Attachments Without Guessing
An inbound photo or document must be connected to the right sender, conversation, and business record. A phone number alone may match multiple Contacts, be shared by a household, or have been reassigned. Use the sender, messaging number, active conversation, recent outbound context, reply window, expected document task, and any approved verification signal to establish the match.
Preserve the original provider message ID, media URL metadata, receive time, sender, destination, reported type, and transfer result. Retrieve media through an authenticated integration, validate it before broad user access, and store it according to the approved Salesforce Files structure. Link it to the message, conversation, person, and relevant business record with explicit relationships.
If identity or context is ambiguous, do not attach the file to the first matching record and do not reveal record details in an automatic response. Place it in a restricted exception queue. Give the reviewer the possible matches, expected task, validation state, and safe next actions while protecting the file from unrelated users.
Make Failures and Fallbacks Visible in Salesforce
Separate transport success from business success. A provider may accept a message even though a carrier later rejects the media, the device cannot present it, or the recipient never completes the linked action. Track queued, validated, blocked, sent, delivered, failed, replied, downloaded or accessed where permitted, handed off, canceled, and resolved states.
Classify failures so automation can respond safely. Temporary provider problems may justify a bounded retry. Unsupported media, oversized files, invalid destinations, expired links, failed scans, missing permissions, stale versions, and ambiguous inbound matches require different actions. Every exception should identify the record, owner, reason, evidence, and recommended next step.
Do not automatically fall back from a private document to a public link, or from MMS to a different recipient number. Fallbacks need their own approval, eligibility check, content, expiry, and audit record. When no safe fallback exists, create visible employee work instead of hiding the failure.
Control Access, Retention, and Reporting
Files often carry more sensitive information than the accompanying text. Apply Salesforce permissions, sharing, encryption, retention, deletion, legal hold, export, and monitoring rules to the original file, transport artifacts, previews, and inbound copies. Review integration users and temporary URLs so access does not extend beyond what the workflow needs.
Useful reporting connects media delivery to the business outcome. Track requests blocked before sending, MMS versus link decisions, validation failures, delivery by route and media type, stale versions prevented, inbound files awaiting association, employee response time, document-task completion, and unresolved exceptions. Segment results by use case rather than combining unrelated media into one success rate.
Review exceptions and samples regularly. Delivery behavior, provider configuration, file policies, and Salesforce permissions can change. A controlled pilot with a narrow file type and use case will reveal more than a large launch built on assumed compatibility.
Salesforce MMS Implementation Checklist
- Approve each media purpose, audience, file classification, sender, timing rule, and fallback.
- Map the exact Salesforce record, recipient, consent purpose, conversation, and owner.
- Define a live capability matrix for country, sender, provider, carrier, device, type, and size.
- Choose direct MMS or an authenticated link from current policy and destination support.
- Lock the exact Salesforce file version and checksum in an immutable media request.
- Validate signature, type, size, malware result, metadata, and any approved transformation.
- Recheck consent, suppression, business state, file approval, and stop conditions before sends and retries.
- Retrieve and associate inbound media through authenticated, validated, explicit record matching.
- Route unsupported media, unsafe files, ambiguous matches, and delivery failures to owned exceptions.
- Test representative production routes and launch one bounded, measurable use case first.
Frequently Asked Questions
What is the difference between SMS and MMS in Salesforce?
SMS is primarily text, while MMS can carry supported media. Salesforce should select the channel from the exact file, destination, provider capability, policy, and fallback rules.
Can Salesforce send PDFs through MMS?
Some routes and devices may accept PDFs, but support varies. Test the exact production path and use an authenticated link when reliable access, security, revocation, or version control matters.
Should an image or PDF be attached directly or sent as a link?
Attach a safe, supported, final file when it belongs in the conversation. Use a secure link for sensitive, large, changing, revocable, or access-controlled content.
How should inbound MMS attachments be stored in Salesforce?
Preserve message identifiers, validate the file, store it under approved Salesforce Files rules, and explicitly link it to the matched conversation and business record.
How can Salesforce prevent the wrong attachment from being sent?
Lock the exact file version, checksum, recipient, record, purpose, and approval in an immutable request, then revalidate them immediately before delivery.
What should be tested before launching Salesforce MMS?
Test real route combinations, formats, size edges, unsafe files, stale versions, opt-outs, fallbacks, inbound matching, duplicate callbacks, permissions, retention, and exceptions.
Connect MMS and Salesforce Files to the Same Business Context
Media messaging becomes useful when the image, PDF, reply, and employee action remain attached to the Salesforce work that created them. WatBox can help teams bring two-way SMS and MMS into Salesforce so users can share approved media and see conversation evidence alongside the records they serve.
Start with one low-sensitivity image workflow or one controlled document-link use case. Make destination capability, exact file version, validation, eligibility, current-state checks, inbound association, fallback, ownership, and reporting testable before expanding to more file types or audiences.
