Use PD Cloudflare DNS Packages to define the DNS allowance linked to your sold Blesta packages. These module packages are an allowance policy, separate from the provider account’s own plan quotas.

Define the entitlement

1. Open PD Modules → Cloudflare DNS → Packages → Add package.
2. Enter the number of zones the allowance should permit.
3. Set any per-zone record limits and per-record-type limits you intend to enforce.
4. Choose the linked Blesta packages that include this allowance.
5. Save, then review the active-service entitlement for a controlled client account.

When several linked active services apply, the largest applicable allowance wins. Do not assume buying two services necessarily adds their limits together. Disabling an allowance package stops enforcing it without deleting the client’s DNS records.

Verify access and editing separately

A client still needs the correct zone assignment and visibility policy. Having an active service linked to an allowance does not justify exposing another client’s zone. Use the assignment guide to check ownership and links.

Check a permitted operation and the intended limit result through a controlled test process. Do not add disposable records to a customer’s working zone simply to test a quota.

Distinguish two kinds of quota

The module’s configured allowance and Cloudflare’s provider quota are separate constraints. A higher module limit cannot make the provider accept more records than its plan permits. Record the actual message before changing a policy.

An import can add some records before a provider limit is reached. The module’s own allowance preflight can instead refuse the planned import before writes. Inspect the current record set before retrying, and use the import guide for that partial-result case.

Change policies deliberately

Review existing customers and the intended commercial/service entitlement before changing linked offerings or limits. A configuration edit is not evidence that an existing record disappeared or that the provider’s plan changed.

If the applied allowance differs from expectations, your hosting team should retain the linked offering references, active-service state, intended limit and original redacted error while reviewing the actual entitlement. Do not include a client database export or provider token.

Check the effective allowance

Your hosting team should compare the saved enabled allowance packages and linked offerings with the customer’s actual active services, most generous applicable limits and requested record type. Review the zone assignment and provider plan separately. Inspect the original refusal and current records before changing a limit or repeating an import; a module preflight refusal differs from a later provider quota error. Do not export the client database or broaden unrelated customer access to diagnose one entitlement.

See the PD Cloudflare DNS Blesta guide for related tasks, or explore the module.