How EspoCRM sends SMS through the SMS Providers extension
A team that wants to text customers or send verification codes from the CRM should start with one fact: EspoCRM has built-in SMS sending but does not bundle a provider. The core product can send messages, but it needs a provider account behind it. The official SMS Providers extension supplies the connectors: Twilio, Spryng, seven, smstools, SerwerSms, Verimor and GatewayAPI. Your first decision is therefore commercial and regional as much as technical: which provider your organization already contracts with, whether it operates in the countries you need to reach, and whether its sender IDs and message content rules fit your use cases. Confirm each provider's current coverage and terms directly with the provider before you commit to one.
Once a connector is configured, SMS can be sent from Formula or from PHP. Formula suits workflows and before-save logic, such as notifying an account owner when a case reaches a given status. PHP suits custom code that your developers maintain as part of an extension. Plan these paths before the build starts, because each one needs its own review of who can trigger a message, what phone number data it reads, and how failures are logged. Decide also whether any SMS must be sent by a person from a record. That requirement changes the design, because UI sending through the VoIP Integration is available only for Twilio, so a team that chooses another provider cannot rely on a sending button in the interface.
Two-factor codes deserve separate treatment. A verification code sent by SMS depends on the same provider, delivery reliability and phone number quality as marketing or service messages, and it carries a higher security expectation. Confirm with your security team whether SMS is an acceptable second factor for your users at all, given EspoCRM's own guidance on two-factor authentication, and whether the message content and sender setup meet your fraud and phishing controls. Keep provider credentials out of shared screens and test sending from a non-admin account, so that a configuration error does not expose an administrator's access.
What you need before enabling SMS in EspoCRM
SMS in EspoCRM depends on four layers: the CRM server, the extensions that add sending, a provider account, and network paths between them. Confirm each layer before you configure anything, because a gap in one usually shows up as a failed send that looks like a provider problem.
EspoCRM server stack
Your instance must run on a supported stack: PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, served by Apache, Nginx or IIS. Check the PHP version first, since it is the most common reason an upgrade or extension install fails. Confirm the exact combination against the server configuration page for the EspoCRM version you run.
Cron for background jobs
SMS queues and scheduled workflow steps run as background jobs, so a cron entry or scheduled task must be active on the server. Without it, messages can sit unsent while the form still shows success. Ask who owns the scheduler and how a missed run would be detected.
SMS Providers extension
Core EspoCRM has no bundled SMS provider. Install the official SMS Providers extension, which covers Twilio, Spryng, seven, smstools, SerwerSms, Verimor and GatewayAPI. Confirm that the extension version you install matches your EspoCRM version before you schedule the change.
Advanced Pack for workflows
If SMS will be sent automatically on a status change, assignment or schedule, you also need the Advanced Pack, which provides Workflows and Business Process Management. It is included in all EspoCRM Cloud plans. Self-hosted instances need it installed separately, so check licensing and compatibility before you design the automation.
Provider account and API credentials
Create a sending account with your chosen provider and generate the API credentials the extension requires. Confirm sender ID rules, country coverage, and any registration your provider or local regulator requires for the sender name or number before launch. Store credentials in your secret management process, not in shared notes.
VoIP Integration for UI sending
Sending SMS from the record screen, rather than only from formulas or workflows, requires the VoIP Integration with Twilio. That path is limited to Twilio. If your team needs manual sending from other providers, plan for formula or workflow sending instead, and confirm this limit against the current documentation.
Outbound network access
The EspoCRM server must reach your provider's API over HTTPS. Check egress firewall rules, proxy settings and any allowlist your provider publishes. Test with one message to a controlled number before any production list is used.
Configuring a provider and sending the first message
This sequence takes an EspoCRM instance from no SMS capability to a verified test message through the provider you chose, with a clear check at each stage. It shows where configuration decisions sit so that the first send is a controlled test rather than a live campaign.
Confirm the provider and extension version
Before installing anything, decide which provider your organization will contract with. The official SMS Providers extension implements Twilio, Spryng, seven, smstools, SerwerSms, Verimor and GatewayAPI, so check that your chosen provider is on that list. Confirm the extension version that matches your EspoCRM release with the SMS sending documentation, since menu names and fields can differ between versions. Done when you have a written note of the provider, the extension version and the EspoCRM version you are running.
Install the SMS Providers extension
A system administrator installs the SMS Providers extension through the Administration area's extension manager, or by the package method your deployment uses, then clears the cache and rebuilds as the installer instructs. Installation is a change to the production instance, so run it first on a staging copy when one exists. Done when the extension appears in the installed list and the SMS-related settings are visible in the administration area.
Create the provider account and credentials
Your team, or the person who owns the telecom contract, creates the account with the provider, registers or verifies the sending number or sender ID your jurisdiction and provider require, and generates the API credentials the extension needs. Store these secrets in your approved vault rather than in a shared document, and restrict who can view them. Done when you can log in to the provider console and the credentials are recorded in your secrets system with an owner named.
Configure the chosen provider in administration
In the administration area, open the SMS Providers configuration, select the provider, and enter the account identifiers and credentials. Field names vary by provider, so use the extension documentation for your installed version as the reference. Save the configuration, then confirm that the provider is marked as the active sending provider. Done when the settings save without a validation error and the active provider name matches the one you chose in the first step.
Set the sender identity
Define the sender value that recipients will see, which is typically a registered number, short code or alphanumeric sender ID depending on the provider and country. Agree who in the business may use it and document the rules for opt-in and opt-out handling before any customer receives a message. Where the provider offers separate sender numbers for different purposes, record which one this configuration uses. Done when the sender value is entered, documented and approved by the owner of customer communications.
Send a test message to a known number
Send one test message from EspoCRM to a phone number that belongs to a team member who has agreed to receive it. Use the sending method your deployment supports, such as a formula or workflow action, or the test action the extension provides for the installed version. Keep the text short and label it as a test so it cannot be mistaken for customer correspondence. Done when the message arrives on the test handset with the expected sender value and body.
Confirm delivery status and logs
Check the provider console for the message status and review the EspoCRM log for the send attempt, including any error returned by the provider. Verify that the status matches what the handset shows, and note any failure codes so they can be traced later. Record the successful test in your change log along with the provider, sender value and date. Done when both the provider console and the EspoCRM log show the message as sent or delivered, and the record is saved for the operations team.
Choosing between formula, workflow, PHP and UI sending
Sending from a formula field or before-save script fits cases where a record change should trigger one message with logic that stays inside the Entity Manager. The formula language is EspoCRM's built-in scripting language, and it runs in before-save scripts configured in the Entity Manager, as well as in API before-save scripts, workflows and BPM. Because the trigger is a save, the method works on the core edition without the Advanced Pack, provided the SMS Providers extension and a provider account are in place.
- Prerequisites: the SMS Providers extension installed, a configured provider, and a recipient phone field on the entity.
- Who maintains it: the EspoCRM administrator who owns the Entity Manager, so changes need the same review as layout edits.
- Where it fails: saves triggered by imports, API calls or mass updates can send unexpected messages if no condition limits the send.
- Good fit: a single confirmation or status notice tied to one field change.
- Watch for: duplicate sends when a record is saved several times, so add a guard field or condition.
Before relying on this method, confirm with a test record which saves, imports and API calls will run the script, and check how the provider handles repeated requests.
Workflows and BPM processes suit multi-step messaging: waiting for a time interval, branching on field values, or sending to a list of recipients after an approval. The Advanced Pack provides Business Process Management and workflows, and the Advanced Pack is included in all EspoCRM Cloud plans. Self-hosted deployments need the Advanced Pack as a separate add-on, so the licensing question comes first. Process logic is easier to read than a long script, and it is visible to people who do not write code.
- Prerequisites: the Advanced Pack, the SMS Providers extension and a tested provider configuration.
- Who maintains it: an administrator or process owner, often with a shared review step for changes to messages and recipient rules.
- Where it fails: processes that wait for long periods depend on the scheduled job runner, so a stopped cron leaves messages pending.
- Good fit: reminders, multi-step follow-ups and messages that depend on an approval.
- Watch for: opt-out and consent checks, which you must model in the process rather than assume.
Confirm with your provider how it handles delivery reports, and confirm how your EspoCRM instance runs its background jobs before you commit to time-based steps.
Custom PHP is the choice when the logic is too complex for the formula language, such as calling an internal service, applying detailed rules across several entities or handling provider responses in a specific way. It is written as an extension or hook and sends through the SMS sending interface that the SMS Providers extension exposes. Ownership moves from the administrator to a developer, which changes how the work is tested, versioned and upgraded.
- Prerequisites: a developer with EspoCRM extension experience, a version-controlled code base and a test instance.
- Who maintains it: the development team, who must re-test the code on every EspoCRM and extension upgrade.
- Where it fails: upgrades can break custom code if the internal interfaces change, and errors can be silent if logging is missing.
- Good fit: logic that a formula cannot express, such as cross-entity rules or integration with an internal system.
- Watch for: storing provider credentials in code, which should be avoided in favor of the extension's configuration.
Before you choose this path, ask your partner to estimate the upgrade effort and to explain how errors are logged and surfaced to administrators.
UI sending lets a user send an SMS from a record, typed by hand or from a template. This is available only through the VoIP Integration for Twilio, not through the other providers in the SMS Providers extension. It suits teams whose staff already call customers through Twilio and need text follow-up in the same record, but it is a manual method, so it does not replace automated messaging.
- Prerequisites: the VoIP Integration for Twilio installed and connected to your Twilio account, plus user permissions for the relevant entities.
- Who maintains it: the telephony owner, together with the administrator who sets roles and layouts.
- Where it fails: a team that uses Spryng, seven or another provider cannot use this path, and sending depends on each user's access.
- Good fit: account managers who send case-specific messages after a call.
- Watch for: message content and recipient checks left to the user, which need guidance and audit review.
Confirm the VoIP Integration setup requirements for your deployment and whether your organization's policy permits manual messages to customers.
Mapping phone numbers, message content and delivery status
This table maps each CRM field involved in an SMS send to its role in the message, from the recipient number to the status written back after the attempt. Read it as a checklist to run against the chosen extension's settings before any live send, since parameter names and formats must be confirmed in that extension. The main takeaway is that the consent flag and number normalization are the two mappings most likely to cause compliance or delivery failures if left to defaults.
| CRM element | Role in the send | What to confirm or decide |
|---|---|---|
| Recipient phone field | Supplies the number the provider delivers to | Confirm the field type and whether the extension expects a specific format, then add validation on the layout |
| Number normalization | Converts local entries to international format before the provider call | Decide the default country code and whether formula logic or the extension performs the conversion |
| Sender identity or number | Sets the originating number or sender ID shown to the recipient | Confirm which sender settings the chosen provider accepts and who owns the sender registration |
| Message body | Carries the text sent, often built from template fields | Check how the extension handles length, encoding and special characters in merged values |
| Template fields | Insert record values such as name or appointment time into the body | Test merges on records with empty fields so no blank or broken text reaches a recipient |
| Opt-in or consent flag | Must be checked before any send, including automated sends | Confirm the flag is enforced in the send condition, not only on the form, and that opt-outs are honored |
| Status fields after send | Record whether the provider accepted, delivered or rejected the message | Confirm which status values the provider returns and whether delivery receipts are supported |
| Provider parameter names | The exact keys the extension sends to the provider API | Confirm these names in the chosen extension's documentation before building field mappings |
Protecting provider credentials and SMS-based login
SMS touches two sensitive areas: the provider account that bills every message, and the sign-in path for staff. The cards below cover how to contain the provider secrets inside EspoCRM and where SMS verification fits alongside the password, session and single sign-on decisions you have already made.
Keep provider secrets out of shared admin use
Provider API credentials for Twilio or another SMS provider are entered in the SMS Providers configuration, so anyone who can open that screen as an administrator can read or replace them. Avoid running daily work from an admin account, and confirm who holds admin rights before you enter production credentials. Rotate the key when staff with admin access leave.
Restrict who views provider settings
Limit read and edit access to provider configuration to a small group of named administrators, and keep sending permissions separate from configuration permissions. Test with a non-admin account that the provider screen is hidden and that ordinary users can still send messages where you intend them to. Record every change to the provider settings in your change log.
Use a dedicated service account for workflows
When a workflow or formula sends SMS, run it under an API or service user with only the permissions the message needs, not a person's login. This keeps automated sends traceable and lets you disable one integration without affecting staff. Confirm in your version how the sending user is recorded on automated messages.
Limit the provider account to approved senders
Use only the sender numbers or sender IDs your organization has registered for messaging, and check the provider console for spending limits and alerts. A leaked key or a broken workflow loop can send large volumes quickly, so scope the account to the destinations and volume you actually need. Ask your provider which controls exist for sender restrictions.
Use SMS codes only with a fallback
SMS can deliver a one-time code for verification, but phone delivery fails during network outages and roaming. Plan a second method, such as a recovery code or an administrator-verified reset, and document it before you enforce the code. EspoCRM's own two-factor authentication is not compatible with OIDC, so for single sign-on users, the SMS code is not a substitute for the identity provider's controls.
Tie verification to password and session policy
Treat SMS verification as one part of the policy in the security docs, alongside a password policy, token lifetime limits and IP restrictions. Confirm that the session lifetime and password recovery settings for admins match your standard before you rely on a code for sign-in. Review these settings together after each upgrade.
Using SMS codes for two-factor sign-in
The main decision here is whether SMS should be a second factor for EspoCRM sign-in at all. The topic facts state that the SMS Providers extension adds SMS sending from Formula, PHP and the user interface, but they do not establish that a one-time code can serve as a login factor in every release. Before you switch on any SMS-based sign-in, confirm in the installed version whether EspoCRM's two-factor flow offers SMS delivery, which settings control it, and which user roles can use it. The EspoCRM SMS sending documentation is the starting point, and your own test instance is the final check. Do not assume a feature listed for one release behaves the same way after an upgrade.
Delivery depends on the same provider configuration as any other outbound message. A code is sent only if the SMS Providers extension is installed, the provider account is funded and approved for your destination countries, and the sender identity is accepted by the carrier. Test the full path with a staff phone number before rollout, and record how long a code takes to arrive on each carrier your users run. Keep the code lifetime and the password policy aligned: a short code window helps against interception, but a strict window combined with a delayed message produces failed sign-ins that users will blame on the platform. The EspoCRM security guidance also recommends enforcing a password policy and requiring 2FA, so SMS should be assessed as one control within that policy rather than as a standalone setting.
Depending on a single SMS route creates an operational risk. If one provider account is suspended, a carrier filters your messages, or a number is ported or lost, every affected user may be locked out at once. Plan for this before go-live. Confirm that at least one administrator can recover access through a second method, such as an authenticator app or a documented break-glass account stored outside the CRM, and that the recovery procedure is tested. Restrict admin accounts to a separate identity and disable password recovery for admins, as the security docs recommend. Ask your provider for their delivery reporting and escalation path, and document who can change the sender or provider settings during an incident.
Why SMS messages fail in EspoCRM and how to fix them
This table lists the failures teams most often hit when sending SMS from EspoCRM, with the likely cause and the fix for each. Read it as a checklist: start with the row that matches the symptom you see, such as a send that never leaves or a scheduled message that never fires. Most failures trace back to provider settings, the background job runner, or the provider's own sender and number rules.
| Failure | Likely cause | Fix |
|---|---|---|
| Messages never send | Provider credentials are missing or wrong in the SMS Providers configuration | Re-enter the account identifier, auth token or API key for the provider, then send a test message to a number you control |
| Number rejected | Recipient number is not in the international format the provider expects | Store phone numbers with a country code and normalize them in the entity or formula before the send |
| Sender ID rejected | The provider does not accept the sender name or number configured for the account | Check the provider's sender rules for your country and use a number or approved sender ID on your account |
| Scheduled SMS never fires | Cron or the scheduled task is not running, so background jobs stay queued | Confirm the cron entry for EspoCRM runs on schedule and check that queued jobs are being processed |
| Formula error in a before-save script | Syntax or reference error in the Formula Script, so the record save or the send step fails | Review the formula log, test the expression on a sample record, and fix the field or variable names it references |
| UI send button missing or failing | UI sending works only through the VoIP Integration for Twilio, so other providers cannot send from the record view | Send from Formula or workflows for other providers, or confirm your setup uses Twilio with the VoIP extension |
| Outbound calls blocked | Firewall or egress rules prevent the EspoCRM server from reaching the provider's API | Allow outbound HTTPS from the EspoCRM host to the provider's API endpoints and check proxy settings |
Questions buyers ask before adding SMS to EspoCRM
Does the open-source edition of EspoCRM support sending SMS?
Yes, through an extension. EspoCRM has built-in SMS sending but no bundled provider, so you add the official SMS Providers extension, which implements Twilio, Spryng, seven, smstools, SerwerSms, Verimor and GatewayAPI. The open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page, and the SMS Providers extension is added on top of that installation. Confirm the extension's current licensing and compatibility with your EspoCRM version before you commit to a provider.
What does adding SMS to EspoCRM cost, and what drives it?
The cost has three parts: the services and effort to configure the extension, the messaging charges paid to your provider, and the ongoing operation of the integration. Provider fees are set by each provider and are billed to your account, so compare their current rate cards for your countries and message volumes. Implementation effort rises with the number of use cases, the template design, the number of providers and the consent logic you must build. Ask any partner for a fixed-scope quote that lists each use case, the providers and the testing included.
How long does an SMS setup in EspoCRM take?
The duration depends on scope rather than on the extension itself, which is configured in EspoCRM's administration settings. The main variables are how many SMS use cases you need (for example, notifications from workflows, manual sending from records, or two-factor codes), whether you need a Twilio VoIP connection for sending from the user interface, how quickly your provider account and sender registrations are approved, and how much testing with real numbers you require. Ask for a written timeline that separates provider approval from build and test work.
What must our team provide before SMS can go live?
Your team needs to supply the provider account and API credentials, the sender identifiers or numbers your provider allows in each country, and a clear set of consent rules that state who may receive which messages. You also need to decide which records and fields hold phone numbers and how opt-outs are recorded. Confirm with your provider and your legal or compliance team which registration and consent steps apply in each market before any message is sent.
Can an in-house administrator set up SMS without a partner?
Often yes, if the administrator is comfortable with the EspoCRM administration area, the Formula language and provider account management. The extension configuration, the Formula script for sending and workflow steps are documented, and the same skills are used for other automation. A partner adds value when you need custom templates, several providers, complex consent handling, or a tested change process. Assess your team's experience with Formula, server access and production change control before deciding.
Do we need the Advanced Pack to send SMS from workflows?
Not necessarily for basic sending. The SMS Providers extension and EspoCRM's built-in SMS sending support sending from Formula or PHP. The Advanced Pack provides Business Process Management and workflows, which are useful when SMS should be triggered by process steps, approvals or scheduled rules. The Advanced Pack page describes what it includes. Note that UI sending through the VoIP Integration for Twilio is a separate path, so confirm which capabilities your chosen plan and extensions provide.
Can we send SMS two-factor codes through EspoCRM, and what should we check?
EspoCRM supports sending SMS through the extension, but you should not assume that SMS two-factor codes are a drop-in replacement for stronger second factors. Check whether your deployment's authentication design allows it, and plan for delivery failures, number changes and account recovery. If you use single sign-on, note that EspoCRM's own two-factor authentication is not compatible with OpenID Connect, so the second factor is usually handled by the identity provider. Review the SMS sending documentation before designing this path.
Consent, opt-outs and message content rules
The organization sending the texts owns the consent basis and the opt-out handling, not EspoCRM and not the SMS provider. Before the first message goes out, confirm with your legal team which basis applies to each group of recipients, such as customers who opted in through a form, contacts from a prior transaction, or leads acquired from a third party. Ask counsel which obligations apply in each country where you send messages and whether any sender registration or message template approval is required by the provider or the carrier. Interpretation of those rules is a question for your counsel, not for the implementation partner or the software vendor.
EspoCRM can hold the evidence you will need to show that a recipient consented and that a recipient opted out. Decide where that data lives before you build anything: a consent field or checkbox on the record, a dated record of when and how consent was given, and a flag that your sending logic checks before any SMS is queued. Formula Script can be used in before-save scripts or workflows to block sends to records without consent or with an opt-out flag, but the rule itself must come from your policy. Confirm with your provider how opt-out keywords such as STOP are received and whether the provider records them, and agree how those replies update the EspoCRM field so the two systems do not disagree.
Message content is part of the same review. Ask legal and the business owner to approve the wording of each template, including the sender identification, any required opt-out instructions and any content that touches health, finance or other sensitive subjects. Plan for message templates to be versioned and for someone to own changes after go-live. Check with your provider which content and sender rules apply to your country and volume before you configure any automated sends, and document the answers so an auditor or a new administrator can see why each rule exists.
