Policies Disponíveis
O MIDDAG Account inclui 10 policies configuráveis. Cada policy controla um aspecto específico do comportamento dos entitlements. Esta página é a referência completa — todos os campos, todos os padrões, todas as opções.
Para entender como a hierarquia de sobrescrita funciona, consulte Hierarquia de Policies. Para configuração passo a passo, consulte Configurando Policies.
Renewal Policy
O que controla: Comportamento de renovação automática, janelas de carência antes da expiração e precificação na renovação.
Quando importa: A cada ciclo de cobrança, quando um entitlement se aproxima da data de expiração.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
auto_renew | true | true / false | Renovar automaticamente antes da expiração |
grace_days_pre_expiry | 7 | Inteiro (dias) | Dias antes da expiração para tentar a cobrança de renovação |
renewal_pricing | same | same / current | same = preço original; current = preço atual do catálogo |
early_renewal_days | 30 | Inteiro (dias) | Antecedência máxima para o cliente renovar manualmente |
renewal_reminder_days | [30, 7, 1] | Lista de inteiros | Dias antes da expiração para enviar lembretes de renovação |
failed_renewal_retries | 3 | Inteiro | Tentativas de retentativa para uma cobrança de renovação falha |
block_downgrade_at_renewal | false | true / false | Impedir downgrades de plano durante a janela de renovação |
Cenário de exemplo: Um contrato de serviço (classe SVC) renova pelo preço atual do catálogo em vez do preço original, e downgrades são bloqueados durante a janela de renovação. A classe SVC sobrescreve renewal_pricing: current e block_downgrade_at_renewal: true.
Payment Recovery Policy
O que controla: Como o sistema responde a falhas de pagamento — quando suspender, quanto tempo esperar antes do cancelamento e se deve reativar automaticamente.
Quando importa: Quando um cartão de crédito expira, uma cobrança é recusada ou uma transferência bancária falha.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
trigger | retry_exhausted | first_failure / retry_exhausted | Quando suspender: na primeira falha ou após todas as retentativas |
anticipate_suspension | false | true / false | Pré-suspender clientes com histórico de problemas de pagamento |
suspended_to_cancelled_days | 30 | Inteiro (dias) | Dias em estado suspenso antes do cancelamento automático |
auto_reactivate_on_payment | true | true / false | Reativar automaticamente quando o pagamento é bem-sucedido |
Cenário de exemplo: Entitlements de plugin (classe PLG) usam uma janela de suspensão mais curta de 14 dias, pois plugins são baratos e facilmente readquiridos. Entitlements de ambiente (classe ENV) usam 15 dias porque um ambiente de hospedagem suspenso é urgente para o cliente.
Cancellation Policy
O que controla: O que acontece após um entitlement expirar — visibilidade no portal, timing de cancelamento automático e retenção de dados.
Quando importa: Quando um entitlement expira e não é renovado, ou quando um cliente cancela.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
portal_visibility_days | 90 | Inteiro (dias) | Dias que um entitlement expirado permanece visível no portal |
expired_to_cancelled_days | 30 | Inteiro (dias) | Dias em estado expirado antes do cancelamento automático |
data_retention_days | 365 | Inteiro (dias) | Dias para manter dados operacionais após o cancelamento |
data_action | export_and_delete | export_and_delete / archive / retain | O que fazer com os dados do cliente no cancelamento |
offer_data_export | true | true / false | Oferecer exportação de dados durante o fluxo de cancelamento |
Importante: Dados fiscais e tributários seguem os prazos de retenção legais (LGPD, legislação tributária) e NÃO são controlados por esta policy. Apenas dados operacionais são afetados.
Cenário de exemplo: Entitlements de plugin (classe PLG) usam archive em vez de export_and_delete porque dados de licença são leves e clientes podem reativar no futuro. A retenção de dados é definida como 90 dias em vez de 365.
SLA Policy
O que controla: Metas de nível de serviço para tempos de resposta, tempos de resolução, uptime e comportamento de escalonamento. Utiliza um modelo de 4 tiers: Standard, Priority, Critical e Dedicated.
Quando importa: Toda vez que uma solicitação de serviço é criada contra um entitlement.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
sla_level | standard | standard / priority / critical / dedicated | Qual tier de SLA se aplica (determina as metas de resposta) |
response_time | (escalonado, veja abaixo) | Objeto com metas por nível e por prioridade | Metas de tempo de primeira resposta |
resolution_time | (escalonado, veja abaixo) | Objeto com metas por nível e por prioridade | Metas de tempo de resolução |
uptime_target | 99.5% | String percentual | Meta de uptime (somente ambientes gerenciados) |
support_hours | business_hours | business_hours / extended / 24x7 | Janela de disponibilidade do suporte |
escalation_enabled | true | true / false | Escalonar automaticamente quando o prazo de SLA está próximo |
escalation_after_pct | 80 | Inteiro (porcentagem) | Porcentagem do tempo de SLA para acionar o escalonamento |
priority_levels | [low, normal, high, urgent] | Lista de prioridades | Níveis de prioridade disponíveis para solicitações de serviço |
Tiers de SLA — metas de tempo de resposta Standard:
| Prioridade | Resposta | Resolução |
|---|---|---|
| P1 | 8h | 2 dias |
| P2 | 1 dia | 3 dias |
| P3 | 2 dias | 5 dias |
| P4 | 3 dias | 7 dias |
| P5 | 5 dias | 10 dias |
Tiers de SLA — metas de tempo de resposta Priority:
| Prioridade | Resposta | Resolução |
|---|---|---|
| P1 | 4h | 1 dia |
| P2 | 8h | 2 dias |
| P3 | 1 dia | 3 dias |
| P4 | 2 dias | 5 dias |
| P5 | 3 dias | 7 dias |
Tiers de SLA — metas de tempo de resposta Critical:
| Prioridade | Resposta | Resolução |
|---|---|---|
| P1 | 2h | 8h |
| P2 | 4h | 1 dia |
| P3 | 8h | 2 dias |
| P4 | 1 dia | 3 dias |
| P5 | 2 dias | 5 dias |
Tiers de SLA — metas de tempo de resposta Dedicated:
| Prioridade | Resposta | Resolução |
|---|---|---|
| P1 | 30 min | 2h |
| P2 | 1h | 4h |
| P3 | 2h | 8h |
| P4 | 4h | 1 dia |
| P5 | 8h | 2 dias |
Todos os tempos são em horário comercial (9:00-18:00 BRT, seg-sex) a menos que support_hours esteja definido como extended ou 24x7.
Cenário de exemplo: Entitlements de serviço (classe SVC) usam por padrão SLA Priority com horário de suporte estendido e escalonamento mais cedo (a 70% do tempo de SLA em vez de 80%). Entitlements de ambiente (classe ENV) usam SLA Standard, mas com uma meta de uptime maior de 99,9%.
Credit Policy
O que controla: Como créditos de serviço (UST) se comportam — expiração, períodos de carência, ordem de consumo e limites de saldo negativo.
Quando importa: Para entitlements que incluem saldo de créditos, tipicamente contratos de serviço (classe SVC).
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
expiration_months | 12 | Inteiro (meses) | Meses até os créditos inclusos no plano expirarem |
grace_before_days | 0 | Inteiro (dias) | Dias de carência antes da expiração |
grace_after_days | 30 | Inteiro (dias) | Dias de carência após a expiração antes dos créditos serem perdidos |
block_on_limit_exceeded | false | true / false | Bloquear novas solicitações de serviço quando o saldo estiver negativo |
limit_threshold | 0 | Inteiro (créditos) | Saldo negativo de créditos permitido antes do bloqueio (0 = nenhum) |
avulso_expiration_months | 6 | Inteiro (meses) | Expiração de créditos comprados avulsos como recarga |
consumption_order | fifo | fifo / lifo | fifo = créditos mais antigos usados primeiro; lifo = mais recentes primeiro |
Cenário de exemplo: Uma organização enterprise negocia expiração de créditos de 24 meses em vez dos 12 meses padrão. Isso é configurado como sobrescrita no nível da organização: expiration_months: 24.
Provisioning Policy
O que controla: Se o acesso é configurado automaticamente após a compra ou requer aprovação manual do admin. Também controla notificações via webhook e desprovisionamento no cancelamento.
Quando importa: Imediatamente após um pagamento bem-sucedido, quando o entitlement é criado.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
auto | true | true / false | Provisionar automaticamente no pagamento ou exigir aprovação manual |
require_approval | none | none / admin / both | Quem deve aprovar quando o provisionamento é manual |
webhook_enabled | false | true / false | Notificar um sistema externo após o provisionamento |
retry_on_failure | true | true / false | Retentar o provisionamento em caso de falha |
max_retries | 3 | Inteiro | Máximo de retentativas antes de falha permanente |
timeout_minutes | 30 | Inteiro (minutos) | Minutos antes de marcar o provisionamento como falho |
notify_admin_on_manual | true | true / false | Enviar notificação ao admin quando provisionamento manual é necessário |
deprovision_on_cancel | false | true / false | Remover recursos automaticamente quando o entitlement for cancelado |
Cenário de exemplo: Entitlements de plugin (classe PLG) são totalmente automáticos — a compra aciona a geração instantânea da licença. Entitlements de serviço (classe SVC) sobrescrevem para provisionamento manual (auto: false, require_approval: admin) porque contratos exigem válidação humana e configuração de workspace no Jira. Entitlements de ambiente (classe ENV) habilitam deprovision_on_cancel: true para desligar ambientes de hospedagem quando cancelados.
Trial Policy
O que controla: Disponibilidade de trial gratuito, duração, conversão automática para pago e prevenção de abuso.
Quando importa: Quando um cliente em potencial quer experimentar um produto antes de se comprometer.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
enabled | false | true / false | Se trials estão disponíveis neste nível |
duration_days | 14 | Inteiro (dias) | Duração do trial |
auto_convert | true | true / false | Converter automaticamente para assinatura paga ao fim do trial |
require_payment_method | false | true / false | Exigir cartão de crédito para iniciar o trial |
max_trials_per_org | 1 | Inteiro | Máximo de trials por organização (previne abuso) |
extend_allowed | false | true / false | Permitir que um admin estenda o trial manualmente |
notification_days_before_end | [3, 1] | Lista de inteiros | Dias antes do fim do trial para notificar o cliente |
Cenário de exemplo: Trials estão desabilitados globalmente, mas habilitados para a classe Environment (ENV) para permitir que escolas testem a plataforma de hospedagem Campus EAD. A sobrescrita da classe ENV define enabled: true e require_payment_method: true para prevenir abuso dos recursos de provisionamento em nuvem.
Refund Policy
O que controla: Janela de elegibilidade para reembolso, aprovação automática vs manual, limites, e o que acontece com o entitlement e os créditos após um reembolso.
Quando importa: Quando um cliente solicita reembolso após a compra.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
refund_window_days | 30 | Inteiro (dias) | Dias após a compra para solicitar reembolso |
auto_refund | false | true / false | Aprovar reembolsos automaticamente dentro da janela (até o valor máximo) |
auto_refund_max | 100.00 | Decimal ou objeto multi-moeda | Valor máximo para reembolso automático; acima disso precisa de admin |
partial_allowed | true | true / false | Permitir reembolsos parciais proporcionais ao uso |
approval_required | admin | none / admin | Quem deve aprovar as solicitações de reembolso |
cancel_entitlement | true | true / false | Cancelar o entitlement após um reembolso total |
credits_on_refund | forfeit | forfeit / retain / proportional | O que acontece com créditos não utilizados no reembolso |
Cenário de exemplo: Entitlements de plugin (classe PLG) habilitam reembolso automático para compras abaixo de R$500 BRL / $100 USD, pois plugins são de baixo risco e políticas de reembolso generosas reduzem a carga de suporte. Entitlements de serviço (classe SVC) definem refund_window_days: 0 porque contratos anuais não possuem período de reembolso, embora um admin ainda possa aprovar exceções.
Tier Change Policy
O que controla: Como upgrades e downgrades funcionam — imediato vs próximo ciclo de cobrança, cooldown entre mudanças, requisitos de aprovação e ajuste de créditos.
Quando importa: Quando um cliente deseja mudar para um tier de plano superior ou inferior.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
effect | immediate | immediate / next_cycle | Quando a mudança de tier entra em vigor |
downgrade_requires_approval | none | none / admin / client / both | Quem deve aprovar um downgrade |
cooldown_days | 0 | Inteiro (dias) | Mínimo de dias entre mudanças de tier (0 = sem limite) |
credit_behavior | next_cycle | immediate / next_cycle / forfeit | Como os créditos são ajustados na mudança de tier |
Cenário de exemplo: Entitlements de serviço (classe SVC) sobrescrevem para effect: next_cycle (mudanças entram em vigor no próximo ciclo de cobrança), downgrade_requires_approval: admin e cooldown_days: 90 para evitar trocas frequentes de plano em contratos anuais.
Notification Policy
O que controla: Quais canais de notificação estão ativos, quais eventos disparam notificações, timing de lembretes e configurações de opt-out.
Quando importa: Ao longo de todo o ciclo de vida do entitlement — avisos de expiração, alertas de pagamento, lembretes de renovação e muito mais.
| Campo | Padrão | Opções / Faixa | Descrição |
|---|---|---|---|
channels | [email] | email, sms, whatsapp, portal | Canais de notificação ativos |
events | (veja abaixo) | Lista de identificadores de eventos | Eventos que disparam notificações |
expiry_warning_days | [30, 7, 1] | Lista de inteiros | Dias antes da expiração para enviar avisos |
credit_low_threshold_pct | 20 | Inteiro (porcentagem) | Porcentagem do saldo de créditos para disparar alerta de crédito baixo |
allow_opt_out | true | true / false | Permitir que colaboradores desativem notificações não críticas |
Eventos de notificação padrão: expiry_warning, credit_low, payment_failed, payment_success, suspension, cancellation, renewal.
Cenário de exemplo: Entitlements de serviço (classe SVC) usam avisos de expiração mais antecipados — [60, 30, 7] em vez de [30, 7, 1] — porque renovações de contrato exigem maior antecedência. Entitlements de ambiente (classe ENV) adicionam o aviso de 1 dia de volta à lista estendida: [60, 30, 7, 1], pois um ambiente de hospedagem ficar offline é urgente.
Referência rápida: padrões por Entitlement Class
Esta tabela mostra quais policies cada Entitlement Class sobrescreve em relação aos padrões globais:
| Policy | PLG (Plugin) | ENV (Environment) | SVC (Service) |
|---|---|---|---|
| Renewal | -- | -- | precificação current, bloquear downgrade |
| Payment Recovery | 14d suspensão | 15d suspensão | -- |
| Cancellation | 30d visível, 14d expirado, 90d retenção, archive | 30d visível, 15d expirado, 180d retenção | -- |
| SLA | Standard, sem escalonamento | Standard, 99,9% uptime, horário estendido | Priority, horário estendido, 70% escalonamento |
| Credit | -- | -- | FIFO explícito, 30d carência |
| Provisioning | -- | desprovisionamento no cancelamento | Manual, aprovação admin, desprovisionamento |
| Trial | -- | Habilitado, 14d, cartão obrigatório | -- |
| Refund | Auto até R$500/$100 | -- | Janela 0d, créditos proporcionais |
| Tier Change | -- | -- | next_cycle, aprovação admin, 90d cooldown |
| Notification | -- | Avisos 60/30/7/1d | Avisos 60/30/7d |
-- significa que a classe herda o padrão global sem sobrescrita.