Assinatura com RLS no envio

Selo de estado: Preview (teto atual do produto) · Curso ACD-340 — Publicação, distribuição, RLS e BI-as-code · Aula 5 de 8 · Atualizado em 2026-10-04.

Objetivo#

Ao final desta aula você vai configurar assinatura semanal.

Vídeo#

Identificador no manifesto: acd-340-05-assinaturas-email-whatsapp · duração-alvo 6 min · tela do produto: /dashboards.

Roteiro (capítulos):

1. 00:00–01:00 — O que é uma assinatura e por que ela não é um export manual.
2. 01:00–03:00 — Configurar a assinatura por e-mail: destinatários, frequência e formato (/dashboards/[id]/compartilhar).
3. 03:00–04:30 — RLS por destinatário: soma com o filtro, nunca amplia; o link some quando há filtro de linha.
4. 04:30–05:30 — WhatsApp Cloud API: template aprovado e consentimento.
5. 05:30–06:00 — Erros comuns e encerramento.

Conteúdo#

Uma assinatura resolve um problema diferente do export manual da Aula 4: em vez de alguém lembrar de exportar toda semana, o dono do painel agenda o envio — dia da semana e horário — e um dispatcher (que roda a cada 5 minutos) cuida do resto. O e-mail que chega traz os KPIs principais, um link para o painel e, opcionalmente, o XLSX anexado. É pensado para a diretoria que não entra na plataforma, mas quer o número toda segunda de manhã sem pedir para ninguém.

Como aparece no produto. A configuração mora na mesma tela de Compartilhar (/dashboards/[id]/compartilhar) das Aulas 2 e 3, numa aba de assinatura: você escolhe os destinatários, a frequência (dia da semana + hora) e o formato do envio. Qualquer viewer que já tenha permissão de ver o painel também pode criar sua própria assinatura self-service, para o que ele já vê — não precisa ser admin para assinar algo que já tinha acesso. A assinatura pode ser pausada sem ser apagada, e cada envio gera um registro no ledger de entrega (estado, tentativas, fila de reprocesso), para você conseguir auditar se um disparo realmente saiu.

O ponto que mais gente esquece — e que o produto garante de propósito — é que a RLS por destinatário atravessa o envio. O filtro da assinatura soma com a RLS de quem vai receber; ele nunca amplia o que a pessoa já tem direito de ver. E quando a RLS do destinatário já filtra linhas, o link dentro do e-mail é suprimido — porque um link aberto poderia, em teoria, ser usado para navegar além do recorte que o e-mail mostrou, então o produto prefere não incluí-lo nesse caso.

Para WhatsApp, o canal oficial é a Cloud API da Meta: um número e uma conta comercial (WABA) do próprio produto, dentro dos Termos da Meta, com um template aprovado para abrir a janela de 24h e o consentimento explícito do destinatário antes do primeiro envio. Existe um gateway alternativo (Z-API, não-oficial) mantido só como fallback deprecated — o caminho recomendado é sempre o oficial.

Exemplo Aurora. maria configura a assinatura "Resumo semanal" de "Vendas por filial" para toda segunda às 8h, com ana@example.com (analista) entre os destinatários. Como o perfil de ana tem o atributo uf = "SP" (da RLS da Aula 3), o e-mail que chega para ela não traz RJ nem MG, mesmo que a assinatura em si tenha sido configurada "para o painel inteiro" — a RLS do perfil dela estreita o que o envio mostra, nunca o contrário. Como o perfil de ana já tem filtro de linha, o e-mail dela também não inclui o link clicável para o painel — só os números e, se configurado, o anexo.

Erros comuns. O primeiro é achar que, ao configurar a assinatura, o e-mail já está sendo entregue de verdade — a entrega real depende do domínio de e-mail transacional estar verificado em produção; em ambiente de treino, o envio costuma ser simulado, e é isso que você deve esperar ver. O segundo é tentar mandar um alerta por WhatsApp sem template aprovado ou sem o consentimento do destinatário registrado — a mensagem simplesmente não sai, porque o canal oficial exige as duas coisas antes do primeiro envio, e isso não é um bug, é o desenho de conformidade do canal. O terceiro é estranhar o link ausente num e-mail e achar que é erro, quando na verdade é a supressão de link por causa de RLS — a leitura, nesse caso, está correta.

Estado do produto. A lógica da assinatura por e-mail — agendamento, RLS por destinatário, supressão de link, registro no ledger — é GA-candidato, coberta por testes determinísticos. Mas a entrega real (o e-mail de fato chegando) é Preview, porque depende do domínio Resend estar verificado em produção, uma pendência conhecida. O WhatsApp é Preview por completo: depende de credencial da Cloud API e de template aprovado, e a entrega real também não é medida hoje. Assinatura self-service pelo próprio viewer (sem o dono precisar criar) está no Roadmap.

Faça você mesmo#

No workspace de treino Aurora Varejo (abra /dashboards no console):

1. Abra "Vendas por filial" em Compartilhar e crie uma assinatura por e-mail chamada "Resumo semanal".
2. Adicione ana@example.com como destinatário, com frequência semanal (um dia + horário).
3. Se ana@example.com tiver um atributo de RLS configurado (da Aula 3), confirme nas opções da assinatura que o filtro dela se mantém — a assinatura não deve oferecer um jeito de contornar a RLS do destinatário.
4. Dispare (ou aguarde) o envio e confira o registro no ledger de entrega — estado da tentativa, não necessariamente "entregue" em ambiente de treino.
5. Pause a assinatura e confirme que ela some da fila de próximos disparos sem ser apagada.
6. Reative a assinatura.

Você terminou quando conseguir explicar por que o e-mail de uma pessoa com RLS configurada chega sem o link clicável para o painel.

Checagem rápida#

Três perguntas no final da aula, corrigidas no servidor. A aula só conta como concluída depois da checagem.

Documentação relacionada#

• bi/exportacao-distribuicao

Capacidades ensinadas#

C08.3 · C08.6 — o selo exibido na aula é sempre o estado mais conservador entre as capacidades citadas; nada aqui é "GA".