How to enter phone numbers
There is exactly one phone number format that works everywhere in REDA Connect: the full international number, digits only — country code first, then the number, with no +, no spaces, no dashes, no brackets. Remove a national trunk prefix only where that country’s international format requires it; retain significant zeros. For a US number that reads +1 (415) 555-0123 on a business card, you store 14155550123. For an Indian mobile 88888 88888, you store 918888888888. This rule is not a style preference — numbers stored any other way cause two concrete failures, described below. This is the single most common cause of "it worked in the demo but not with our real data".
The package's own field help states the format for the account numbers: "The number must be provided in the following format: \<Country ISD Code\>\<Number\>. The number must not contain any special characters and spaces. For example, for United States (ISD Code is 1) if the number is 2223334444, provide 12223334444." The same convention applies to every phone value REDA Connect touches.
Where the rule applies
- The account's own numbers — WhatsApp Number and SMS From Number on every Connect Account.
- Phone fields on your records — whichever field each object configuration names as the phone field for a channel (MobilePhone on Contact, Phone on Lead, any custom field). These are the values incoming messages are matched against.
- The recipient number on individual messages (the To Number field), for messages created by automations or integrations.
Why: the two failures
1. A stored + breaks SMS sending outright. When sending an SMS, REDA Connect adds the + itself — to both the recipient's number and the account's SMS From Number. If the stored value already begins with +, the provider receives a number starting ++ and rejects the send: the message ends with Status Failed and the provider's error in its Error Message field.
2. Matching of incoming messages is exact. When a customer messages you, WhatsApp and Twilio identify the sender as the full international number in digits (Twilio's leading + is removed before matching). REDA Connect then looks for a record whose configured phone field equals that value character for character. There is no cleanup on either side — no stripping of spaces, dashes, or brackets, no "ends-with" matching, no fuzzy search. A record whose phone is stored as +1 (415) 555-0123 is simply not found when 14155550123 messages in: the message still arrives, but with no link to the record — it appears only in the global feed, unattached, and none of the record-based automation runs. How matching picks records is covered in Matching incoming messages to records.
Worked example — eight ways to store one number
The customer's number is US +1 415 555-0123. Here is what happens for each way an org might have stored it:
| # | Stored value | Works? | Why |
|---|---|---|---|
| 1 | 14155550123 | Yes — everywhere | Full international number, digits only. Sends succeed and incoming messages match |
| 2 | +14155550123 | No | The + breaks SMS sending (the system adds its own +, producing ++1…), and an incoming 14155550123 never matches this value |
| 3 | +1 (415) 555-0123 | No | +, spaces, brackets, and dashes — fails sending on SMS and never matches incoming messages |
| 4 | 1-415-555-0123 | No | Dashes make it a different string from 14155550123 — no match |
| 5 | 1 415 555 0123 | No | Spaces — same problem, no match |
| 6 | 4155550123 | No | Country code missing. Incoming messages always carry the country code, so 14155550123 ≠ 4155550123 |
| 7 | (415) 555-0123 | No | National formatting and no country code |
| 8 | 04155550123 | No | National leading zero. Providers never send the number this way |
Row 1 is the only one that works in both directions on both channels. Some malformed values may appear to work in one narrow case — which makes the failure harder to spot later. Store every number as row 1 and none of these cases can bite.
Adopt a convention — and clean up once
Because matching is exact, consistency org-wide matters more than any individual entry:
- Write the convention down for everyone who enters data: country code + number, digits only — and include it in onboarding for sales and support teams.
- Fix the sources: web-to-lead forms, imports, and integrations that write phone fields should store digits only. A
+added by an upstream system will quietly reintroduce the problem. - Run a one-time cleanup pass on the phone fields your object configurations use. Build a list view or report filtered on the phone field, look for values containing
+, spaces, dashes, or brackets, and correct them (mass-update tools help for volume). Do this before go-live: a mismatched number doesn't error — it just silently fails to match.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Every SMS from one account fails immediately with a provider error about the number | The account's SMS From Number (or the recipient's stored number) starts with + | Remove the + and all separators; resend |
| Incoming messages arrive but aren't linked to the right Contact/Lead/record | The record's phone field is formatted differently from the digits-only number the provider sends | Reformat the record's phone value to <country code><number>, digits only |
| Messages match for some customers but not others | Inconsistent formatting across records — only the digits-only ones match | Run the cleanup pass above on the configured phone field |
| A number that works on WhatsApp fails on SMS | Only the digits-only format works on both channels; some malformed values fail on one channel first | Store the number digits-only and it behaves identically on both |
FAQ
Providers use + notation on the wire, but REDA Connect manages that itself — it adds the + where the provider needs one and removes it from what the provider sends. Your stored values must always be the digits-only form.
Yes — WhatsApp Number and SMS From Number follow exactly the same format, and a + in SMS From Number breaks every SMS the account sends.
Only the fields your object configurations actually use for matching and sending. But yes — for those fields, any record not in digits-only format will not match incoming messages, with no error to tell you. A one-time mass update is far cheaper than the silent misses.
Keep any extra formatting in a separate field if you like — just make sure the field named in your object configuration holds the digits-only value.
Where to go next
- Matching incoming messages to records — how the exact match picks a record, and what happens when several match.
- Creating a Connect Account — the account fields these numbers live in.
- Default accounts and routing order — after formats, the other routing decision worth understanding.