Before enabling real sends, confirm the existing resource and sender against the current Azure SMS eligibility guide. Saving a trigger or campaign does not remove Azure’s onboarding restrictions.

Use PD Azure SMS to notify a WHMCS client when a service is activated, suspended or unsuspended. Set up the events deliberately so a message describes the service action that happened, rather than promising that every application is ready.

Prepare the recipient and message

Check the effective mobile number and country on a controlled test client. Open Azure SMS → Client Preferences, review Service Texts, and apply the intended profile choices. The event’s category determines its preference check; putting a template into another library category does not bypass that check.

Create an enabled template under Templates. For a service event, use {service_product} for the customer-facing service name and {service_domain} where that service has a domain. A service without a domain can leave that field empty, so write a sentence that still makes sense. Use the merge-field reference, and keep the text limited to the information the recipient needs. Do not include passwords or sensitive service access details in the message.

Add the trigger

1. Open PD Modules → Azure SMS → Triggers → New trigger.
2. Under When this happens, choose Service activated.
3. Under Send this template, choose the intended enabled template.
4. Under Send via, choose an explicit gateway. Use Test / Debug Log only for a controlled rehearsal.
5. Choose Create trigger, then review the row’s event, template, gateway and On/Off state.

Create separate triggers for Service suspended and Service unsuspended if you use those notices, with wording specific to each state. These follow the module’s corresponding successful service actions. A paid invoice is a separate event and does not establish that unsuspension succeeded.

An activation text should invite the customer to check their service in the client area. It should not promise that DNS has propagated, an application is healthy or credentials have been delivered simply because the service action completed.

Verify the outcome

Review History for the actual recipient, rendered text and gateway. If queueing is enabled, normal cron operation and quiet hours can delay the attempt. A category marked Not offered, a client preference, a disabled template or missing mobile number can prevent sending even when a trigger exists.

Do not repeat a real customer event to force another notification. Check whether another enabled trigger already handles the same event before adding a duplicate. For Azure, a Sent result reflects Azure’s initial successful recipient result; later phone delivery is separate. An Unknown timeout needs reconciliation before any repeat message.

Several SMS modules on one installation

When several PD SMS modules are enabled, a single module manages the shared client-profile fields. PD SMS Manager takes precedence when present. Follow any Client Preferences message identifying that module and make shared profile-setting changes there. Check PD Azure SMS’s own category rules, phone source and gateway routing separately; a shared profile summary does not prove every enabled module’s sending configuration.

Distinguish the recorded result from delivery

The gateway checks Azure’s per-recipient send result. A Sent record reflects initial success, not later delivery to the phone. Enabling Request delivery reports requests Azure-side reporting; it does not set up Event Grid subscriptions or update module History with later results. Keep the Azure message reference for an investigation instead of treating a campaign progress total or green result as a delivery receipt.

See the PD Azure SMS WHMCS guide for related tasks, or explore PD Azure SMS.