Policies
A Policy is a configurable rule that governs how entitlements behave. Instead of hardcoding business logic like "credits expire in 12 months" or "suspend after the third payment failure," MIDDAG Account exposes these rules as configurable policies that admins can adjust without touching code.
Policies are the answer to "how do I change the rules for this customer?" or "how do I set different renewal terms for this product?"
The 5-level hierarchy
Policies can be set at five levels. When the system needs to evaluate a policy for a specific entitlement, it looks for a value at the most specific level first and walks up the hierarchy until it finds one:
The most specific level with a value defined wins. Levels without a value inherit from the next level up.
| Level | Where it is configured | Example use case |
|---|---|---|
| Global | Plugin settings in WordPress admin | "Credits expire in 12 months for everyone" |
| Entitlement Class | Class settings (PLG, ENV, SVC, etc.) | "PLG entitlements auto-renew by default" |
| Organization | Organization meta (per customer) | "Acme Corp gets 24-month credit expiration" |
| Product | WooCommerce product settings | "SVC-Hosting has a 60-day tier change cooldown" |
| Entitlement (individual) | Entitlement meta (per specific entitlement) | "SVC-2026040001 gets a 90-day cooldown (enterprise)" |
Values are never merged across levels. If the organization level sets expiration_months = 24, that is the final value for that field. Each policy field is resolved independently through the hierarchy.
The policies
MIDDAG Account includes these configurable policies:
Credit Policy
Governs how service credits work -- expiration, consumption order, and limits. Relevant for SVC entitlements that include a credit balance.
- How long credits last before they expire
- Grace period before and after expiration
- Whether to block service requests when credits run out
- Consumption order: oldest first (FIFO) or newest first (LIFO)
- Separate expiration rules for credits purchased individually
Payment Recovery Policy
Governs what happens when a recurring payment fails.
- When to suspend the entitlement: on the first failure, or after all retries are exhausted
- Whether to suspend sooner for customers with a history of payment issues
- How many days a suspended entitlement waits before automatic cancellation
- Whether to reactivate automatically when the payment is resolved
Tier Change Policy
Governs upgrade and downgrade behavior.
- Whether tier changes take effect immediately or at the next billing cycle
- Whether downgrades require approval (from admin, customer, or both)
- Minimum days between tier changes (cooldown, to prevent gaming)
- How credits are handled during a tier change
Cancellation Policy
Governs what happens when an entitlement expires or is cancelled.
- How many days an expired entitlement stays visible in the customer portal
- How many days before an expired entitlement is automatically cancelled
- How long operational data is retained after cancellation
- Whether to offer a data export during the cancellation process
Note: financial and tax data retention follows legal requirements and is not configurable through this policy.
Notification Policy
Governs how and when customers are notified about their entitlements.
- Which channels to use (email, SMS, WhatsApp, portal notification)
- How many days before expiration to send reminders (e.g., 30, 7, and 1 day before)
- Credit balance low-threshold alerts (e.g., notify when balance drops below 20%)
- Whether customers can opt out of non-critical notifications
Provisioning Policy
Governs how entitlements and their downstream resources are set up.
- Whether provisioning is automatic (self-serve) or requires admin approval
- Who approves manual provisioning requests
- Whether to notify an external system via webhook after provisioning
- Retry behavior if provisioning fails
- Whether to automatically deprovision resources when an entitlement is cancelled
Renewal Policy
Governs how entitlement renewal works.
- Whether to auto-renew before expiration
- How many days before expiration to attempt renewal
- Renewal pricing: same price as original, or current catalog price
- How early a customer can renew (early renewal window)
- When to send renewal reminder emails
- Whether to block downgrades during the renewal period
Trial Policy
Governs free trial behavior.
- Whether trials are available
- Trial duration in days
- Whether to auto-convert to a paid subscription when the trial ends
- Whether a payment method is required to start a trial
- Maximum number of trials per organization (abuse prevention)
- Whether admins can extend trials
Refund Policy
Governs refund terms and their impact on entitlements.
- How many days after purchase a refund is allowed
- Whether refunds below a threshold are processed automatically
- Maximum amount for automatic refunds (above this, manual approval is needed)
- Whether partial refunds are allowed
- Whether the entitlement is automatically cancelled after a full refund
- What happens to credits after a refund (forfeit, retain, or adjust proportionally)
SLA Policy
Governs service-level targets for entitlements that include support or managed services.
- Maximum response time for first reply
- Maximum resolution time
- Uptime target for managed environments
- Support hours (business hours, extended, or 24x7)
- Whether automatic escalation is enabled on SLA breach
- Available priority levels for service requests
How override works
Here is a concrete example of the hierarchy in action:
Scenario: How long do credits last for entitlement SVC-2026040001?
| Level | Value set? | Result |
|---|---|---|
| Global | expiration_months = 12 | Fallback: 12 months |
| Class (SVC) | Not defined | Inherits global: 12 months |
| Organization (Acme) | expiration_months = 24 | Override: 24 months |
| Product (SVC-Hosting) | Not defined | Inherits org: 24 months |
| Entitlement (SVC-001) | Not defined | Inherits org: 24 months |
| Final answer | 24 months |
The organization-level override took precedence over the global default. Since neither the product nor the individual entitlement defined a value, the organization's setting is used.
What admins see
Policies are configured in several places in the WordPress admin:
- Global policies: Plugin settings page, under "Policies" tab
- Class-level policies: Entitlement Class settings, one section per policy
- Organization-level policies: Organization detail page, "Policies" tab
- Product-level policies: WooCommerce product edit page, in the MIDDAG Account panel
- Individual entitlement policies: Entitlement detail page, "Policy Overrides" tab
Each configuration screen shows the current effective value for each field, with an indicator of which level it is inherited from. This makes it easy to see "this entitlement uses a 24-month credit expiration because the organization has an override" without manually checking each level.
Related pages
- Entitlements -- the entity that policies govern
- Entitlement Classes -- the second level of the policy hierarchy
- Orders -- refund and renewal policies affect order-to-entitlement behavior
- How Concepts Connect -- the full relationship diagram