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.

Notify customers when an invoice is created or paid using separate PD Azure SMS triggers. These are billing-event messages, with invoice-specific merge fields; a bulk SMS campaign is a different workflow.

Prepare Billing Texts and templates

Open Azure SMS → Client Preferences and review Billing Texts. Apply the intended profile choices and check the test client’s effective mobile number. A hidden billing category prevents its automatic messages even if a trigger is enabled.

Create two enabled templates under Templates. A new-invoice notice can use Hi {first_name}, invoice {invoice_id} for {invoice_total} is due on {invoice_due}. Please check your client area. A paid-invoice notice can use Hi {first_name}, invoice {invoice_id} is now marked paid. Thank you from {company_name}.

Use the invoice number customers recognise, and inspect the rendered amount with its currency. A preview with sample data does not prove that every real invoice context is correct. Rehearse the intended event in a controlled test workflow through Test / Debug Log only before choosing a live gateway.

Create each trigger

1. Open Azure SMS → Triggers → New trigger.
2. Choose Invoice created, select the new-invoice template and an explicit Send via gateway, then choose Create trigger.
3. Create a second trigger for Invoice paid, using the paid-invoice template.
4. Review both rows for the correct template, gateway and enabled state.

The created notice follows the invoice being added. The paid notice follows Blesta closing the invoice as paid in full. It is not a notice for each partial payment, nor proof that a related service has finished provisioning.

These events cover renewals as well as initial invoices. Do not describe every paid-invoice text as a new order confirmation. Check for an existing trigger for the same event to avoid duplicate notifications.

Diagnose a missing notice

Confirm the original event occurred, the client has the intended mobile number and Billing Texts allows the message. Check that the selected template and trigger are enabled. Review pending work, quiet hours and normal cron operation before expecting a History attempt.

If History says Sent through Azure, Azure accepted the request; it does not prove phone delivery. Inspect the provider reference and Azure delivery evidence. A timeout marked Unknown should be reconciled before a manual repeat. Do not create or mark a real invoice paid merely to test the notification.

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 Blesta guide for related tasks, or explore PD Azure SMS.