How incoming messages find their record
Every incoming WhatsApp or SMS message arrives carrying just one clue about who sent it: the sender's phone number. REDA Connect turns that number into a record by walking your object configurations in a fixed, predictable order and filing the message against the first record whose phone field matches exactly. Understanding this walk is the key to answering "why did that message land on that record?" — and to designing priorities so it lands where your team expects.
The short version: configurations are tried in Priority Order (1 first); within each one the match is exact on the digits-only international number; the first configuration that finds a record wins and the search stops; if several records share the number, the one modified longest ago wins; if nothing matches anywhere, the message exists but sits on no record — unless you've set up auto-creation.
- This article assumes your configurations exist — see Configuring Contacts and Leads.
- The single biggest cause of match failures is phone formatting. Read How to enter phone numbers — numbers must be stored as the full international number, digits only, no
+, no spaces or separators.
The matching walk
When a message arrives on a Connect Account:
- Scope. REDA Connect gathers the active configurations belonging to that Connect Account for that channel. Inactive configurations, other accounts' configurations, and the other channel's configurations play no part.
- Order. The configurations are sorted by Priority Order — "1" is the highest priority and is tried first. (Configurations sharing the same priority number are ordered by name — but give each a distinct priority so you never rely on that.)
- Search. For each configuration in turn, REDA Connect looks for a record of that configuration's object whose Channel Identity Field field exactly equals the sender's number in digits-only international form. Exactly means exactly:
14155550123stored as+14155550123,(415) 555-0123, or415-555-0123does not match. - First match wins. The moment a configuration finds a record, the walk stops. Lower-priority configurations are never consulted for this message. The message is filed against the matched record (or, for related-record configurations, against the related person's record with the matched record as parent) and appears in its Connect Feed.
- Tie-break within a configuration. If more than one record of that object holds the same number, the record that was modified longest ago wins — the oldest-modified record, not the newest. This is easy to guess wrong, so plan around it: keep phone numbers unique per object, and treat duplicate numbers as data to clean up rather than something to rely on.
- No match anywhere. The message is still saved — you'll find it in the Connect Feed tab's global view and in the All Inbound Messages list view on messages — but it appears on no record's feed, and nobody is notified through a record. The exception: if one configuration is marked Is Default New Record, REDA Connect creates a brand-new record and files the message there — see Auto-creating records.
Worked example — three configurations, one number
Setup on one Connect Account, WhatsApp channel:
| Priority | Object | Phone field |
|---|---|---|
| 1 | Contact | MobilePhone |
| 2 | Lead | MobilePhone |
| 3 | Booking (custom, related-record setup via Tenant) | Tenant__r.MobilePhone |
Message arrives from 971501234567. The walk:
- Contact (priority 1): is there a Contact whose Mobile equals
971501234567? Two Contacts do — a duplicate. The one whose record was modified longest ago wins. Say that's "Dana Reyes (old import)". The message is filed on that Contact. The walk stops. The Lead with the same number at priority 2 is never even looked at.
Now suppose the duplicate Contact didn't exist and neither did any Contact with that number:
- Lead (priority 2): a Lead "D. Reyes" has Mobile =
971501234567→ message filed on the Lead. Stop.
And if there were no Contact and no Lead match:
- Booking (priority 3): a Booking whose Tenant's Mobile matches → the message is filed on the Tenant Contact with the Booking as parent (the related-record filing rule). Stop.
- Nothing matched at all: the message is saved with no record. If the Lead configuration had Is Default New Record ticked, a new Lead would be created instead and the message filed on it.
Designing your priorities
- Put the object your team works in first. Most orgs put Contact at 1 and Lead at 2 so that once a Lead is converted, conversations follow the Contact.
- Put related-record configurations above their plain counterpart if you want incoming replies to carry the context record as parent (e.g. Booking-via-Tenant above plain Contact means replies file with the Booking attached).
- Keep the list short. Every active configuration is one more search on every incoming message. A handful per account and channel is the right size.
- Keep numbers unique within an object. The oldest-modified tie-break will silently pick a record you may not expect. Duplicate management on Contacts/Leads pays off directly here.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Message arrived (visible in the global feed) but is on no record | No configuration matched — usually a phone-format mismatch on the record | Store the number digits-only international (formats); the next message from that sender will match. Consider auto-creation as a safety net |
| Message landed on the wrong object | A higher-priority configuration matched first | Reorder Priority Order values across your configurations |
| Message landed on the wrong record of the right object | Two records share the number; the oldest-modified one won | Merge or fix the duplicate records |
| Messages stopped matching after an admin edited a configuration | Configuration deactivated or object/field name typo introduced | Check Is Active and re-verify the API names |
| No message arrived at all | Delivery problem, not matching | An incoming message didn't arrive |
FAQ
No. The sender's number, in digits-only international form, matched exactly against the configured phone field — that's the entire mechanism. No fuzzy matching, no partial matching, no fallback on name or email.
Prevention beats repair: fix priorities or duplicates so the next message matches correctly. But the message already filed can be moved — it is a supported admin edit. Open the message record and edit its Record Id field (and Parent Record Id, if your setup uses it) to the 18-character Id of the correct record; the conversation view follows the new value. You need edit access to messages, and the Id must be copy-pasted carefully — Salesforce won't warn you about a wrong but valid Id.
No — they're saved and visible in the Connect Feed tab's global view and in the All Inbound Messages list view. They just don't appear on any record's feed, so make checking for them part of someone's routine, or set up auto-creation.
No. Matching only uses configurations belonging to the account that received the message, for the channel it arrived on.
Where to go next
- Auto-creating records from incoming messages — turn "no match" into a new Lead instead of an orphaned message.
- Assigning incoming messages to record owners — get the matched message in front of the right agent.
- How to enter phone numbers — the format rule that makes or breaks every match.