Políticas
Uma Policy é uma regra configurável que governa como os entitlements se comportam. Em vez de ter lógica de negócio fixa no código como "créditos expiram em 12 meses" ou "suspender após a terceira falha de pagamento", o MIDDAG Account expõe essas regras como políticas configuráveis que os admins podem ajustar sem tocar no código.
Políticas são a resposta para "como mudo as regras para este cliente?" ou "como defino termos de renovação diferentes para este produto?"
A hierarquia de 5 níveis
Políticas podem ser definidas em cinco níveis. Quando o sistema precisa avaliar uma política para um entitlement específico, ele busca um valor no nível mais específico primeiro e sobe na hierarquia até encontrar um:
O nível mais específico com um valor definido vence. Níveis sem valor herdam do próximo nível acima.
| Nível | Onde é configurado | Exemplo de uso |
|---|---|---|
| Global | Configurações do plugin no WordPress admin | "Créditos expiram em 12 meses para todos" |
| Entitlement Class | Configurações da classe (PLG, ENV, SVC, etc.) | "Entitlements PLG renovam automaticamente por padrão" |
| Organization | Metadados da organização (por cliente) | "Acme Corp tem expiração de créditos de 24 meses" |
| Product | Configurações do produto WooCommerce | "SVC-Hosting tem cooldown de 60 dias para mudança de plano" |
| Entitlement (individual) | Metadados do entitlement (por entitlement específico) | "SVC-2026040001 tem cooldown de 90 dias (enterprise)" |
Valores nunca são mesclados entre níveis. Se o nível da organização define expiration_months = 24, esse é o valor final para aquele campo. Cada campo de política é resolvido independentemente através da hierarquia.
As políticas
O MIDDAG Account inclui estas políticas configuráveis:
Credit Policy
Governa como os créditos de serviço funcionam — expiração, ordem de consumo e limites. Relevante para entitlements SVC que incluem saldo de créditos.
- Quanto tempo os créditos duram antes de expirar
- Período de carência antes e depois da expiração
- Se bloqueia solicitações de serviço quando os créditos acabam
- Ordem de consumo: mais antigo primeiro (FIFO) ou mais recente primeiro (LIFO)
- Regras de expiração separadas para créditos comprados individualmente
Payment Recovery Policy
Governa o que acontece quando um pagamento recorrente falha.
- Quando suspender o entitlement: na primeira falha ou após todas as tentativas se esgotarem
- Se suspende mais cedo para clientes com histórico de problemas de pagamento
- Quantos dias um entitlement suspenso aguarda antes do cancelamento automático
- Se reativa automaticamente quando o pagamento é resolvido
Tier Change Policy
Governa o comportamento de upgrade e downgrade.
- Se mudanças de plano entram em vigor imediatamente ou no próximo ciclo de cobrança
- Se downgrades requerem aprovação (do admin, do cliente ou de ambos)
- Mínimo de dias entre mudanças de plano (cooldown, para evitar abuso)
- Como créditos são tratados durante uma mudança de plano
Cancellation Policy
Governa o que acontece quando um entitlement expira ou é cancelado.
- Quantos dias um entitlement expirado permanece visível no portal do cliente
- Quantos dias antes de um entitlement expirado ser automaticamente cancelado
- Quanto tempo os dados operacionais são retidos após o cancelamento
- Se oferece exportação de dados durante o processo de cancelamento
Nota: a retenção de dados financeiros e fiscais segue requisitos legais e não é configurável por esta política.
Notification Policy
Governa como e quando os clientes são notificados sobre seus entitlements.
- Quais canais usar (e-mail, SMS, WhatsApp, notificação no portal)
- Quantos dias antes da expiração enviar lembretes (ex.: 30, 7 e 1 dia antes)
- Alertas de saldo de créditos baixo (ex.: notificar quando o saldo cai abaixo de 20%)
- Se clientes podem optar por não receber notificações não críticas
Provisioning Policy
Governa como entitlements e seus recursos derivados são configurados.
- Se o provisionamento é automático (autoatendimento) ou requer aprovação do admin
- Quem aprova solicitações de provisionamento manual
- Se notifica um sistema externo via webhook após o provisionamento
- Comportamento de retentativa se o provisionamento falhar
- Se desprovisiona automaticamente os recursos quando um entitlement é cancelado
Renewal Policy
Governa como a renovação de entitlements funciona.
- Se renova automaticamente antes da expiração
- Quantos dias antes da expiração tentar a renovação
- Preço de renovação: mesmo preço do original ou preço atual do catálogo
- Com quanta antecedência o cliente pode renovar (janela de renovação antecipada)
- Quando enviar e-mails de lembrete de renovação
- Se bloqueia downgrades durante o período de renovação
Trial Policy
Governa o comportamento de testes gratuitos.
- Se testes gratuitos estão disponíveis
- Duração do teste em dias
- Se converte automaticamente para assinatura paga quando o teste termina
- Se um método de pagamento é necessário para iniciar o teste
- Número máximo de testes por organização (prevenção de abuso)
- Se admins podem estender testes
Refund Policy
Governa os termos de reembolso e seu impacto nos entitlements.
- Quantos dias após a compra um reembolso é permitido
- Se reembolsos abaixo de um limite são processados automaticamente
- Valor máximo para reembolsos automáticos (acima disso, aprovação manual é necessária)
- Se reembolsos parciais são permitidos
- Se o entitlement é automaticamente cancelado após um reembolso total
- O que acontece com os créditos após um reembolso (perder, manter ou ajustar proporcionalmente)
SLA Policy
Governa metas de nível de serviço para entitlements que incluem suporte ou serviços gerenciados.
- Tempo máximo de resposta para primeira resposta
- Tempo máximo de resolução
- Meta de uptime para ambientes gerenciados
- Horário de suporte (comercial, estendido ou 24x7)
- Se escalação automática é habilitada em caso de violação do SLA
- Níveis de prioridade disponíveis para solicitações de serviço
Como a sobrescrita funciona
Aqui está um exemplo concreto da hierarquia em ação:
Cenário: Quanto tempo duram os créditos do entitlement SVC-2026040001?
| Nível | Valor definido? | Resultado |
|---|---|---|
| Global | expiration_months = 12 | Fallback: 12 meses |
| Classe (SVC) | Não definido | Herda global: 12 meses |
| Organização (Acme) | expiration_months = 24 | Sobrescrita: 24 meses |
| Produto (SVC-Hosting) | Não definido | Herda org: 24 meses |
| Entitlement (SVC-001) | Não definido | Herda org: 24 meses |
| Resposta final | 24 meses |
A sobrescrita no nível da organização prevaleceu sobre o padrão global. Como nem o produto nem o entitlement individual definiram um valor, a configuração da organização é usada.
O que os admins veem
Políticas são configuradas em vários lugares no WordPress admin:
- Políticas globais: Página de configurações do plugin, na aba "Policies"
- Políticas por classe: Configurações de Entitlement Class, uma seção por política
- Políticas por organização: Página de detalhes da Organização, aba "Policies"
- Políticas por produto: Página de edição do produto WooCommerce, no painel MIDDAG Account
- Políticas individuais por entitlement: Página de detalhes do Entitlement, aba "Policy Overrides"
Cada tela de configuração mostra o valor efetivo atual de cada campo, com um indicador de qual nível está sendo herdado. Isso facilita ver que "este entitlement usa expiração de créditos de 24 meses porque a organização tem uma sobrescrita" sem verificar manualmente cada nível.
Páginas relacionadas
- Entitlements — a entidade que as políticas governam
- Entitlement Classes — o segundo nível da hierarquia de políticas
- Pedidos — políticas de reembolso e renovação afetam o comportamento pedido-entitlement
- Como os Conceitos se Conectam — o diagrama completo de relacionamentos