SMS DLT template mapping and sending lifecycle runbook

SMS DLT template mapping and sending lifecycle runbook explains how to turn an approved MSG91 or Exotel SMS/DLT template into a production-safe SquareOS template with exact body matching, ordered variables, provider callback proof, and mobile-safe read-only boundaries.

What this page is for

Who should use it

Owner, implementation, communications admin, platform admin, support

Where to find it

MSG91 panel, Exotel Dashboard, DLT portal, SquareOS Admin / SMS Templates

Before you start

SMS DLT template mapping and sending lifecycle runbook must be completed for each SMS template before staff use it in reminders, dues, campaigns, class/session updates, payment-link handoff, freeze/cancellation notices, or member lifecycle notifications.
SMS template creation starts after connected SMS Channel Account and Sender Account exist, and records provider MSG91 or Exotel, approved sender header, DLT Entity ID, DLT Template ID, provider template or flow id, route, encoding, body text, variable key order, sender account, provider account, event key, and internal description.
Provider portal template proof records approved DLT body, exact variable placeholders, template category or route, Unicode or text encoding decision, approval status, provider template or flow id, and screenshot or support ticket evidence before SquareOS marks the template production-ready.
SquareOS SMS fields map provider values to Message Template channel SMS, externalTemplateId or smsProviderTemplateId, designJson dltEntityId/dltTemplateId/route/encoding/variableKeys, Sender Account senderValue, Channel Account provider config, and active template status.
SMS send proof requires active template status, connected sender account, connected provider account, DLT Entity ID, DLT Template ID, approved sender header, exact body match, ordered variables, fake mode off for live certification, provider message id, and POST /engagement/sms/:provider/webhook callback.
MSG91 and Exotel delivery callbacks must update DeliveryAttempt, Message, CampaignDeliveryLog when campaign-originated, and dead-letter state by matching provider message id before staff call delivery verified.
Rejected, unmapped, body-mismatched, or pending SMS templates must keep campaign, automation, profile activity, Inbox, class group message, and mobile SMS send actions disabled or routed to an approved replacement template.
SMS variable QA must prove each SquareOS variable key maps to the same placeholder order approved in DLT/provider portal and that missing variables fail closed rather than sending unapproved text.
SMS template secret handling forbids exposing MSG91 Authkey, Exotel API token, webhook token, DLT portal screenshots with private data, raw delivery callback payload, or sample customer data in mobile screens, support tickets, analytics, or crash logs.
If MSG91, Exotel, or DLT portal labels differ from the runbook, extraction row must record portal path attempted, provider field label, copied value, SquareOS field, approver, replacement template id, and verification action.

Daily workflow

Confirm the SMS Channel Account is connected and the SMS Sender Account uses the same approved sender header recorded in MSG91, Exotel, and the DLT/provider approval evidence. Do not create a template against a disconnected provider or a mismatched sender.
In MSG91, open the SMS template/flow or DLT template area used by the gym. Record template name, flow id or template id, DLT Entity ID, DLT Template ID, sender header, route/category, approved body, variable placeholders, encoding, approval state, and last approval/sync time.
In Exotel, open the SMS/DLT/onboarding screen or support ticket supplied by Exotel. Record Account SID, approved sender header, DLT Entity ID, DLT Template ID, provider template reference when supplied, route/category, exact body, variables, encoding, approval state, and status callback readiness.
In SquareOS Admin / SMS Templates, create the Message Template with channel SMS, the correct event key, linked sender account, linked provider account, externalTemplateId when the provider expects the approved template id/name, SMS DLT Entity ID, SMS DLT Template ID, provider template or flow ID, route, encoding, body template, variable key order, and internal description.
For MSG91, put the MSG91 flow id or approved template reference in Provider template / flow ID when it differs from the DLT Template ID. For Exotel, use the Exotel/provider template reference or leave it blank only when the Account SID plus DLT Template ID is the certified dispatch key.
Body template must remain an exact copy of the approved DLT/provider body except for SquareOS variable names replacing approved placeholders. The variable key order field must list the SquareOS variables in the same order as the provider placeholders, for example memberName, dueAmount, dueDate, paymentLink.
Before activating, render one preview with complete variable data and one preview with a required variable missing. The complete preview must match the approved body shape, and the missing-variable case must fail closed or remain unsent instead of sending unapproved fallback text.
Set template status to active only after provider approval is documented. If the provider says pending, rejected, unmapped, or body mismatch, keep the template inactive or archived and route staff to an approved replacement template.
Run one live certification send to an opted-in internal phone with fake mode off. Capture the provider message id, request id, rendered body, sender header, DLT Template ID, callback payload reference, DeliveryAttempt status, Message status, CampaignDeliveryLog update when relevant, and dead-letter result.
For delivery callbacks, verify the configured endpoint POST /engagement/sms/msg91/webhook or POST /engagement/sms/exotel/webhook receives a token-verified callback and matches by provider message id. Delivery is not production-certified until the callback updates SquareOS rows or the failed state is documented.
For gym use cases, create separate approved templates for appointment reminder, class reminder, renewal due, invoice due, payment link, trial follow-up, PT session change, freeze request status, cancellation status, transfer request status, birthday/anniversary campaign, and emergency closure notice when those messages are sent by SMS.
After launch, audit SMS dead letters daily for DLT mismatch, sender mismatch, opt-out, DND, quiet-hour suppression, provider disconnected, body mismatch, and variable mismatch. Keep affected workflows disabled until an approved template or provider fix is certified.

Watch out

Do not treat the DLT Template ID, provider template id, and MSG91 flow id as always interchangeable. Record each value separately and map it to the exact SquareOS field used by dispatch.
Do not let staff edit approved SMS body copy from Inbox, campaigns, automation, profile activity, or mobile when the message is template-controlled. Free-form SMS needs a separate permission and compliance decision.
Do not activate a template from a screenshot alone if the screenshot hides sender, DLT Template ID, body, variables, or approval state. The extraction row must connect provider evidence to SquareOS fields.
Do not store MSG91 Authkey, Exotel API token, webhook token, raw callback payload, or screenshots containing customer phone numbers in general docs, mobile analytics, crash logs, or support attachments.
Do not mark delivered from queued provider response, cached status, fake-mode attempt id, manually typed message id, or unsigned callback. Delivery proof must match the provider message id and verified callback state.
Do not reuse one approved template across unrelated gym scenarios if the body intent changes. Renewal dues, class reminders, payment links, freeze status, and cancellation status should each have their own approved wording.

Use the left menu to open related pages in Start Here.
Use Ask Docs for questions that are already covered in this public documentation.