SMS

The SMS layer in ActiveManage lets your application send text messages to mobile phones for transactional notifications, alerts, two-factor authentication codes, password resets and marketing communications. It plugs into your chosen SMS gateway (Twilio, Vonage, MessageBird, AWS SNS or a custom HTTP relay) and exposes a single sending API that the rest of the platform calls.

When SMS Is Used

SMS is the right channel any time you need delivery in under a minute and you cannot rely on the recipient having the app open. Typical use cases include:

• Two-factor authentication. When a user signs in from a new device, the 6-digit code is texted to their registered mobile number.
• Password reset. Instead of (or alongside) the email reset link, the user can request a reset code by SMS.
• Booking reminders. A reminder to a patient, a tradesperson or a workshop attendee 24 hours before their appointment.
• Operational alerts. A site supervisor receives a text when an incident form is submitted with severity “major”.

How Sending Works

Every outbound message routes through one configured gateway, identified by an SMS engine record. The platform formats the destination number into E.164 (with the country prefix), substitutes any merge tokens, then posts the request to the gateway and stores the gateway's message ID for status tracking.

Note: Numbers entered without a country prefix are normalised against the tenant's default country. If no default is set the message will fail validation rather than being silently misrouted.

Cost and Throughput Considerations

SMS is metered per-segment (typically 160 GSM characters or 70 Unicode characters per segment). The platform shows the segment count before you send a campaign and stores the per-message cost reported by the gateway. Common pitfalls:

• Using an emoji or a curly quote unknowingly switches the message to Unicode, dropping the segment limit to 70.
• Some carriers reject all-caps sender IDs in marketing messages — use mixed case.
• UK alphanumeric sender IDs cannot exceed 11 characters.

Compliance

You are responsible for ensuring all marketing SMS has consent and an opt-out mechanism (typically “Reply STOP to unsubscribe”). The SMS log includes opt-out tracking so you can demonstrate compliance during an audit.

SMS is one of the supported delivery channels for two-factor authentication codes and password reset verification. When enabled, users receive a short numeric code by text rather than (or alongside) email, which is generally faster and harder to phish.

Turning SMS 2FA On

SMS 2FA is configured at three levels:

1. Globally in Site Settings → Security → Two-Factor Authentication — set “SMS” as an allowed second-factor method.
2. Per security group — tick “Require 2FA” on the group to force every member to enrol.
3. Per user — each user enrols by entering their mobile number and confirming the test code sent to it.

Tip: If users have multiple devices, prefer authenticator apps over SMS for highest-security roles. SMS is great for the long tail of users who do not want to install a separate app.

Password Reset by SMS

When SMS reset is enabled, the forgotten-password page asks for the user's email or username and then offers “Text me a reset code”. The flow is:

1. The platform looks up the user's stored mobile number.
2. It generates a 6-digit code, stores its hash with a 10-minute expiry, and texts the plaintext code to the user.
3. The user enters the code on the reset page and is prompted for a new password.

Example Workflows

• Healthcare portal: Patient signs in to view test results. The system requires SMS 2FA because the data is sensitive.
• Field operations app: Engineers signing in on shared tablets must complete an SMS challenge so a borrowed device cannot stay signed in.
• School parent portal: Parents reset forgotten passwords by SMS rather than waiting for an email, useful from a phone with no email client configured.

Failure Handling

If the SMS gateway rejects the number (wrong country prefix, blocked carrier, missing consent) the user sees a clear error and the system falls back to email if email-2FA is also configured for the user. Every failed send is captured in the SMS log for diagnosis.

The sender name (also called sender ID, originating address or short-code) is what your recipients see in the “From” slot of their text message inbox. ActiveManage lets you configure this per tenant and per use case, subject to carrier rules.

Where the Setting Lives

Go to Site Settings → Communication → SMS. The “SMS Sender Name” field accepts the default sender used by all outbound messages. Individual templates can override this if your gateway plan supports per-message sender IDs.

Country Restrictions

Sender IDs are governed by carrier policy in each destination country. The platform shows a country-by-country reference under the field; the most common rules are:

• United Kingdom: Alphanumeric senders up to 11 characters, no spaces or special characters except dashes.
• United States: Alphanumeric senders are not supported — you must use a registered long code or a 10DLC/short-code (e.g. “+12025551234”).
• Germany, France, Spain: Alphanumeric allowed but must be pre-registered with the carrier in some cases.
• India: Sender IDs must be pre-registered with TRAI and tied to an approved template.

Warning: Setting an unregistered alphanumeric sender in a country that requires pre-registration causes the gateway to reject every message silently or to replace the sender with a generic short-code. Test with one real number before rolling out.

Worked Examples

• A UK clinic sets the sender to HealthClin. Reminders arrive labelled with the clinic name rather than a number, building trust.
• A US courier company cannot use an alphanumeric sender, so they purchase a long-code (e.g. +14155550199) from the gateway and configure it as the sender.
• A multi-country SaaS sets the default sender to YourApp globally and overrides to a long-code for US-prefix destinations using a per-template rule.

Every outbound text message is recorded in the SMS log so that you can audit delivery, troubleshoot failed sends and report on usage and cost.

What Is Captured

Each log row contains the recipient phone number, sender ID, message body (or a token-summary if the message contains PII you have chosen not to retain), segment count, delivery status, gateway message ID, the originating user/template and the cost in your billing currency.

Common Statuses

• Queued: Accepted by the platform, awaiting gateway dispatch.
• Sent: Posted to the gateway successfully.
• Delivered: Confirmed received on the handset (where the gateway supplies delivery receipts).
• Failed: Gateway rejected the message — click the row to view the gateway's failure reason.
• Undelivered: Sent but never received (number off, blocked, invalid).

Example Investigations

• A user says they never got their 2FA code. Filter the log by their number and the last 10 minutes. If status is “Failed” with reason “invalid number”, the user has a typo in their stored mobile.
• This month's SMS bill jumped. Group the log by template and date. You will spot the new welcome-flow that started sending three texts to every signup.
• Audit request for GDPR. A data subject asks what SMS you have sent to them. Filter by their number and export to CSV.

Note: Delivery receipts are only as reliable as the destination carrier. Some networks (notably certain pay-as-you-go SIMs) never return a delivery confirmation — status may remain “Sent” indefinitely even though the message was received.