Power Automate + SharePoint: como corrigir o erro “The required field data type is not supported” ao carregar outputs dinâmicos (coluna Client)

Ao montar um fluxo no Power Automate que lê ou grava numa lista do SharePoint, você pode se deparar com o erro “The required field ‘Client’ data type is not supported”. Neste guia prático, explico por que isso ocorre, como diagnosticar e todas as formas de corrigir — da mais simples à mais robusta.

Índice

Sintoma e mensagem de erro

Failed to retrieve dynamic outputs… API ‘sharepointonline’ operation ‘GetTable’… BadRequest…
“The required field ‘Client‘ data type is not supported”.

Na prática, o designer do Power Automate não consegue montar o esquema dinâmico (os “campos dinâmicos” que aparecem na UI) da lista porque a coluna Client é obrigatória e tem um tipo não suportado pelo conector quando o campo é exigido.

Por que isso acontece

Quando você configura ações como Get items, Create item ou Update item, o conector do SharePoint tenta “ler” a definição da lista para exibir os campos dinâmicos. Se durante essa leitura existir uma coluna obrigatória do tipo “complexo” (ou multi‑valor) que o conector não consegue representar na UI, o carregamento do esquema falha e os outputs dinâmicos simplesmente não aparecem.

Tipos de coluna que mais causam o erro

A seguir, um panorama prático do risco por tipo de coluna quando marcada como Obrigatória:

Tipo de coluna	Suporte na UI do conector	Risco quando é Obrigatória	Observações úteis
Pessoa/Grupo (multi‑valor)	Parcial	Alto	Melhor converter para valor único; multi exige payload com `results` e IDs de usuário.
Pesquisa/Lookup (multi‑valor)	Parcial	Alto	UI falha com frequência; prefira lookup de valor único ou atualize via HTTP.
Metadados geridos (Taxonomia)	Limitado	Alto	Requer formato específico (TermGuid/Label); para UI é fonte comum de falhas.
Localização / Geolocation	Limitado	Médio	Estrutura de objeto; difícil para o dynamic schema quando obrigatório.
Múltiplas linhas de texto com “Acrescentar alterações”	Limitado	Médio	Histórico de versão torna o campo especial; evite torná‑lo obrigatório.
Imagem/Anexo como obrigatório	Limitado	Alto	Arquivos exigem outra ação; não combine com obrigatoriedade na mesma etapa.
Pessoa/Grupo (valor único)	Bom	Baixo‑médio	Suporta bem, mas ainda pode falhar se houver validações adicionais.
Pesquisa/Lookup (valor único)	Bom	Baixo‑médio	Usável; use o sufixo `Id` no JSON ao atualizar via HTTP.
Escolha (um valor) / Texto de uma linha	Ótimo	Baixo	Tipos mais previsíveis para a UI e para validação.

Correções rápidas (da menos intrusiva à mais invasiva)

Tornar a coluna `Client` não obrigatória e recarregar o esquema

No SharePoint, abra Configurações da lista → Colunas, edite Client e defina como Não obrigatório.
No fluxo, remova a ação do SharePoint que falha e adicione novamente (isso força o recarregamento do esquema).
Se a ação for Get items, em Advanced options experimente Limit columns by view apontando para uma vista que não contenha Client. Em muitos cenários isso evita o erro de UI.
Guarde o fluxo, feche e reabra o designer (alguns caches do esquema só atualizam após novo carregamento).

Alterar o tipo da coluna para uma variante suportada

Pessoa/Grupo: troque para valor único (desative “Permitir múltiplas seleções”).
Pesquisa/Lookup: troque para valor único.
Taxonomia: quando possível, substitua por Escolha (um valor) ou Texto de uma linha com validação no app.
Múltiplas linhas de texto com histórico: desative “Acrescentar alterações ao texto existente” ou converta para Texto de uma linha se fizer sentido.

Nota: se mudar de multi‑valor para valor único, valide os dados existentes e comunique o impacto às equipas envolvidas.

Manter o tipo atual, mas contornar via HTTP (sem depender de outputs dinâmicos)

Quando a coluna precisa permanecer “complexa” e obrigatória, use a ação Send an HTTP request to SharePoint para criar/atualizar itens diretamente via REST. Assim você não fica refém da UI de campos dinâmicos.

Atualizar Pessoa/Lookup (valor único)

Method: POST
Uri: api/web/lists/getbytitle('NOMEDALISTA')/items(IDDOITEM)
Headers:
  IF-MATCH: *
  X-HTTP-Method: MERGE
Body:
{
  "ClientId": 15
}

Atualizar Pessoa/Lookup (multi‑valor)

Method: POST
Uri: api/web/lists/getbytitle('NOMEDALISTA')/items(IDDOITEM)
Headers:
  IF-MATCH: *
  X-HTTP-Method: MERGE
Body:
{
  "ClientId": { "results": [15, 27] }
}

De onde vêm os IDs? Do próprio SharePoint (ID do utilizador ou do item de origem). Você pode obtê‑los com ações como Get item/Get items (quando já tem a entidade em mãos), com o conector de perfis (Get user profile) combinado com o endpoint ensureuser do SharePoint, ou ainda lendo a lista de origem.

Evitar dependência de UI com “Select Query” e expressões

Mesmo sem outputs dinâmicos, em Get items use Select Query para listar apenas os campos necessários (excetuando o problemático) e na expressão aceda às propriedades com item()?['InternalName']. Isso permite continuar o desenvolvimento enquanto a UI do designer não carrega o esquema completo.

Coluna auxiliar para desacoplamento

Crie uma coluna de apoio, por exemplo Client_Text (Texto), e use‑a no fluxo. A coluna Client fica reservada para o SharePoint/Power Apps. Um processo posterior (Power Apps, outro fluxo ou lógica de backend) faz a sincronização, convertendo texto em ID de usuário/lookup.

Se “tabelas” significar Excel no SharePoint

Se você estiver a usar Excel guardado no SharePoint:

Confirme que o intervalo está formatado como Tabela do Excel e que a tabela tem um Nome simples.
Evite imagens, objetos ou células mescladas na coluna Client.
Prefira cabeçalhos sem caracteres especiais e sem espaços no início/fim.
Recrie a tabela, se necessário, e atualize a ação de Excel para forçar o recarregamento do esquema.

Checklist prático de diagnóstico

☐ Em Definições da lista → Colunas, verifique o tipo de Client e se é Obrigatória.
☐ Se for multi‑valor (Pessoa/Lookup) ou Taxonomia, altere para valor único ou para Texto/Escolha.
☐ Guarde as alterações, remova e adicione novamente a ação no fluxo.
☐ Se não puder mudar o tipo/obrigatoriedade, utilize a ação HTTP com o payload adequado.
☐ Confirme o nome interno da coluna (na URL de edição, parâmetro Field=...) e use esse nome no JSON.
☐ Em Get items, avalie Limit columns by view ou Select Query para excluir a coluna problemática.
☐ Guarde o fluxo, feche e reabra o designer para limpar cache de esquema.

Como obter os IDs certos para Pessoa/Lookup

Pessoa/Grupo (Id do utilizador SharePoint)

Se você tem o e‑mail/UPN, use o endpoint ensureuser via HTTP para obter o Id SharePoint e depois grava‑lo no campo ClientId.
Ao copiar dados de outra lista, o Id já estará no campo lookup de origem (SomeUserFieldId); reutilize‑o.

Pesquisa/Lookup

Use o Get items na lista de origem e pegue o ID do item que deseja referenciar; grave em ClientId (ou ClientId.results para multi).

Boas práticas de modelagem para evitar o erro

Evite colunas complexas como Obrigatórias quando o fluxo depender da UI de “campos dinâmicos”. Prefira torná‑las opcionais e validar no app.
Centralize regras de negócio: deixe o SharePoint “simples” (Texto/Escolha), e aplique lógica no Power Apps/Power Automate.
Planeie os nomes internos: crie colunas com nomes sem espaços; o “nome interno” é fixado na criação e facilita JSON e OData.
Isolar anexos: trate uploads de arquivo em ações dedicadas; não crie “campos obrigatórios de anexo”.
Use vistas e Select Query para controlar colunas retornadas por Get items e reduzir atritos com o schema dinâmico.

Exemplos de payloads para atualizar campos complexos

Cenário	Campo de destino	JSON (Body)	Notas
Pessoa/Grupo (valor único)	`Client` (interno: `ClientId`)	`{ "ClientId": 15 }`	15 é o ID de usuário no SharePoint, não o e‑mail.
Pessoa/Grupo (multi)	`Client` (interno: `ClientId`)	`{ "ClientId": { "results": [15, 27] } }`	Use a coleção `results` com inteiros.
Lookup (valor único)	`Client` (interno: `ClientId`)	`{ "ClientId": 42 }`	42 é o ID do item na lista referenciada.
Lookup (multi)	`Client` (interno: `ClientId`)	`{ "ClientId": { "results": [42, 87, 103] } }`	Formato idêntico ao de Pessoa/Grupo multi.
Texto de várias linhas (sem histórico)	`ClientDetails`	`{ "ClientDetails": "Descrição..." }`	Evite o modo “Acrescentar alterações” se for obrigatório.

Exemplo de atualização completa com HTTP

Ação Get items ou outra origem para obter ID do item.
Ação Send an HTTP request to SharePoint: Site Address: <seu site> Method: POST Uri: _api/web/lists/getbytitle('NOMEDALISTA')/items(@{variables('ItemId')}) Headers: IF-MATCH: * X-HTTP-Method: MERGE Body: { "ClientId": @{variables('ClientUserId')}, "Title": "@{triggerOutputs()?['body/Title']}" }
Trate erros com Configure run after e registe a resposta do HTTP para auditoria (status, body).

Perguntas frequentes

Mudar a vista resolve sempre?

Não. Limit columns by view ajuda a reduzir a carga no retorno de dados, mas o erro ocorre em muitos casos durante a leitura do schema da lista, antes mesmo de considerar a vista. Ainda assim, é um paliativo útil e low‑impact.

É um “bug” do Power Automate?

É mais uma limitação do sistema de dynamic schema dos conectores. A abordagem via HTTP existe justamente para cobrir essas lacunas.

Preciso recriar o fluxo?

Quase nunca. Na maioria dos casos, tornar a coluna opcional, recarregar a ação, ou alternar o tipo para uma variante suportada já resolve. Quando não for possível, o caminho HTTP contorna o problema.

Posso continuar sem outputs dinâmicos?

Sim. Construa com expressões (item()?['InternalName']), use Select Query e/ou HTTP. É menos “point‑and‑click”, mas é robusto e previsível.

Procedimento recomendado para casos críticos

Diagnostique a coluna Client: tipo e obrigatoriedade.
Teste rapidamente tornar “Não obrigatória” e recarregar o esquema no fluxo.
Se a modelagem exige complexidade, defina a estratégia:
- Curto prazo: HTTP para gravações, Select Query para leituras, expressões no lugar de campos dinâmicos.
- Médio prazo: converter para valor único (Pessoa/Lookup) ou substituir por Texto/Escolha.
- Longo prazo: coluna auxiliar (Client_Text) e sincronização controlada.
Implemente logs e tratamento de erros no fluxo (respostas do HTTP, condições e scopes com run after).

Conclusão

O erro “The required field ‘Client’ data type is not supported” é um clássico choque entre um esquema de lista “rico” e as limitações de UI do conector do SharePoint no Power Automate. A solução passa por simplificar (tornar opcional ou ajustar o tipo), reduzir a superfície (vistas e Select Query) ou assumir o controlo completo via REST (Send an HTTP request to SharePoint). Com os passos e exemplos acima, você consegue desbloquear o desenvolvimento agora e ainda estruturar a lista para evitar a recorrência do problema.

Observação: a resposta original que motivou este artigo apontava apenas para discussão em fórum. As ações compiladas aqui trazem soluções práticas, com caminhos testados para corrigir e contornar a falha na geração de outputs dinâmicos.