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 package

1. Open Packages → Packages → Add Package.
2. Choose PD Azure MySQL as the module and select the intended saved Azure account.
3. Set Region, Plan, Engine version and Storage (GB) in the module fields. This is a MySQL offering; the engine scope is fixed by the module.
4. Review Resource name prefix and the client feature controls described below. Set the package’s terms and your own pricing, then save it in the intended package group.
5. Add that package group to the appropriate order form under Packages → Order Forms when it is ready for sale.

Use the package’s fixed settings first

The reviewed release does not expose the newer native configurable-option generation workflow described in some module guides. Start with a package for the intended fixed combination of region, plan, version and storage. Obtain guidance for your installed build before adding manual customer-selectable dimensions; do not copy option names from a different billing platform.

The module’s Products page can show the saved package and its attached customer options. A No customer options label describes that attachment; it does not establish whether the fixed package can provision.

Review the intended activation process. Eligible paid pending services are handled by Provision Paid Pending Services automation; a manually activated service needs the intended staff action. Keep the normal automation task and cron running. Saving a package or receiving payment alone does not prove that Azure has created the server.

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