Build a managed MySQL offering after saving its Azure connection. The module requests the selected database server configuration when the service is intentionally activated; saving the offering itself does not create a server.

Create the product

1. Open System Settings → Products/Services and create the intended product in its product group.
2. Choose Other Products/Services as the product type. In Module Settings, select PD Azure MySQL and the server group containing the intended Azure connection.
3. Set Region, Plan, Engine version and Storage (GB). This module provisions MySQL; selecting it does not create an offering for a different database engine.
4. Review Resource name prefix for new resources and the client feature controls described below.
5. Review Automatically setup the product. Choose the trigger that fits your order process, such as the first payment if that is when you want provisioning to begin. Do not assume a shortcut set it correctly.
6. Save the product. Review customer-selectable dimensions separately on the module’s Products page before offering them.

A checkout choice can override a Module Settings default. Confirm the actual selected region, plan, storage and version on the order form, including choices hidden from the customer.

Review the database specification

Choose the region, plan and engine version deliberately. The module uses a maintained catalogue of choices; a listed combination is not confirmation of capacity or availability in your particular subscription. Confirm the intended region and plan before making the offering available.

The starting MySQL storage floor is 20 GB in the module’s fields. Storage can grow later but cannot be reduced, so choose the starting size with the customer offering in mind. Azure describes the service’s storage behaviour in its Flexible Server storage guide.

Decide what clients can manage

Review Client: Firewall, Client: Connection details and Client: Databases. These govern access to trusted sources, connection credentials and database management. Enable the controls you intend to support rather than assuming every customer needs every action. The module’s admin database credential is different from the Azure app credential; customers should never receive the latter.

The Client Area Section field can add your intended overview text. Review what will be shown before publishing the offering, and keep provider credentials out of that field.

Verify the intended activation

Preview the order form, selected resource settings and your own pricing. When you are ready, use your normal authorised provisioning test: a real activation creates chargeable Azure resources. Inspect Clients & Databases, Activity, the service state and the provider result before calling setup complete. Keep the normal cron running for background progress.

A saved offering, a Ready options label or a passed connection check is not proof that a server exists or accepts database connections. A new server also needs the intended trusted source before an application can connect. If the result is uncertain, reconcile it before repeating activation.

Do not send provider credentials, database passwords or a full customer record.

See the PD Azure MySQL WHMCS guide for related setup, or explore PD Azure MySQL.