If your customer data lives in Salesforce, the technical integration is well-trodden. What is different at this size is that you are not just building a feature — you are adding a communication channel to a system with an owner, a change process and a security review.
Three ways out
| Mechanism | Good for | Watch out for |
|---|---|---|
| Flow with an HTTP callout | Declarative, no code, visible to admins | Governor limits, and error handling is basic |
| Outbound message (workflow) | Reliable, retried by the platform | Fixed payload shape; you adapt on your side |
| Apex callout with a queueable | Full control, proper retries and logging | Needs a developer and test coverage |
For anything customer-facing that matters, the Apex route with a queueable job is the one that behaves properly under load. Flow is the right choice for a pilot precisely because an admin can see and change it without a deployment.
The security review is the real work
You are proposing to send customer data to a third party that reaches iMessage by means Apple has not sanctioned. That will come up, and it should. The evaluation that gets approved is the honest one — here is how to write it, including what a SOC 2 Type II report does and does not cover.
Answer the Apple question directly
Do not let it surface late. State it up front: Apple publishes no iMessage API, the provider operates outside Apple's terms, the failure mode is a channel that stops delivering, and here is the fallback. A reviewer who hears that from you trusts the rest of your assessment. A reviewer who discovers it themselves does not.
Data governance specifics
- Field-level security on the consent and phone fields, so they cannot be edited casually.
- A DPA with the provider, and clarity on where message content is stored and for how long.
- Message content retention — decide it deliberately. A provider holding customer conversations indefinitely is a liability you inherit.
- Audit trail of who sent what, which Salesforce gives you if you log the send as an activity.
- Sandbox first. Never test a messaging integration against production contact records.
Multi-org and multi-brand
Large Salesforce estates often mean several business units sharing customer records. That raises a question per-line pricing makes expensive: does each brand get its own number? And a harder one — if two business units both message the same customer, who is enforcing the frequency cap? Put that logic in your own service, not in each Flow. The multi-tenant version of this problem.
Enterprise checklist
- Security review completed with the Apple position stated up front.
- DPA signed; retention and residency documented.
- Consent field with field-level security and an owner.
- Central frequency cap across all business units.
- Sends logged as activities for audit.
- Sandbox-tested; no production contacts used in testing.
- A tested fallback channel if the line stops delivering.