Skip to main content
A hands-on walkthrough that takes you from an installed package to a verified round-trip iMessage in under ten minutes. Run this in a sandbox or Developer Edition Org first.

​
What You’ll Do

  • Send an outbound iMessage from a Lead record using the chertConversation Lightning component.
  • Confirm the send wrote a Chert_Message__c row with the correct Direction__c and Chert_Message_Id__c.
  • Receive a reply on the recipient device and watch it appear on the same record.

​
Before You Begin

Outbound calls leave Salesforce and hit the live Chert messaging service. The send is real. Use a phone number you control as the recipient.

​
Step 1: Open a Test Lead

1

Open any Lead record

From the App Launcher, open Sales, click Leads, and pick a Lead. If your sandbox is empty, click New and create one named Tutorial Lead with a recipient mobile number you control.
2

Confirm MobilePhone is set in E.164 format

The component reads Lead.MobilePhone. Set it to the recipient’s number in E.164 format — for example, +14155551234. If MobilePhone is empty, paste the number into the field and save.
3

Locate the Chert Conversation pane

Scroll the right rail. The Chert Conversation Lightning component appears with an empty thread and a message composer at the bottom. If it’s missing, the Lead Record Page is not active for your profile — see Configuration.

​
Step 2: Send Your First Message

1

Type a short test message

Use something obvious so you can spot it on the recipient device, e.g. Tutorial test from Salesforce.
2

Click Send

The component disables the composer for the duration of the callout. On success, the message renders in the conversation thread with a timestamp and an outbound chevron.
3

Inspect the response

chertConversation calls ChertSendIMessage under the hood. The invocable returns messageId and duplicate. The message ID is persisted to Chert_Message__c.Chert_Message_Id__c on the row inserted in the next step.
If Send returns an error, open Setup → Apex Jobs and the Debug Logs for your user. Most first-send failures trace to a missing or stale Signing_Secret__c value.

​
Step 3: Verify in Salesforce

1

Open the Chert Messages related list

From the Lead record, scroll to the Chert Messages related list. A new Chert_Message__c row appears.
2

Confirm the field values

Click into the row. You should see:
3

Cross-reference Setup Audit Trail

Optional but recommended in a regulated Org. From Setup, enter Setup Audit Trail. The send is not itself an audited Setup event, but Permission Set assignments and metadata changes from install are visible here.

​
Step 4: Receive a Reply

1

Reply from the recipient device

On the iMessage thread on your phone or Mac, send a short reply back to the Chert phone line — for example, got it.
2

Wait for the inbound POST

Chert posts the reply to your Org’s ChertInboundRest resource. Delivery is typically under five seconds.
3

Refresh the Lead record

The conversation pane updates on next load. The Chert Messages related list shows a new row with Direction__c = inbound and Text__c matching what the recipient sent.
4

Confirm the dedup behavior

If the same inbound message replays (Chert retries on 5xx), the second POST is detected by Chert_Message_Id__c uniqueness and is treated as a no-op. No duplicate row.

​
Verify Yourself

Answer these to confirm you’ve internalized the round-trip. The answers are linked into the reference docs.
  1. Which Apex action does chertConversation invoke to send a message? (Configuration)
  2. Which custom object stores the per-message audit row, and what field captures the Chert-side message ID? (Architecture)
  3. Where is the HMAC signing secret stored, and which Apex class reads it at send time? (Security)
  4. What’s the dedup window for an idempotencyKey, and what duplicate value should Flow logic treat as success? (Limits and Considerations)
  5. Which Permission Set must a user hold to send through ChertSendIMessage, and what object grants does it carry? (Configuration)

​
Next

Architecture

Component map and the synchronous-versus-asynchronous call graph.

Security

Trust boundary, HMAC signature format, and inbound verification.

Limits and Considerations

Governor math, edition fit, and platform-feature compatibility.