For a real Azure send, first confirm the existing resource and sender against the current eligibility and service-change guide. Configuration changes do not remove Azure’s onboarding restrictions.

Use Azure SMS → Client Preferences to decide which automatic-message categories clients can receive and which choices they see. Set the category wording clearly so a client understands what enabling a text-message preference does.

Choose each category’s behaviour

1. Open PD Modules → Azure SMS → Client Preferences.
2. Review the category label and explanation, using wording that explicitly mentions texts.
3. Choose On unless they opt out, Only if they agree or Not offered for that category.
4. Save the category and use Apply to client profiles when ready to apply the choices.
5. Check a controlled test client’s profile and preference summary before enabling live triggers.

Not offered means the category is absent and its automatic messages are not sent. Only if they agree starts off until the client enables it. Marketing Texts starts with that behaviour; campaigns use the marketing preference rather than assuming that every active client is a recipient.

Understand existing clients

Applying an opt-out category sets existing clients on as intended by that mode, but a client who turned off every offered preference is kept off when a new preference is added. Review the resulting profile state; changing the category is not a way to override an earlier blanket refusal.

The choices appear on Account Details, beside email preferences. Keep the SMS wording distinct from the client’s email preferences.

What the main setting changes

Let clients choose which texts they receive controls the exposed choices. Turning it off removes those choices and stops promotional sends; it does not stop all service messages or erase existing refusals. Profile removal can depend on the installed panel applying the setting immediately or the next normal cron run.

Automatic triggers and queued category messages check preferences. Manual sends and staff alerts follow different routing and are not blocked by these client choices. If the visible settings seem inconsistent, your hosting team should compare Health, the effective profile state and the module managing the shared fields. Do not change stored answers to diagnose a display mismatch.

Check the Azure context

A client preference does not expand Azure resource eligibility or sender capabilities. If an otherwise eligible automatic message is refused, read the original provider error and review the intended sender and destination before repeating it.

Several SMS modules on one installation

When several PD SMS modules are enabled, only the module managing the shared client-facing fields can apply their profile choices. PD SMS Manager takes precedence when present. If Client Preferences reports that another module manages the fields, make the profile-setting change there and review the result. Changing another module’s visibility setting may not remove the shared profile choices. The shared client page and individual message routing are separate matters.

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