Power Apps offline: como funciona na prática

O app trava quando a operação fica sem sinal#

Todo projeto de campo cedo ou tarde esbarra no mesmo problema: o técnico chega no subsolo do galpão, o vendedor entra na zona rural, o inspetor sobe no navio, e ali não tem 4G nem Wi-Fi. Se o app depende de conexão para gravar cada registro, ele simplesmente para. É nesse ponto que o Power Apps offline deixa de ser um detalhe técnico e vira requisito de negócio. A boa notícia é que dá para operar sem rede. A notícia honesta é que o offline do canvas não é um botão que você liga, é uma arquitetura que você desenha, testa e mantém.

Neste artigo eu mostro como o modo offline realmente funciona no Power Apps: onde os dados ficam guardados no dispositivo, como detectar conexão, como montar a fila de sincronização, como tratar conflitos e onde estão os limites reais. Sem promessa mágica, para você entender o que dá e o que não dá antes de prometer prazo.

O offline do Power Apps é feito de três peças#

Não existe uma "chave offline" no canvas app que resolve tudo. O que existe são funções e propriedades que, combinadas, permitem trabalhar sem rede. São três peças que você precisa conhecer:

Peça	O que faz	Função ou propriedade
Cache no dispositivo	Grava e lê coleções localmente, mesmo com o app fechado	SaveData e LoadData
Detecção de rede	Informa se o dispositivo está online no momento	Connection.Connected
Fila de sincronização	Estrutura que você cria para acumular alterações pendentes	Coleções + Patch / ForAll

O ponto que muita gente não entende no começo: as duas primeiras peças o Power Apps entrega prontas. A terceira, a fila e a lógica de sincronização, é você quem constrói. Não há mecanismo automático de "sincronizar quando voltar a internet" no canvas app padrão. Quem coordena isso é o seu código em Power Fx.

Coleções locais são o coração do offline#

A base de tudo são as coleções em memória. Quando o app está online, você puxa os dados da fonte (Dataverse, SharePoint, SQL, o que for) para uma coleção. Quando fica offline, você trabalha em cima dessa coleção. E para que os dados sobrevivam ao app ser fechado ou o celular reiniciar, você persiste a coleção no armazenamento local do dispositivo com SaveData, recuperando depois com LoadData.

O padrão mais comum é decidir a origem dos dados logo no OnStart ou na tela inicial, conforme a conexão:

// Ao abrir o app, decide de onde vêm os dados
If(
    Connection.Connected,
    // Online: puxa da fonte e atualiza o cache no dispositivo
    ClearCollect(colClientes, Clientes);
    SaveData(colClientes, "cacheClientes"),
    // Offline: lê o que ficou salvo localmente
    LoadData(colClientes, "cacheClientes", true)
)

O terceiro parâmetro do LoadData com valor true significa "ignore o erro se o arquivo ainda não existir". Isso evita que o app quebre na primeira execução, quando ainda não há cache gravado.

Vale saber algumas regras práticas do SaveData e LoadData:

• Eles funcionam no app publicado no celular e no Teams. No player web dentro do navegador o comportamento é limitado, então não conte com offline pleno rodando pelo browser.
• Existe limite de tamanho para o dado persistido, e ele é menor em alguns ambientes. Cache de milhares de linhas com muitos campos e imagens embutidas é pedido de problema. Guarde só o necessário.
• SaveData grava a coleção como está naquele instante. Se você alterou a coleção em memória, precisa chamar SaveData de novo para o dispositivo refletir a mudança.

Connection.Connected diz se há rede, não se a rede é boa#

Para saber se o app está online, você usa a propriedade Connection.Connected, que devolve verdadeiro ou falso. Também existe Connection.Metered, que indica se a conexão é limitada (por exemplo, dados móveis que o usuário paga por volume), útil para você evitar sincronizações pesadas fora do Wi-Fi.

// Guarda o estado da conexão em uma variável para usar na tela
Set(varOnline, Connection.Connected);

// Exemplo de uso: só mostra o botão "Sincronizar agora" quando há rede
// Visible do botão = varOnline

Aqui entra um alerta que evita frustração: Connection.Connected diz se o dispositivo acredita ter conexão, não se ela está funcionando bem. Em sinal fraco, o app pode reportar online e a chamada ao Dataverse falhar. Por isso, tratar erro na sincronização continua obrigatório mesmo quando a propriedade diz que está tudo certo. Confiar cegamente nela para gravar direto na fonte é uma das causas mais comuns de dado perdido.

A fila de sincronização você desenha na mão#

Chegamos na parte que separa um app que "quase funciona offline" de um app confiável. Quando o usuário registra algo sem rede, você não pode gravar na fonte, porque ela está inacessível. Então você guarda essa alteração em uma coleção que funciona como fila de pendências, e persiste essa fila no dispositivo.

// Usuário registra uma visita, mesmo sem rede
Collect(
    colFilaSync,
    {
        IdLocal: GUID(),
        Cliente: DropdownCliente.Selected.Nome,
        Observacao: txtObservacao.Text,
        DataRegistro: Now(),
        Status: "Pendente"
    }
);
// Persiste a fila para não perder nada se o app fechar
SaveData(colFilaSync, "filaSync")

Repare no campo IdLocal com um GUID(). Ele serve para você identificar o registro localmente antes de existir um id oficial da fonte. E o campo Status é o que permite saber o que ainda falta enviar.

Quando a conexão volta, você percorre a fila e envia cada pendência para a fonte. O padrão usa ForAll sobre os itens pendentes com Patch:

// Ao voltar a rede, envia as pendências
If(
    Connection.Connected And CountRows(Filter(colFilaSync, Status = "Pendente")) > 0,
    ForAll(
        Filter(colFilaSync, Status = "Pendente") As item,
        Patch(
            Visitas,
            Defaults(Visitas),
            {
                IdLocal: item.IdLocal,
                Cliente: item.Cliente,
                Observacao: item.Observacao,
                DataRegistro: item.DataRegistro
            }
        )
    );
    // Marca como enviado e regrava a fila
    UpdateIf(colFilaSync, Status = "Pendente", { Status: "Sincronizado" });
    SaveData(colFilaSync, "filaSync")
)

Esse código resolve o caminho feliz, mas tem uma armadilha que precisa ficar clara: o ForAll com Patch não para no primeiro erro e não devolve com facilidade qual item falhou. Se o registro 3 de 10 falhar por qualquer motivo, os outros continuam, e você marcou tudo como sincronizado. Em operação real, faça o envio em lote menor, verifique Errors(Visitas) após a gravação e só mude o Status dos itens que realmente foram aceitos. É trabalho extra, e é justamente esse trabalho que garante que nenhum dado de campo se perca.

Conflitos aparecem quando duas pessoas mexem no mesmo registro#

Offline abre a porta para um problema que o online esconde: dois usuários editam o mesmo registro em momentos diferentes, sem rede, e sincronizam depois. Qual versão vale? O Power Apps não decide isso por você. A estratégia de resolução de conflito é uma escolha de negócio que você implementa. As opções mais usadas:

Estratégia	Como funciona	Quando faz sentido
Último a gravar vence	A última sincronização sobrescreve o que havia	Dados de campo onde só uma pessoa mexe por registro
Registro por data	Compara o carimbo de tempo e mantém o mais recente	Quando há um Modificado em confiável em todos os lados
Mesclar campos	Junta alterações campo a campo em vez do registro inteiro	Formulários longos editados por áreas diferentes
Enviar para revisão	Marca o conflito e deixa uma pessoa decidir	Dados críticos, financeiros ou regulatórios

Na prática, para a maioria dos apps de coleta em campo, cada técnico só edita os próprios registros, e "último a gravar vence" já resolve. Mas se o seu cenário tem várias pessoas mexendo no mesmo dado, assuma que você vai gastar tempo real construindo comparação de versões. Isso não é gratuito e precisa estar no prazo.

Os limites reais do offline no canvas#

Aqui é onde o consultor honesto ganha a confiança do cliente. O offline do Power Apps resolve muita coisa, mas tem teto. Conheça os limites antes de prometer:

• Volume de dados. Cache local grande deixa o app lento e pode estourar o limite de armazenamento. Offline funciona bem para o subconjunto de dados que aquele usuário precisa naquele dia, não para replicar o banco inteiro no celular.
• Delegação continua valendo. As regras de delegação da fonte não somem no offline. Se você depende de filtros que não delegam, vai carregar dados demais ou de menos, e isso piora no cache.
• Relações complexas. Modelos com muitas tabelas relacionadas, cálculos que dependem de dados fora do dispositivo e validações que exigem servidor não cabem bem no offline do canvas.
• Anexos e imagens. Fotos de campo pesam. Guardar muitas imagens na fila local consome espaço rápido e torna a sincronização lenta em conexão fraca.
• Player web. Offline pleno é para o app no celular, não para o navegador.

Quando o cenário é realmente complexo, com sincronização bidirecional pesada e regras de conflito sofisticadas, vale avaliar o offline gerenciado do Dataverse, que automatiza parte dessa mecânica, ou repensar o processo para reduzir o que precisa rodar sem rede. Nem todo problema de campo cabe num canvas app offline construído à mão, e reconhecer isso cedo economiza retrabalho. Se a sua base de dados está desorganizada, o problema começa antes do app, e um trabalho de engenharia de dados resolve mais do que qualquer truque de Power Fx.

Um roteiro para implementar offline sem se enganar#

Se você vai encarar offline, siga uma ordem que reduz surpresa:

1. Defina o mínimo offline. Liste só as telas e ações que precisam funcionar sem rede. Quanto menor o escopo offline, mais confiável o app.
2. Modele a fila antes do resto. Decida os campos de controle (IdLocal, Status, carimbo de tempo) antes de fazer tela.
3. Trate o cache no início. Resolva SaveData e LoadData no carregamento, com LoadData tolerante a arquivo inexistente.
4. Isole a sincronização. Centralize o envio da fila num único fluxo, com tratamento de erro e verificação de Errors().
5. Escolha a regra de conflito. Combine com a área de negócio qual versão vence, e documente.
6. Teste em modo avião de verdade. Simule perda de rede no meio do preenchimento, feche o app, reabra e sincronize.

Esse tipo de app quase sempre faz parte de um conjunto maior de automação e dados. Se você monta a solução completa, vale conectar o offline ao restante da plataforma, e o nosso trabalho de Power Platform existe para isso. Para ver como Power Apps e Power Automate se encaixam de ponta a ponta, o guia de Power Platform 2026 traz o contexto que falta em muitos projetos.

Perguntas frequentes#

O Power Apps sincroniza sozinho quando a internet volta? Não no canvas app padrão. As funções SaveData e LoadData guardam e recuperam os dados no dispositivo, e Connection.Connected avisa se há rede, mas a lógica de enviar a fila para a fonte quando a conexão retorna é você quem escreve em Power Fx. Não existe sincronização automática pronta que resolva a fila por você.

SaveData e LoadData funcionam no navegador? De forma limitada. O offline pleno é pensado para o app publicado no celular ou no Teams. Rodando pelo navegador, o comportamento do cache local é restrito, então não projete uma operação de campo crítica para funcionar offline no browser.

Qual o limite de dados que posso guardar offline? Há um limite de tamanho para o que o SaveData persiste, e ele varia por ambiente. Na prática, cache grande deixa o app lento e pode estourar. Guarde só o subconjunto que o usuário precisa naquele dia, evite imagens pesadas na fila e não tente replicar o banco inteiro no dispositivo.

Como saber se a conexão está boa o suficiente para sincronizar? Connection.Connected diz se o dispositivo acredita estar online, não se a rede está funcionando bem. Em sinal fraco, o app pode reportar online e a gravação falhar mesmo assim. Por isso, sempre trate erro na sincronização e verifique Errors() na fonte antes de marcar um registro como enviado.

Como resolvo conflito quando duas pessoas editam o mesmo registro? Você escolhe a regra. As opções comuns são último a gravar vence, comparar por data de modificação, mesclar campo a campo ou marcar o conflito para revisão humana. O Power Apps não decide isso automaticamente, então defina a estratégia com a área de negócio e implemente na mão.

Todo app de campo cabe no offline do canvas? Não. Cenários com muitas tabelas relacionadas, validações que exigem servidor e sincronização bidirecional pesada podem não caber no offline construído à mão. Nesses casos, avalie o offline gerenciado do Dataverse ou simplifique o processo. Reconhecer o limite cedo evita retrabalho caro.

Fechamento#

O modo offline do Power Apps é totalmente viável, desde que você trate ele como arquitetura e não como configuração. Cache com SaveData e LoadData, detecção com Connection.Connected, fila e conflito desenhados por você: essas são as peças. O erro clássico é prometer offline como se fosse um botão e descobrir a complexidade no meio do projeto. Quem entende os limites antes entrega um app que a operação confia mesmo sem sinal.

Se você quer desenhar uma solução offline confiável ou revisar um app que já está travando em campo, fale com a gente e a gente ajuda a acertar a arquitetura desde o começo.