Privileged User Management no D365 F&O

 

Acesso privilegiado com prazo de validade e gravação

Oct 10, 2026 · @Francisco

Introdução

O D365 F&O agora permite conceder acesso elevado com horário de início e término e gravar tudo o que o usuário faz nesse intervalo. Isso resolve um dos achados de auditoria mais comuns em projetos de ERP: contas com papéis de administrador ou de gestor financeiro que permanecem ativas "para sempre".

Na prática, alguém sempre precisa de um acesso extra: um key user que vai investigar um problema em produção, um contador cobrindo as férias de um colega, um consultor ajudando no fechamento do mês. O problema não é conceder o acesso, é esquecer de retirá-lo e não ter evidência do que foi feito com ele.

Neste post, mostro como as duas funcionalidades do Security Governance resolvem isso juntas: Temporary role management (acesso com prazo) e Privileged user management (gravação e rastro de auditoria).

As duas peças do Security Governance

As duas funcionalidades são independentes, mas foram pensadas para trabalharem juntas: uma controla o que o usuário pode fazer e por quanto tempo; a outra registra o que ele efetivamente fez.

	Temporary role management	Privileged user management
Objetivo	Atribuir papéis de segurança por um período (sessão)	Gravar a atividade de contas privilegiadas por um período
O que muda no usuário	Os papéis (Merge ou Replace)	O estado da conta (habilitada ou desabilitada)
Duração máxima	Sem limite	24 horas por sessão
Status para liberar o processamento	Planned	Approve
Logs disponíveis	Audit logs, User log, User role change log	Audit logs, User log, Recordings
Ao final da sessão	Usuário volta aos papéis originais	Conta volta ao estado original

Em ambos os casos, só quem tem o papel System administrator cria e aprova as sessões, e é um processo em batch que efetivamente aplica e reverte as mudanças.

Habilitando a funcionalidade

As telas só aparecem depois de ativar a feature User security governance no Feature management:

1. Acesse System administration > Workspaces > Feature management.
2. Pesquise por User security governance.
3. Selecione Enable now.

Com a feature ativa, os dois formulários ficam disponíveis em:

• System administration > Security > Security governance > Temporary role management
• System administration > Security > Security governance > Privileged user management

Dica: antes de usar em produção, valide a feature em um ambiente de sandbox (Tier-2) com a mesma versão da plataforma. Como o processamento depende de batch, vale confirmar se o servidor de batch do ambiente está saudável.

Temporary role management: o acesso com prazo de validade

Uma sessão de papel temporário atribui um conjunto de papéis a um usuário entre uma data/hora de início e uma de fim. Quando a sessão termina, o usuário volta exatamente aos papéis que tinha antes. Casos típicos: cobertura de férias e divisão temporária de uma função entre várias pessoas.

Ciclo de vida da sessão

1. Em Temporary role management, clique em New. O registro nasce com status Draft.
2. Informe o User ID, o tipo de sessão, o início e o fim.
3. Em Assign roles, escolha os papéis temporários. Se o acesso deve valer apenas para algumas empresas, use Assign organizations.
4. Um System administrator aprova mudando o Change status para Planned.
5. O batch processa a sessão (ou o admin clica em Process manualmente). No horário de início, o status passa para Active.
6. Ao fim do horário, os papéis temporários são revogados e o status passa a 'Finished'.

Merge ou Replace?

• Merge soma os papéis temporários aos que o usuário já possui. É o caso mais comum: o usuário continua fazendo o trabalho dele e ainda ganha algo a mais.
• Replace substitui os papéis atuais pelos temporários durante a sessão. Útil quando o usuário vai assumir outra função e não deve acumular acessos (pense na segregação de funções).

Em ambos, ao final, os papéis originais são devolvidos. A aba Original roles mostra o que o usuário tinha antes, o que ajuda na revisão.

Rastreabilidade

• Audit logs: cada mudança de status, quando, por quem e se foi o batch ou um administrador que processou.
• User log: os logins do usuário durante a sessão ativa (e o momento em que a sessão terminou). Logins fora da janela não aparecem aqui.
• User role change log: todas as alterações de papéis realizadas durante a sessão.

Atenção: ao contrário da gravação, não há limite de duração para uma sessão de papel temporário. Cabe ao processo interno definir um teto razoável.

Privileged user management: gravando o que foi feito

O Privileged user management agenda uma sessão para uma conta e, durante essa sessão, grava as interações do usuário na interface por meio do Task recorder. A ideia é ter evidência objetiva, para fins de auditoria e compliance, de que uma conta com poderes elevados não foi usada para nada fora do combinado.

Ciclo de vida da sessão

1. Em Privileged user management, clique em New. O registro nasce como Draft.
2. Informe o User ID e as janelas de início e de fim. A sessão pode durar, no máximo, 24 horas.
3. Defina se a conta deve ser habilitada (se estava desabilitada) ou desabilitada quando a sessão começar. Ao final, a conta volta ao estado original.
4. Um System administrator aprova mudando o Change status para Approve.
5. O batch processa a sessão (ou o admin processa manualmente). Ao fechar a janela, o status passa para Ended.

Consentimento e gravação

Quando o administrador agenda a sessão, o sistema avisa que o Task recorder vai capturar as interações do usuário; seguir em frente significa concordar com a gravação. Do lado do usuário, ao entrar no sistema durante a sessão, aparece uma mensagem de consentimento no topo da página. Se ele continuar usando o F&O, a sessão será gravada; se não concordar, deve fechar a aplicação.

O Task recorder registra o tipo de ação (clique em botão, preenchimento de campo, navegação) e os dados associados a ela. Cada sessão gera uma gravação separada, armazenada na aba Recordings, a partir da qual pode ser baixada. As gravações ficam lá até que alguém as apague manualmente.

Rastreabilidade

• Audit logs: mudanças de status, data/hora, autor e se a aprovação veio do batch ou de um administrador.
• User log: os logins da conta durante a sessão privilegiada, com o tempo gasto em cada um. Nada fora da janela é registrado.
• Recordings: o arquivo do Task Recorder de cada sessão.

A Microsoft recomenda usar o recurso apenas para contas realmente privilegiadas, cada uma com uma função única, e mantê-las desabilitadas quando não estiverem em uso. A opção de habilitar a conta apenas durante a sessão se encaixa exatamente nesse modelo.

Cenário prático: 30 minutos de Accountant, com gravação

Um key user precisa do papel de Accountant por 30 minutos (das 16:00 às 16:30) para investigar um lançamento em produção. A área de controles exige que o acesso seja temporário e que haja evidência de que nenhuma configuração foi alterada.

[embed: node/2c143013-5dea]

As duas sessões correm em paralelo: uma concede e revoga o papel, a outra grava o que acontece no meio.

Passo 1: conceder o papel temporário

Em Temporary role management:

1. Crie um registro e informe o User ID.
2. Escolha Merge para manter os papéis atuais do usuário.
3. Informe início às 16:00 e fim às 16:30.
4. Em Assign roles, inclua Accountant e System user.
5. Mude o status para Planned.

Pegadinha: se o System user não estiver entre os papéis temporários, o sistema retorna um erro ao processar a sessão. Inclua-o sempre.

Passo 2: agendar o batch (uma única vez)

O processamento das sessões depende de um job em batch recorrente. Configure-o uma vez, com recorrência curta (por exemplo, a cada poucos minutos, conforme a precisão de horário de que vocês precisam). A partir daí, ele aplica e revoga as sessões sozinho. Quando a sessão for aplicada, o status muda para Active e o papel aparece na atribuição do usuário.

Passo 3: agendar a gravação

Em Privileged user management:

1. Crie um registro com o mesmo User ID.
2. Defina a janela de gravação, por exemplo, das 16:05 às 16:30.
3. Mude o status para Approve.
4. Se ainda não houver um batch ativo para esse processo, configure-o; se já houver, não é preciso criar outro.

Quando o usuário entrar no sistema dentro da janela, verá o aviso de que a sessão está sendo gravada.

Passo 4: o fim das sessões

Às 16:30, as duas sessões terminam: o registro de papel temporário passa para Finished (o Accountant é removido) e o de gravação passa para Ended. A gravação fica disponível na aba Recordings.

Uma observação de desenho: no exemplo, a gravação começa cinco minutos após o papel. Em produção eu prefiro alinhar as duas janelas, ou começar a gravação antes, para não deixar nenhum minuto de acesso elevado sem registro.

Analisando a gravação com Security diagnostics

O arquivo baixado da aba Recordings pode ser lido no próprio F&O, sem precisar abrir o Task recorder e reproduzir passo a passo:

1. Baixe a gravação em Privileged user management > Recordings > Download.
2. Acesse System administration > Security > Security diagnostics for task recordings.
3. Selecione "Open from this PC", clique em "Browse" e escolha o arquivo.

Após o upload, o sistema lista os pontos de entrada de segurança acionados e as telas visitadas pelo usuário durante a sessão. É esse resultado que fecha o ciclo para o auditor: quem teve o acesso, por quanto tempo e o que fez com ele.

Boas práticas e pegadinhas

• Use os dois juntos. O papel temporário sem gravação reduz o tempo de exposição, mas não gera evidência do uso. Gravação sem papel temporário gera evidência, mas o acesso continua lá depois.
• Inclua o System user nos papéis temporários. Sem ele, o processamento falha.
• Monitore o batch. Se o job parar, as sessões nem começam nem terminam na hora. Um papel que deveria ter sido revogado permanece ativo, o que é justamente o risco que se quer evitar.
• Defina um teto interno para Temporary role management. O produto não limita a duração; a política da empresa deve fazê-lo.
• Mantenha as contas privilegiadas desabilitadas fora das sessões e use a opção para habilitá-las apenas durante a janela de gravação.
• Prefira Replace quando houver conflito de segregação de funções. Se o papel temporário, somado aos atuais, cria um conflito (por exemplo, entre cadastro de fornecedor e liberação de pagamento), substituir é mais seguro do que mesclar.
• Restrinja por empresa com Assign organizations quando o acesso só fizer sentido em uma entidade legal.
• Cuide das gravações. Elas ficam guardadas até que alguém as apague. Defina quem baixa, onde arquiva e por quanto tempo, em conformidade com a política de retenção e com a LGPD/GDPR, já que contêm dados de usuário.
• Avise os usuários antes. A mensagem de consentimento aparece no login, mas comunicar o processo com antecedência evita surpresa e sessões abandonadas.

Conclusão

Com Temporary role management e Privileged user management, o D365 F&O passa a cobrir nativamente o ciclo completo de acesso privilegiado: conceder com prazo, revogar automaticamente e comprovar o que foi feito. Para quem atende a auditorias SOX ou a controles de ITGC, isso substitui planilhas e lembretes manuais por evidências geradas pelo próprio sistema.

O investimento é pequeno: ativar uma feature, agendar um batch e alinhar o processo com a área de controles. O retorno é sair da próxima auditoria sem o clássico achado de "administrador permanente".

Referências

• Privileged user management (Microsoft Learn)
• Temporary role management (Microsoft Learn)
• Privileged User Management in Dynamics 365 Finance and Supply Chain Management, por Dogan Adiyaman

D365F&O - Atualizações via Power Platform

Com a migração da administração do Dynamics 365 Finance and Operations do Lifecycle Services (LCS) para o Power Platform admin center (PPAC), uma das dúvidas mais frequentes é: como ficam os Service Updates, os Quality Updates (PQU) e os hotfixes?

Neste post reúno o que está documentado hoje pela Microsoft (e alguns pontos da comunidade) considerando exclusivamente um ambiente Sandbox criado no Power Platform (USE ou UDE), sem qualquer envolvimento do LCS.

1. O modelo mudou: o F&O agora é uma aplicação

Em ambientes unificados, o Finance and Operations deixa de ser um "ambiente" próprio e passa a ser uma aplicação Dynamics 365 instalada num ambiente Power Platform com Dataverse. Na prática, isto significa que Service Updates e Quality Updates são aplicados pela mesma operação: atualizar a versão da aplicação Dynamics 365 Finance and Operations Provisioning App.

Nomenclatura das versões

No PPAC as versões seguem o formato 10.0.XX.N, onde 10.0.XX é o service update e N indica o nível de PQU incluído.

Versão	Significado	Disponível em
10.0.40.2 (Preview)	10.0.40 com 3 PQUs, build preview	Apenas ambientes com early release cycle
10.0.39.4	10.0.39 com 5 PQUs	Todas as geografias
10.0.38.9	10.0.38 com 10 PQUs	Todas as geografias

Pontos importantes:

• Cada versão disponível já inclui o PQU mais recente daquele service update.
• Não é possível escolher um build anterior de uma mesma versão.
• Builds preview só aparecem em ambientes com early release cycle.

O calendário oficial de PQU já publica o mapeamento entre o build "clássico" e a versão do Provisioning App. Exemplo: o train 10.0.48 Release-6 corresponde ao App version 10.0.2645.136, Platform 7.0.7996.119 e Unified Environment Provisioning Application Version 10.0.48.7.

2. Aplicar manualmente um Service Update ou Quality Update num Sandbox

1. Aceda ao PPAC → Environments → selecione o ambiente.
2. No cartão Resources, clique em Dynamics 365 apps.
3. Selecione Dynamics 365 Finance and Operations Provisioning App → … → Manage.
   Se a opção Manage não aparecer, o ambiente já está na versão mais recente.
4. Confirme o aviso. Na nova página, escolha a versão na lista (só aparecem versões superiores à instalada).
   Se a lista estiver vazia, não submeta o pedido: o ambiente já está atualizado.
5. Aceite os termos e clique em Install. O estado da aplicação passa a Installing; a Microsoft indica cerca de 1 hora de duração.

Acompanhar a operação

Além do painel Details da aplicação, o progresso pode ser acompanhado na app Finance and Operations Package Manager (PPAC → Resources → Power Apps), no separador Operation History.

Via Power Platform CLI (preview)

O grupo de comandos pac dynamics já permite automatizar este processo:

# Listar versões disponíveis para o ambiente
pac dynamics get-fin-ops-versions --environment https://meuambiente.crm4.dynamics.com

# Aplicar uma versão específica (operação de longa duração)
pac dynamics apply-fin-ops-version --version 10.0.47.5 --environment https://meuambiente.crm4.dynamics.com

# Consultar erros recentes de operações
pac dynamics get-fin-ops-operation-errors --environment https://meuambiente.crm4.dynamics.com

3. Service Updates automáticos em ambientes unificados

A Microsoft mantém uma página de calendário específica para ambientes unificados, com o build e a versão do Provisioning App de cada service update. Os clientes com ambientes agendados recebem notificação antes do rollout.

O rollout segue o modelo de estações (o mesmo usado pelos PQUs):

Estação	Regiões
Station 1	Apenas ambientes opted-in
Station 2	Canada Central/East, France Central, India Central, Norway East, Switzerland West
Station 3	France South, India South, Norway West, Switzerland North, South Africa North, Australia East/South East, UK South, UAE North, Japan East, South East Asia
Station 4	East Asia, UK West, Japan West, Brazil South, North Europe, East US, UAE Central
Station 5	West Europe, Central US, West US
Station 6	DoD, GCC, China

Detalhe importante: o service update automático 10.0.48 aplica-se apenas a ambientes em 10.0.46 ou anterior; ambientes já em 10.0.47 ou superior são ignorados. Ou seja, o auto-update atua sobre ambientes que ficaram para trás, e quem se mantém atualizado manualmente não é "empurrado".

E pausar?

O mecanismo de pause service updates documentado é exclusivo do LCS. No PPAC, o controlo disponível são as Maintenance Settings do Finance and Operations. Via CLI, o parâmetro --updated-maintenance-window-cadence do comando pac dynamics update-fin-ops-maintenance-settings aceita os valores EveryUpdate, EveryOtherUpdate e Regulated. Até ao momento, não encontrei documentação no Microsoft Learn que detalhe o comportamento de cada valor no PPAC.

4. Proactive Quality Updates (PQU)

• Mesmo calendário: segundo a Microsoft, não há diferença no agendamento de PQUs entre ambientes unificados e ambientes geridos pelo LCS.
• Cadência quinzenal: a partir da 10.0.47, os PQUs passaram de um ciclo de 28 dias para um ciclo de duas semanas.
• Sandbox primeiro: produção recebe o PQU sempre pelo menos 5 dias depois dos sandboxes.
• Não é possível adiar, reagendar ou pausar um PQU, nem pedir exclusão da cadência quinzenal.
• Aplicação antecipada: é possível instalar um PQU antes do calendário. Em ambientes unificados isso equivale a escolher a versão .N mais alta no Provisioning App. Se o ambiente já tiver um build igual ou superior, o PQU agendado é ignorado.
• PQU ignorado quando existe um service update agendado nos 7 dias seguintes.
• Sem rollback: após aplicado, um PQU não pode ser revertido. Em ambientes unificados, a alternativa prática é trabalhar com cópias/backups do ambiente antes de atualizar.
• Notificações: chegam pelo Message center do Microsoft 365 admin center.

Receber PQUs em dias úteis (apenas produção)

1. PPAC → ambiente de produção → Settings.
2. Em Updates, selecione Maintenance Settings.
3. Na secção Finance and Operations Maintenance Settings, escolha os Maintenance window days.
4. Guarde. (Também é possível via pac dynamics update-fin-ops-maintenance-settings --updated-maintenance-window-days-of-week.)

5. E os hotfixes individuais (KB)?

Este é o ponto com menos documentação. Tudo o que a Microsoft documenta sobre aplicar hotfixes manualmente refere-se ao LCS. No PPAC:

• O Asset library não existe: pacotes ficam no Azure DevOps e são importados diretamente para o Dataverse.
• Não é possível escolher um build anterior de uma versão, nem (segundo a FAQ do UDE) provisionar/atualizar para um runtime update específico.
• Não encontrei documentação oficial que descreva a seleção de um KB avulso num ambiente unificado.

Conclusão prática: em ambientes unificados, o "hotfix" chega sempre como parte do PQU cumulativo seguinte, aplicado automaticamente ou manualmente através do Provisioning App. Se um fix crítico ainda não estiver num PQU, o caminho é abrir um ticket de suporte. A consulta da lista de KBs de um PQU continua documentada apenas via LCS.

6. Outros pontos úteis

• Builds preview: em unified, o acesso é feito através do early release cycle do ambiente (o First Release Program documentado é configurado no LCS).
• Paridade de versões entre ambientes: a Microsoft sugere usar a cópia de ambiente para alinhar um UDE com a versão de um sandbox ou produção. Em ambientes unificados, a cópia leva dados e código, portanto também a versão.
• UDE: as funcionalidades do Unified Developer Experience estão GA a partir da 10.0.39.
• Modo manutenção: ativar o Administration mode no PPAC tem o mesmo efeito do maintenance mode do LCS.

Lacunas atuais na documentação

• A semântica das cadências EveryOtherUpdate e Regulated no PPAC.
• Como consultar a lista de KBs de um PQU sem acesso ao LCS.

Se tiverem experiência com algum destes pontos, deixem nos comentários!

Referências

• Tutorial: Update the Finance and Operations Provisioning app
• Release schedule for service updates (unified environments)
• Release schedule for proactive quality updates
• Proactive quality updates FAQ
• Overview of unified admin experience for finance and operations apps
• Power Platform CLI – pac dynamics
• Unified developer experience FAQ
• Maintenance mode
• LCS to PPAC: Smoothly Transition Your Updates (Anitha Eswaran)

Dynamics 365 Finance & Operations 10.0.49: As novidades que merecem atenção!

D365 Finance & Operations 10.0.49: o que realmente muda no seu dia a dia

Toda nova versão do D365 F&O traz uma longa lista de novidades — mas nem tudo merece o mesmo nível de atenção. Na 10.0.49 (build 10.0.2790), separei o que é só ruído do que vai exigir teste, decisão ou ajuste de processo antes de chegar à produção.

TL;DR: mais automação no financeiro (pré-pagamento por linha, liquidação desacoplada, reconciliação bancária com revisão), planejamento mais preciso no supply chain, classificação dinâmica de trabalho no armazém com Power Fx — e uma mudança de ferramenta para quem desenvolve X++ que não pode ficar para a última semana do projeto.

---

📅 Quando isso chega ao seu ambiente?

Fase	Data
Preview	Julho de 2026
GA (self-update)	Setembro de 2026
GA (auto-update)	Outubro de 2026

Data de disponibilidade não é sinônimo de "ativar tudo no dia seguinte". O caminho seguro continua sendo: sandbox primeiro, integrações revisadas, usuários-chave validando os processos críticos.

---

💰 Financeiro: menos trabalho manual, mais rastreabilidade

Pré-pagamento agora pode ser calculado por linha

Até aqui, a regra de adiantamento valia para o documento inteiro. Agora dá para diferenciar por linha.

Cenário real: equipamento de 100.000 com 30% de adiantamento + instalação de 20.000 com 50% de adiantamento. Antes, uma regra única distorcia um dos dois. Agora, cada linha respeita sua própria condição.

📍 Ativação: Accounts receivable parameters, com Prepayment customer invoice habilitado no Feature management.

Datas contábeis que se ajustam sozinhas

Requisição criada em 30/06, aprovação arrasta até depois do fechamento do período. Em vez de travar o processo, o sistema reprocessa para o próximo período aberto do mesmo ano fiscal e reavalia o orçamento automaticamente.

Menos ping-pong com o financeiro — mas vale confirmar se essa automação bate com a política de períodos e os requisitos de auditoria da empresa.

Reservas orçamentárias com mais controle

Um pacote de melhorias que ataca perguntas que todo controller já fez pelo menos uma vez:

• O compromisso ainda está mesmo aberto?
• Um documento finalizado continua consumindo orçamento por engano?
• Existe alguma relação quebrada entre compromisso e liquidação?
• O fechamento do exercício está sendo respeitado no saldo exibido?

Prioridade alta de teste para quem trabalha com setor público ou governança orçamentária forte.

Pagamento contabilizado, liquidação em fila

Delay settlement from journal posting separa dois momentos que hoje são um só: contabilizar o pagamento e concluir a liquidação. Se o volume travar a liquidação, o pagamento entra mesmo assim — e a liquidação roda depois, automática ou manual.

⚠️ Ganho de continuidade operacional, mas alguém precisa monitorar a fila e tratar os casos que não se liquidam sozinhos.

Reconciliação bancária com um "ok" humano antes de fechar

As regras de correspondência continuam automáticas, mas agora é possível revisar e aprovar o resultado antes de marcar como conciliado. Útil para valores altos, contas sensíveis ou exceções que ninguém quer descobrir depois do fechamento.

De brinde: filtro de transações de bridge por conta bancária, cliente/fornecedor, referência, número de cheque e período — relevante para quem trabalha com alto volume.

Ativos fixos e moeda de reporte

Ajustes de moeda de reporte agora acompanham corretamente divisões de ativos registrados em moeda estrangeira (o recurso de contabilização do ajuste ainda está em preview). Antes de ativar, vale revisar transações antigas, lançamentos não contabilizados e registros zerados em moeda de reporte.

Electronic Reporting fica mais robusto

• Geração nativa de GS1-128, GS1 DataMatrix e GS1 QR Code
• Funções DIV e MOD nas fórmulas
• Respeito ao número de cópias do Print management
• Menor consumo de memória em execuções grandes
• Validação de múltiplas versões de configuração numa única operação, com histórico

DIV(25, 10) = 2 caixas completas · MOD(25, 10) = 5 unidades restantes — simples, mas resolve paginação, agrupamento de volumes e dígitos verificadores.

---

📦 Supply Chain: planejamento mais fino, armazém mais inteligente

Master planning respeita melhor a realidade da produção

Duas melhorias que se somam: consideração de períodos fechados em calendários de transporte e, principalmente, sub-BOM e sub-roteiro entrando na redução de previsão. Resultado esperado: menos excesso de compra e produção quando já existe suprimento no meio do caminho.

📍 Antes de confiar no novo comportamento, rode um cenário de comparação: ordens planejadas, datas e quantidades, antes x depois.

Reserva de matéria-prima presa ao mesmo lote (preview)

Pensado para rastreabilidade em produção — típico caso de indústria alimentícia, onde a ordem precisa consumir de um único lote sempre que o estoque permitir. Testar com regras de validade, localização e disponibilidade parcial é obrigatório antes de ligar em produção.

ASN de entrada vira despatch advice

O aviso antecipado de embarque do fornecedor agora entra como despatch advice, permitindo organizar docas, equipe e conferência antes do caminhão chegar. Ganho direto de produtividade no recebimento.

Uma localização, um proprietário

Nova regra impede múltiplos proprietários numa mesma localização de armazém — importante em operações de terceiros ou consignação. Antes de ativar: audite os saldos atuais, porque dado legado com múltiplos proprietários vai pedir limpeza.

Mapeamento de status de estoque para integrações externas

Um sistema externo manda Available, Blocked, QualityHold — e agora dá para mapear isso direto para os status internos do SCM, com efeito claro em reserva, picking e disponibilidade para venda.

Classificação dinâmica de trabalho com Power Fx

Provavelmente o recurso mais "de engenharia" da lista: uma fórmula Power Fx substitui vários templates estáticos de work classification, decidindo em tempo real pool de trabalho, prioridade, diretiva de localização e classe de trabalho.

Switch(workTable.Load.CarrierCode,
    "Carrier1", {WorkPoolId: "Carrier1", DefaultWorkPriority: 100},
    "Carrier2", {WorkPoolId: "Carrier2", DefaultWorkPriority: 50},
    "Carrier3", {WorkPoolId: "Carrier3", DefaultWorkPriority: 10}
)

Ou, direcionando por zona refrigerada:

{ WorkClassId: Concatenate("S-", workLine.ZoneId) }

Poderoso, mas pede governança: documente as fórmulas, teste os casos sem correspondência e confira se a lógica se encaixa no agrupamento de templates já existente.

E ainda: melhorias incrementais

CAPA, consolidação de transações de estoque, sincronização de estabelecimento em entregas diretas, bloqueio de registros de chão de fábrica após o cálculo diário, escalabilidade de filas do message processor e rastreamento de alterações de preço para o Azure Product Search.

---

⚠️ O que passou a ser obrigatório

Nem tudo é opt-in. Ficaram obrigatórios nesta versão:

• Finance: customer and vendor netting, melhorias de reconciliação bancária, cash position, cash control e diversas validações de pagamento
• Supply Chain: Advanced quality management, integrações do Inventory Visibility, dispense management, recálculo de datas em entregas diretas, recursos de rebates

Isso muda o jogo do planejamento: não basta escolher o que ativar — é preciso mapear o que mudou de comportamento por padrão e testar os processos que dependem disso.

---

✅ Checklist rápido para o projeto

1. Confirme versão atual, canal de atualização e data planejada
2. Inventário de customizações X++, extensões, integrações e ER
3. Separe: novo opcional, ativado por padrão, obrigatório, preview
4. Teste ponta a ponta: compras, vendas, pagamentos, fechamento, produção, planejamento, recebimento
5. Compare master planning antes x depois
6. Teste reconciliação bancária, liquidação em fila e filas de processamento
7. Valide ER: cópias, idiomas, destinos, códigos de barras
8. Teste regras de armazém com transportadoras, zonas e mudança de carga
9. Revise permissões, batch jobs e monitoramento
10. Documente decisões e mantenha um plano de rollback — mesmo em One Version

---

🛠️ Atenção, devs: o Visual Studio muda a partir do PU74

A partir do PU74, o Visual Studio 2022 deixa de ser suportado para desenvolvimento X++ — o ambiente suportado passa a ser o Visual Studio 2026. Isso não é só uma preferência de IDE: máquinas de desenvolvimento, agentes de build, pipelines de CI/CD e extensões precisam ser revisados.

Não deixe essa migração para a última etapa do projeto — ela afeta diretamente a capacidade de compilar, testar e publicar.

---

Conclusão

A 10.0.49 segue a direção que o D365 F&O vem tomando há tempo: mais automação nos controles financeiros, mais inteligência no armazém, mais integração e rastreabilidade. Os ganhos mais claros para a maioria dos projetos estão em pré-pagamento por linha, liquidação desacoplada, reconciliação bancária com revisão, ER otimizado, planejamento mais preciso e classificação dinâmica de trabalho.

Trate a atualização como projeto de negócio, não como aplicação de pacote. Testar os novos comportamentos, preparar os usuários e revisar as integrações vai pesar tanto quanto instalar a versão em si.

---

Fontes

• Microsoft Learn — What's new in Dynamics 365 Finance 10.0.49
• Microsoft Learn — What's new in Dynamics 365 Supply Chain Management 10.0.49
• Microsoft Learn — Classificação dinâmica do trabalho
• Microsoft Learn — Platform updates for version 10.0.49

Fixing "Insufficient privileges" on D365 Finance and Operations Batch SharePoint Connections

D365F&O Tenant Migration

The symptom

While troubleshooting a custom SysOperation batch process that uploads a generated CSV file to a SharePoint document library (via SharePointDocumentStorageProvider) after a Tenant Migration, I ran into an upload failure that looked like this:

Upload failed: Exception has been thrown by the target of an invocation.
Inner: An unknown error occurred while communicating with the SharePoint server '<tenant>.sharepoint.com'.

The exception itself is unhelpful — it's the generic wrapper message that the SharePoint client SDK returns whenever the underlying HTTP call fails, without exposing the actual status code or response body.

The first clue came from Document management parameters (Organization administration > Document management > Document management parameters > SharePoint). This page has two separate connection tests:

• Test interactive SharePoint connection — succeeded
• Test batch SharePoint connection — failed with "You are not authorized to connect to '<tenant>.sharepoint.com'"

That asymmetry was the key diagnostic signal. If the interactive test works but the batch test doesn't, the problem isn't the SharePoint site, the folder path, or the Document Type configuration — it's specifically about how non-interactive (application-only) calls authenticate.

Root cause

Interactive connections use the signed-in user's delegated permissions — essentially riding on the user's existing Microsoft 365 license and SharePoint access, just like a browser session would.

Batch connections are different. Since Microsoft deprecated the old Microsoft-managed high-trust connection between finance and operations environments and SharePoint (this affects environments on version 10.0.40 and later that have SharePoint user authentication enabled), batch jobs authenticate as an application rather than as a user. This means the finance and operations service principal needs its own application-level grant to talk to SharePoint Online — and that grant is not provisioned automatically. A tenant administrator has to assign it manually once per tenant.

If nobody has performed this one-time setup, every batch/non-interactive call to SharePoint — including custom X++ code using SharePointDocumentStorageProvider, and the built-in Export attachments feature — will fail with exactly the vague error shown above, while everything that goes through an interactive user session keeps working fine. This makes the problem easy to misdiagnose as a networking, firewall, or tenant-migration issue when it's actually a missing permission grant.

The fix

The fix is to grant the Microsoft Dynamics ERP first-party service principal an application permission (Sites.ReadWrite.All) against the SharePoint Online first-party service principal, in the target tenant. Both service principals already exist in every tenant that runs finance and operations and SharePoint — there's nothing to register or create.

Option A — PowerShell (Microsoft Graph SDK)

This is Microsoft's documented approach. Run it once, as a Global Administrator (or a role with Application.ReadWrite.All), against the tenant that hosts the finance and operations environment's SharePoint site:

Import-Module Microsoft.Graph.Applications

# Replace with your tenant
Connect-MgGraph -TenantId <yourtenant>.onmicrosoft.com -Scopes 'Application.ReadWrite.All'

# These AppIds are fixed first-party application IDs — they do not change between tenants
$erpServicePrincipal = Get-MgServicePrincipal -Filter "AppId eq '00000015-0000-0000-c000-000000000000'"
$sharePointServicePrincipal = Get-MgServicePrincipal -Filter "AppId eq '00000008-0000-0ff5-ci00-000000000000'"
$spAppRole = $sharePointServicePrincipal.AppRoles | Where-Object { $_.Value -eq 'Sites.ReadWrite.All' }

# Assign the SharePoint 'Sites.ReadWrite.All' application role to the Dynamics ERP service principal
New-MgServicePrincipalAppRoleAssignedTo `
    -ServicePrincipalId $erpServicePrincipal.Id `
    -PrincipalId $erpServicePrincipal.Id `
    -ResourceId $sharePointServicePrincipal.Id `
    -AppRoleId $spAppRole.Id

Option B — Microsoft Graph Explorer (no local PowerShell needed)

If PowerShell isn't installed locally, or a policy restricts running scripts on your machine, the exact same operation can be done through Graph Explorer, signed in as a Global Administrator:

1. Find the Dynamics ERP service principal

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '00000015-0000-0000-c000-000000000000'

Copy the id from the response — this is erpServicePrincipalId.

2. Find the SharePoint Online service principal

GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '00000008-0000-0ff5-ci00-000000000000'

Copy the id — sharePointServicePrincipalId — and, from the appRoles array in the same response, find the entry where "value": "Sites.ReadWrite.All" and copy its id — this is appRoleId.

Note: Graph Explorer's default permission set (User.Read) won't be enough for either of these steps. Under Modify permissions, consent to Application.ReadWrite.All first — as a Global Admin you can grant this directly from the same screen.

3. Grant the permission

POST https://graph.microsoft.com/v1.0/servicePrincipals/{erpServicePrincipalId}/appRoleAssignments

Request body:

{
  "principalId": "{erpServicePrincipalId}",
  "resourceId": "{sharePointServicePrincipalId}",
  "appRoleId": "{appRoleId}"
}

A 201 Created response confirms the grant succeeded.

Verifying the fix

Back in Document management parameters > SharePoint, run Test batch SharePoint connection again. It should now report success, matching the interactive test.

A security note

Sites.ReadWrite.All is a broad grant — it gives the finance and operations application read/write access to every SharePoint site in the tenant, not just the specific document library used by a given integration. There's no officially documented narrower alternative for this particular first-party grant (the more restrictive Sites.Selected model applies to apps you register and control yourself, not to this Microsoft-managed service principal). If your organization has strict least-privilege requirements for SharePoint, this is worth flagging to your security team as an accepted trade-off and revisiting if Microsoft introduces a more granular option in the future.

Conclusion

When a finance and operations environment can reach SharePoint interactively but not from batch, don't waste time chasing networking, DNS, or tenant-migration theories first — check whether the one-time application consent for batch SharePoint access has actually been granted. This step is easy to miss because it doesn't live in D365 F&O at all: it's an Entra ID (Azure AD) application permission that must be granted once per tenant, and there's no button for it in the finance and operations client. Whether you use PowerShell or Graph Explorer, the operation is a single, five-minute application role assignment — but until it's done, every non-interactive SharePoint call from your environment, including custom integrations and the built-in Export attachments feature, will keep failing with the same unhelpful "unknown error" message.