A2P SMS Template Validation: Checks Before Publishing
An operational guide to reviewing SMS template changes, checking their technical effects, and maintaining traceability before sending.
A small edit can change technical behavior
Changing a template can affect its character set and message length and, depending on the encoding and applicable rules, the number of segments. An apparently editorial change—such as adding a symbol or altering a variable—deserves a new technical review, not just a style approval.
Do not assume that every platform handles encoding, concatenation, or variables in the same way. Confirm how they behave in the documentation for the platform and connector you use. Applicable rules depend on the effective encoding and the implementation.
- Treat every modification as a change that requires assessment.
- Record the result returned by the validation system or platform; do not assume it applies to other environments.
- Do not use a generic character count as a substitute for a technical check.
Create a record that identifies every template
Maintain a centralized record with a unique identifier and enough information to understand the intended use of each template. The exact structure will depend on your processes, but it should distinguish approved content from other variants and assign responsibilities.
As a minimum operational record, consider including the purpose, language, intended sender, responsible team, version, and approval status. If a platform requires additional fields, document those requirements as well.
- Assign a stable identifier that does not depend on the visible text.
- Keep the template’s purpose separate from its specific content.
- Indicate who maintains the template and who can authorize its publication.
- Keep the exact text associated with each approved version.
Validate content, characters, variables, and length
Before approving a change, check the text against the technical rules of the intended platform and sending route. The review should establish whether the characters used are supported, which encoding applies, and how length and segments are calculated. It is unwise to infer these results from how the message looks alone.
Review variables as elements with their own rules: expected format, whether they can be empty, expected maximum length, and the characters they can contain. If those constraints are not defined, validation is incomplete. The available evidence does not establish one universal rule for how all systems resolve variables or concatenate messages.
- Check the final text processed by the integration, not just the template with placeholders.
- Identify characters that may change the encoding under your system’s documented rules.
- Verify length and segment limits using the relevant tool or documentation.
- Record the encoding and the validation result observed.
Test representative substitutions before publishing
A template may appear valid even when its actual values are not. Test substitutions that reflect legitimate data in the environment: a typical value, one close to the permitted limit, and any special cases allowed by the variable’s contract. Also check what happens when an optional field is empty, if that situation can occur.
Do not put arbitrary test values into production. Use authorized synthetic or test data and avoid including unnecessary personal information. The goal is to verify the resulting text and its technical handling, not to broaden the scope of the message.
- Cover short and long values within the defined limits.
- Test special characters only if the field allows them.
- Check that substitution does not leave unresolved placeholders or produce ambiguous content.
- Save test results without exposing sensitive data.
Separate editorial, technical, and publication approvals
A content review does not replace a technical check, and technical validation alone does not determine whether a message is authorized for use. Set distinct checkpoints: review of the purpose and text, validation of characters and behavior, and publication authorization in accordance with internal and applicable rules.
For marketing communications, also confirm that the use and audience meet consent requirements and relevant rules. Technical tests do not establish consent or the legitimacy of a send.
- Define who reviews the content and who checks technical aspects.
- Require approval before a version becomes available for sending.
- Record the decision, responsible person, and date in accordance with the organization’s retention policy.
- Do not confuse a successful test with authorization to send.
Version templates and link sends to the version used
Every approved modification should create an identifiable version. This helps prevent a later change from silently replacing content that was already validated. Maintain a link between the published version and the send or process that used it, to the extent your platform and systems allow.
Decide in advance how to maintain that link—for example, by recording the identifier and version in your management systems. Do not assume an API or connector provides this function; check which fields and records the specific integration exposes.
- Do not overwrite an approved version without keeping a history.
- Record each version’s status—draft, under review, approved, published, or retired—if those statuses fit your process.
- Associate validation results and approvals with the exact version.
- Verify that the available records let you identify which version was used.
Run regression checks before deployment
Before publishing a modification, compare its output with the previous version and repeat the affected checks. Regression testing should cover visible content, variables, encoding, length, and segments, as well as compatibility with the integration that sends the message.
The scope of testing depends on what changed. An edit that does not touch a variable may require different checks from one that alters its format or length. Document the scope criteria so the team can explain what was checked again.
- Compare the exact text and the list of changes.
- Repeat the relevant substitution tests.
- Confirm that the sending system accepts the intended version and fields.
- Revalidate any aspects whose results could be affected by the modification.
Record failures and retire versions with traceability
When validation fails, record the version examined, the test environment, the observed result, and the known reason. Distinguish a reproducible error from a cause that has not yet been confirmed; if there is not enough evidence, avoid attributing the failure to encoding, the operator, or the transport.
If you need to retire a template, mark the version as unavailable for new sends according to your system’s capabilities. Keep the history and evidence of approval or retirement in line with internal policies and applicable obligations. Do not delete records needed to reconstruct what happened.
- Include the date, responsible person, template identifier, and version.
- Attach the available technical result and steps to reproduce it.
- Indicate whether the cause is confirmed or still under investigation.
- Check what retiring a version means in the specific platform and which records it retains.
Frequently asked questions
Is checking the template’s character count enough?
Not necessarily. The result can depend on the characters, encoding, and the platform’s rules for length and concatenation. Validate the final text and consult the sending system’s documentation.
Does every text change need a new version?
As a control practice, it is a good idea to identify each approved change with a new version or an equivalent history. This makes it possible to preserve which content was validated and which version was published.
Which variable values should be tested?
Test representative values within the defined limits, including values close to the maximum and any special characters the field allows. If the limits are not documented, clarify them before approving the template.
Does a technical test prove that a send is authorized?
No. The test checks technical aspects of the template and integration. Content authorization and, where applicable, consent and regulatory compliance require separate controls.
Sources consulted
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA
- SMPP v3.4 specificationSMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- Comprender los segmentos de mensajes para SMSHubSpot Knowledge Base
- Configuración y protocolo del conector SMSAdobe Experience League