Para empresas que querem crescer com controle

Um sistema para operar sua empresa com IA.

Vendas, marketing, atendimento, operação, financeiro e inteligência trabalhando sobre o mesmo contexto — para sua empresa ganhar escala sem perder controle.

Sua empresa inteira. Uma operação. IA trabalhando.

Ver a Centriu funcionando

Para empresas de qualquer setor que querem crescer com estrutura, controle e inteligência.

Representação ilustrativa do trabalho em execução

O problema

Sua empresa não deveria operar em pedaços

Não é falta de ferramenta. É que cada ferramenta resolve um pedaço, e ninguém é dono do todo. O custo disso não aparece numa fatura — aparece no mês seguinte.

Sistemas que não se falam
O mesmo dado é digitado de novo — e cada cópia conta uma história diferente.
Dados duplicados
Ninguém sabe qual versão é a verdadeira na hora de decidir.
Conversas perdidas
O cliente repete o contexto a cada canal e a cada pessoa.
Tarefas espalhadas
O trabalho vive em planilhas, mensagens e na memória de alguém.
Decisões sem contexto
A escolha é feita com o recorte que estava à mão, não com o que importava.
Automações desconectadas
Cada ferramenta automatiza um pedaço e ninguém enxerga o todo.

Nenhum desses problemas se resolve comprando mais um software. Eles se resolvem quando a operação inteira passa a trabalhar sobre o mesmo contexto.

A resposta

Tudo trabalha sobre o mesmo contexto.

A Centriu não é uma coleção de produtos. É uma plataforma em que clientes, áreas e agentes leem e escrevem no mesmo lugar.

Cliente 360

Um contexto, não vários cadastros

Cada conversa, tarefa, campanha, cobrança e decisão fica ligada ao cliente e à operação — não a um sistema isolado.

Clientes
Comercial
Atendimento
Operação
Financeiro
Marketing
Inteligência
Agentes
Consultoria

As áreas abaixo são partes da mesma operação, não produtos separados. Elas compartilham conta, permissões e histórico.

IA que trabalha — não um chatbot ao lado

A inteligência artificial da Centriu participa da operação: entende contexto, prepara trabalho, executa rotinas e pede aprovação quando importa.

Entende o contexto

Lê a operação, o cliente e o histórico antes de propor qualquer coisa.

Prepara o trabalho

Redige, organiza, calcula e deixa pronto para revisão humana.

Executa rotinas

Roda o que é repetitivo dentro dos limites definidos pela empresa.

Recomenda a próxima ação

Cruza áreas, identifica prioridade e mostra o motivo da recomendação.

Pede aprovação

O que é sensível passa por uma pessoa antes de valer. Sem exceção silenciosa.

Mantém histórico e aprende

Registra o que aconteceu e usa o resultado para melhorar a próxima decisão.

O que a Centriu faz

Uma plataforma, várias frentes de trabalho. Tudo no mesmo contexto, com a IA participando do que dá para acelerar.

Comercial

CRM, pipeline, oportunidades, propostas, follow-up e automações.

Atendimento

WhatsApp, Instagram, Messenger, chat do site e e-mail no mesmo contexto.

Operação

Tarefas, responsáveis, prazos, aprovações, agenda e capacidade.

Financeiro

Contas, cobranças, caixa, fiscal, margem, IR, orçamento e inteligência econômica.

Marketing

Planejar, produzir, aprovar, publicar e medir conteúdo e campanhas.

Inteligência

Painéis, alertas, previsões, recomendações e leitura executiva.

Agentes

Rotinas executadas continuamente pela IA com controle e aprovação.

Consultoria

Diagnóstico, estratégia, transformação, acompanhamento e especialistas.

Para quem é

Para empresas que querem crescer — e crescer certo.

A Centriu faz sentido quando o volume aumenta e a estrutura precisa acompanhar. Não é sobre setor nem tamanho: é sobre a operação conseguir sustentar o próximo estágio.

As vendas crescem, mas o processo não acompanha.

As áreas trabalham separadas e o cliente sente.

A operação depende de pessoas específicas.

O financeiro ficou complexo e o caixa perde visibilidade.

O atendimento cresce em volume e em canais.

A IA entra sem contexto, controle ou histórico.

Se a empresa ainda não começou a crescer, a Centriu também ajuda a preparar a estrutura para o primeiro salto.

Ver a Centriu funcionando

Consultoria

Tecnologia sozinha não resolve uma operação mal desenhada.

A Centriu combina tecnologia, inteligência, método e acompanhamento. A consultoria diagnostica, desenha, implanta e acompanha — com evidências, não com apresentação.

Diagnóstico e imersão na operação

Estratégia e prioridades

Roadmap de transformação

Desenho da arquitetura operacional

Implantação conduzida

Acompanhamento com evidências

Benchmarking e leitura de mercado

Especialistas, rede e inteligência coletiva

A participação de especialistas depende da solução e do contrato. Não é um item incluído automaticamente em toda contratação, e não prometemos acompanhamento humano ilimitado.

Veja a Centriu funcionando na sua operação

Uma conversa para entender onde a sua operação perde tempo, dinheiro ou capacidade — e o que a Centriu faria primeiro.

Ver a Centriu funcionando

problema

Client Approval Authorization Consistency Automation: Approved On Screen, Still Pending in the Database

Centriu Axis decides who is allowed to approve a client's content in more than one place, and for the single most common case — an approver with no permission explicitly recorded for them yet — two of those places disagreed. The database's own row-level security policy on the approvals table required the permission to be explicitly recorded as true; absent it, the rule denied. The edge function's own copy of the identical rule used the opposite default: absent meant allowed. A client approver who had never had that specific permission explicitly configured for them — the code's own comments name this as the ordinary case for anyone invited before the granular permissions panel existed — could click "Approve," have the browser's own write silently matched to zero rows by the stricter rule, and still see a success confirmation, because the code that handles a genuine zero-row race between two approvers used the exact same, silent, no-error path for a denied write. The post's real status never changed. The fix replaces both independent copies of the rule with one predicate function, called by the database policy directly and by every edge function through a shared helper using the same identity — one resolved default, and a denied approver now gets a real, visible refusal instead of an indistinguishable false success.

Quero resolver isso

A rule written twice agrees on almost everything, and diverges on exactly the case nobody was watching

Two independently written copies of the same authorization rule rarely disagree on the easy cases — a master account is always allowed, a disabled team member is always denied, an unrelated client is always denied. Where two independent copies of a rule actually diverge is the edge case each author had to make a judgment call about without a specification to point to: what happens when the specific permission being checked was simply never recorded for this person at all. One author reasonably reads silence as "nothing was granted, so deny." Another, just as reasonably, reads the same silence as "nothing was ever taken away, so allow" — especially for a person who was invited before the fine-grained permission screen existed to record anything at all. Both readings are defensible in isolation. Only one of them can be correct once the exact same person hits both rules in the same afternoon.

Two independently written copies of the same authorization rule rarely disagree on the easy cases — a master account is always allowed, a disabled team member is always denied, an unrelated client is always denied. Where two independent copies of a rule actually diverge is the edge case each author had to make a judgment call about without a specification to point to: what happens when the specific permission being checked was simply never recorded for this person at all. One author reasonably reads silence as "nothing was granted, so deny." Another, just as reasonably, reads the same silence as "nothing was ever taken away, so allow" — especially for a person who was invited before the fine-grained permission screen existed to record anything at all. Both readings are defensible in isolation. Only one of them can be correct once the exact same person hits both rules in the same afternoon.

Quero resolver isso

How a click that looked like it worked left the real status untouched — and the single predicate that ends the disagreement

The approval screen's own "Approve" and "Reject" buttons wrote directly from the browser to the underlying approvals table, protected only by the database's row-level security policy — no edge function sat between the click and the write. That policy's rule, confirmed directly from the fix's own inline comment describing the exact behavior it replaces, required the specific approval permission to be recorded as explicitly true; if it was never recorded at all, the policy treated the write as unauthorized and matched it to zero rows, exactly as row-level security is designed to do.

A separate authorization check, written independently inside the edge function used for the same product's calendar and deliverable decisions, encoded the identical underlying rule — but resolved the exact same "never recorded" case the opposite way: absent meant allowed, on the reasoning that an approver invited before a permissions panel even existed to record anything should not lose access purely because nobody ever explicitly re-confirmed it. Both readings appear in the product's own code comments as deliberate, reasoned decisions — made independently, at different times, by different code paths, with no shared function connecting them.

The consequence surfaces at exactly the point these two disagree: a client approver with the permission never explicitly recorded either way clicks "Approve" on the direct-write screen. The database policy denies the write and returns zero affected rows — no exception, no error, because a genuine zero-row result is also exactly what a legitimate, benign race between two people approving the same item at once looks like, and the calling code's own comment says as much: an update affecting no rows means someone else already won that race, so do nothing further and don't show an error. The screen's own success handler, which fires whenever the underlying request resolves without throwing, has no separate check distinguishing those two cases — it shows the same confirmation either way. The approver sees "Post approved successfully." The post's actual status never moved past pending.

The fix collapses both independent copies of the rule into one: a single predicate function that takes an organization and a client, and returns whether the calling, authenticated identity is allowed to approve for that pairing. The database's own security policy calls it directly. Every edge function calls the identical function too, through a small shared helper that authenticates as the CALLER (not as an administrative service account), so the database resolves the exact same identity the exact same way regardless of which code path asked. The unrecorded-permission case is now decided once, consistently, in the direction the edge function already used — an approver invited before permissions existed keeps working. And because decisions now run through dedicated functions that check this same predicate explicitly and raise a stated, human-readable refusal when it fails, a genuinely denied approver gets an actual, visible error message instead of a silent, indistinguishable false success.

Ver como funciona

What is actually built today

One predicate function decides who may approve content for a given organization and client — called directly by the database's own row-level security policy, with no separate copy of the logic living anywhere else in the database layer.
Every edge function that needs the same answer calls that identical function through a shared helper, authenticated as the calling user's own identity — not a separate, independently maintained mirror of the rule.
The one case that previously diverged — no permission ever explicitly recorded for a given approver — now resolves the same way everywhere: permitted by role, matching what the edge function already did before this fix.
A denied approval attempt now raises an explicit, stated refusal from inside the decision function itself, rather than silently matching zero rows the way a direct database write always could.
A JavaScript fallback mirrors the same rule for the narrow window before the underlying database function exists in a given environment, so a mid-rollout deploy cannot silently block every approval outright.
No change to who is DENIED under either previous rule's strict reading — master accounts, active staff, a client's own recognized approvers, and legacy client logins are still exactly who is authorized; the fix closes the one case where the two rules genuinely disagreed.

Conhecer os recursos

What changes operationally

Centriu Axis's database security policy and every edge function that decides who may approve content now call the identical predicate function, authenticated as the same calling identity either way — closing a gap where the single most common unrecorded-permission case resolved two different ways depending on which code path handled the click, and where a denied write on one of those paths was visually indistinguishable from a genuine success.

Centriu Axis's database security policy and every edge function that decides who may approve content now call the identical predicate function, authenticated as the same calling identity either way — closing a gap where the single most common unrecorded-permission case resolved two different ways depending on which code path handled the click, and where a denied write on one of those paths was visually indistinguishable from a genuine success.

Quero esses resultados

A confirmation toast, and a post that never moved (illustrative framing of the actual measured finding)

A client contact, added as an approver before the agency's team ever opened the fine-grained permissions screen for that account, opens their approval queue and clicks "Approve" on a post. Before the fix, the click resolves without error, a "Post approved successfully" message appears, and the queue refreshes — while, underneath, the database's own security rule silently rejected the write because no explicit permission had ever been recorded for that specific approver, and the calling code's own race-condition handling treated the zero-row result as a normal, silent non-event. The post remains pending, invisibly, until someone else — staff, an admin, or an approver whose permission happens to be explicitly recorded — eventually approves it through a different path. After the fix, the identical click is evaluated by the one shared predicate, resolves as permitted (matching the edge function's own long-standing default for this exact case), and the post's status genuinely changes.

Conversar sobre meu caso

Como começar

Começar agora

Perguntas frequentes

Could a real approver have seen a success message without actually approving anything?

Yes — an approver with no explicit permission recorded either way could have the database silently reject the write while the interface's own success handler still fired, because a resolved request with zero affected rows and a database-level denial looked identical from the browser's side.

Why did two different rules disagree on the same account?

The database's security policy and the edge function's own copy of the rule were written independently, at different times, and made two different, individually reasonable choices about what an unrecorded permission should default to.

What is the single fix?

One predicate function now decides who may approve, called directly by the database's own security policy and by every edge function through a shared helper using the caller's real identity — there is no longer a second, independent copy of the rule anywhere.

What happens now when someone is genuinely not allowed to approve?

The decision function raises an explicit, stated refusal instead of a database write silently matching zero rows — a denial is now visible, not indistinguishable from a coincidental success.

Did this change who is allowed to approve content?

Only for the one case that previously disagreed — an approver with nothing explicitly recorded is now treated consistently as an approver by role, matching what the edge function already did; every explicitly recorded permission, in either direction, is unchanged.

What does Centriu Axis cost?

It is sold by subscription with a published starting price — exact current values are on the central pricing page.

Ainda tenho dúvida

See how Centriu Axis keeps approval authorization consistent end to end

Quero resolver isso