Francisco Silva Jr. - Microsoft Dynamics

D365F&O PPAC e o Planning Optimization Add-in for Dynamics 365 SCM

2026-10-21T06:40:40.424-07:00

Aos que já utilizam o F&O via PPAC e também o Planning Optimization...

Após mover o banco de dados de um ambiente para outro, esse recurso não é reconfigurado automaticamente. Verificando nas configurações do Master Planning no F&O, você verá o status "Not Connected":

Com este status, o job não será executado.

Tive que abrir um chamado na Microsoft para solicitar a reinstalação do Add-in, já que, como sabemos, não temos como removê-lo pelo PPAC.

A resposta foi rápida e até simples. Eu realmente não pensei nesta possibilidade em momento algum!

A solução é ir ao make.powerapps.com, selecionar o seu ambiente e remover a solution de nome "master planning anchor":

Depois de removê-la do make.powerapps.com, volte ao PPAC e instale o Add-in novamente em seu ambiente:

Agora o status no F&O muda para connected:

Tudo pronto para testar os trabalhos em lote do seu Master Plan!

A documentação disponibilizada não especifica que podemos desinstalar um add-in. Eu não sabia disso, aprendi hoje!

A fonte oficial foi o chamado na Microsoft!

O link fornecido por eles é este:

Cause 2: Connection lost after a database refresh

A solução apresentada acima foi enviada por e-mail. Não consta no link da Microsoft.

"Em primeira mão é só aqui, oh páh!"

Taming D365 F&O Storage: Finding Files in the Database and Cleaning Them Up

2026-10-14T01:03:25.414-07:00

Most Dynamics 365 Finance and Operations environments store far more files than anyone planned for. Some stay under a few GB; others pass 500 GB or even 1 TB of file and database consumption. This post gathers, in one place, how to find out where those files live, how to clean them up with standard and custom routines, and how to move them out of the expensive storage tiers.

Why this matters now

Storage capacity for finance and operations apps is reported and enforced in the Power Platform admin center (PPAC). Each environment shows two numbers under Resources > Capacity > Finance and Operations:

Metric	What it measures
Finance and operations database usage	Size of the environment’s Azure SQL database, including large container (BLOB) and memo fields
Finance and operations file usage	Files kept in the Microsoft-managed Azure Blob Storage behind the environment (usually shown as `AXDB.File`)

Database capacity is the scarcer and more expensive of the two. A file that sits inside a database table counts against it. The same file in blob storage counts as file capacity, and the same file in SharePoint or your own Azure Storage Account does not count against F&O capacity at all.

The database usage figure has a table-level drill-down in PPAC. That drill-down is the single most useful starting point for everything below.

Before you start. Every environment is different: version, localizations, ISV solutions, customizations, integrations and legal retention rules all change the picture. Menu paths, table names and field values in this post reflect what I have seen and what Microsoft documents at the time of writing. Items marked Verify are not confirmed for every version and must be checked by the professional responsible for each customer, in a sandbox, before anything is changed or deleted in production.

Where a file can live in F&O

Location	How it is stored	Counts against
Database	A container (BLOB) field in a table, for example `DocuValue.File` when a document type uses Location = Database, or any standard or custom table with a binary field	Database capacity
Azure storage (Microsoft-managed blob)	The file is in the environment’s blob storage; the database keeps only a pointer (DocuRef/DocuValue)	File capacity
SharePoint Online	The file is in a SharePoint library; the database keeps only a pointer	SharePoint storage, outside F&O capacity
Your own storage (custom)	The file is in an Azure Storage Account or DMS you own, reached through an integration; F&O keeps a URL or reference	Your Azure or DMS subscription

Two practical rules come out of this table:

“Azure storage” in document management means the Microsoft-managed blob of the environment, not a Storage Account in your subscription. As far as I know, F&O has no standard option to point document management at your own Storage Account. Verify for the version you run.
A large container field anywhere, standard or custom, is effectively a file inside the database, even when document management is never involved.

Part 1 – Finding files in the database

Work in a sandbox with a recent copy of production. You will need System administrator access in F&O, PPAC access to the capacity pages, and SQL access to the sandbox database (just-in-time access for Tier-2+ sandboxes, direct access on development environments). Never run heavy diagnostic queries against production.

A good order of work:

Export the PPAC table drill-down for database usage and note the 30 largest tables.
Run the table-size query below in the sandbox and compare it with PPAC.
Go through the seven areas in this section.
Record each finding (source, tables, MB, database or blob, proposed action, owner).

Start here: the largest tables and their LOB space

SELECT TOP 50
       t.name AS table_name,
       SUM(CASE WHEN p.index_id IN (0,1) THEN p.rows ELSE 0 END) AS row_count,
       SUM(a.total_pages) * 8 / 1024.0 AS total_mb,
       SUM(CASE WHEN a.type = 2 THEN a.total_pages ELSE 0 END) * 8 / 1024.0 AS lob_mb
FROM sys.tables t
JOIN sys.partitions p ON p.object_id = t.object_id
JOIN sys.allocation_units a ON a.container_id = p.partition_id
GROUP BY t.name
ORDER BY total_mb DESC;

lob_mb (LOB_DATA allocation units) is the space used by large fields: containers, memos and XML. A table with a high lob_mb is a strong candidate for “files hidden in the database”. Sandbox numbers can differ slightly from PPAC because of indexes and compression; use PPAC as the official figure and SQL to find the cause.

1. Document management (attachments)

This is the most common source, especially in environments upgraded from AX 2012, where old attachments may arrive with their binary still inside DocuValue.

In F&O:

Organization administration > Document management > Document types: for each type note Class (Attach file, Attach URL, Simple note), Group and Location. Any type with Class = Attach file and Location = Database sends files into the database.
Document management parameters: check the allowed file types, any file size limit, and the SharePoint tab.
Active document tables: which tables users can attach to.
Check the document types other features use: Electronic reporting parameters, print archive, vendor invoice automation, ISV solutions and custom integrations.

Key tables: DocuType (types and location), DocuRef (link to the business record: RefTableId, RefRecId, TypeId, ValueRecId) and DocuValue (file name, StorageProviderId, AccessInformation and the FILE_ container).

StorageProviderId = 0 means database and 1 means Azure storage. SharePoint uses another value, often reported as 2. Verify: run the first query below to see which values actually exist in your environment.

-- Where attachments live and how much sits inside the database
SELECT v.STORAGEPROVIDERID,
       COUNT(*) AS files,
       SUM(CAST(DATALENGTH(v.FILE_) AS BIGINT)) / 1048576.0 AS mb_in_database
FROM DOCUVALUE v
GROUP BY v.STORAGEPROVIDERID;

-- Which source tables and years hold the most attachments
SELECT t.NAME AS source_table,
       YEAR(r.CREATEDDATETIME) AS year_created,
       v.STORAGEPROVIDERID,
       COUNT(*) AS files,
       SUM(CAST(DATALENGTH(v.FILE_) AS BIGINT)) / 1048576.0 AS mb_in_database
FROM DOCUREF r
JOIN DOCUVALUE v ON v.RECID = r.VALUERECID
LEFT JOIN TABLEIDTABLE t ON t.ID = r.REFTABLEID
GROUP BY t.NAME, YEAR(r.CREATEDDATETIME), v.STORAGEPROVIDERID
ORDER BY files DESC;

-- Orphan DocuValue rows (no DocuRef pointing to them)
SELECT COUNT(*) FROM DOCUVALUE v
WHERE NOT EXISTS (SELECT 1 FROM DOCUREF r WHERE r.VALUERECID = v.RECID);

Verify: the column is usually FILE_ because File is a reserved word (sp_columns 'DOCUVALUE' confirms it). TABLEIDTABLE maps table IDs to names in the versions I have used; if it is not available, use SQLDICTIONARY with FIELDID = 0. Rows with STORAGEPROVIDERID = 1 and a filled FILE_ suggest binaries duplicated in the database, which I have seen after migrations.

2. Print archive and print management

Every SSRS report printed with the Archive destination keeps a copy. With high volumes of invoices, confirmations and packing slips, this grows quickly and has no standard automatic cleanup.

Organization administration > Inquiries and reports > Print archive: filter by date and report to see the monthly volume.
Print management per module (for example Accounts receivable > Setup > Forms > Form setup > Print management): which documents include Archive.
Print destination settings saved on batch jobs, which can archive without going through print management.
The archive’s files are attachments of PrintJobHeader; run the source-table query above and look for that table.

3. Electronic reporting (ER)

ER keeps its files permanently: templates, files sent to the Archive destination and outputs of ER jobs. Unlike Data management, there is no automatic retention; a file is deleted only together with the record it is attached to (Microsoft Learn).

Electronic reporting parameters > Attachments: the document types used for configurations, job archive, temporary files and others, and their Location.
Electronic reporting destination: formats with Archive enabled.
Electronic reporting jobs: volume and age of jobs (table ERFormatMappingRunJobTable and its attachments).
Old, unused configuration versions also keep their templates.

4. Data management framework (DMF)

DMF keeps package files in the managed blob, but its staging tables and execution history live in the database. High-frequency recurring integrations can push staging and log tables to tens of GB.

Job history volume per day and project, and the Job history cleanup settings.
Projects that could use Skip staging.
Recurring data jobs and their frequency; export projects whose packages nobody downloads.
Tables to measure: all *Staging tables, DMFDefinitionGroupExecution, DMFDefinitionGroupExecutionHistory, DMFExecution, DMFStagingLog, DMFStagingLogDetail, DMFStagingExecutionErrors, DMFStagingValidationLog.

5. Email, batch, alerts and logs

Several standard features write binaries or large payloads straight into container fields.

Table	What it holds	Where to look in F&O
SysOutgoingEmailTable / SysOutgoingEmailData	Body and attachments of every email sent by the email distributor (invoice PDFs, for example)	System administration > Periodic tasks > Email processing > Email history
SysEmailHistory	Email history	Email parameters / View email history
BatchJobHistory / BatchHistory	Batch history and infolog	System administration > Inquiries > Batch jobs
EventInbox / EventInboxData	Alerts and notifications	Alerts
SysDatabaseLog	Database log (audit of changes)	System administration > Inquiries > Database > Database log
HcmPersonImage, CompanyImage	Photos and logos	Workers / Legal entities

-- Email attachments per year
SELECT YEAR(e.CREATEDDATETIME) AS year_created,
       COUNT(DISTINCT e.EMAILITEMID) AS emails,
       SUM(CAST(DATALENGTH(d.DATA) AS BIGINT)) / 1048576.0 AS attachment_mb
FROM SYSOUTGOINGEMAILTABLE e
LEFT JOIN SYSOUTGOINGEMAILDATA d ON d.EMAILITEMID = e.EMAILITEMID
GROUP BY YEAR(e.CREATEDDATETIME)
ORDER BY year_created;

-- Every binary column in the database
SELECT t.name AS table_name, c.name AS column_name, ty.name AS data_type
FROM sys.columns c
JOIN sys.tables t ON t.object_id = c.object_id
JOIN sys.types ty ON ty.user_type_id = c.user_type_id
WHERE ty.name IN ('varbinary', 'image')
ORDER BY t.name;

For each relevant table returned, measure the real volume with SUM(CAST(DATALENGTH(<column>) AS BIGINT)).

6. Localizations and electronic invoicing

Localizations with electronic fiscal documents (Brazil, Mexico, Italy, India and others) store submitted XML, authority responses and events. They may be attachments or long text (nvarchar(max)) fields in localization tables. Check the electronic document submission log, the document types used by electronic invoicing, and the long-text columns in country-specific tables. Removing anything here depends on legal retention rules, which differ per country and per company: this is a decision for the tax team, not only for IT.

7. Customizations and integrations

In environments with hundreds of GB, the cause is often custom code: integration logs that keep the full payload of every call, custom log tables without retention, or attachments created automatically for each processed record.

In the metadata, look for container fields (AxTableFieldContainer) and unlimited string fields used for payloads.
In X++, look for DocumentManagement::attachFile, direct DocuRef/DocuValue inserts, BinData, con2Buf, MemoryStream written into table fields, and tables named *Log, *Payload, *Request, *Response.
Cross the results with the table-size query using your model’s table prefix.

Get-ChildItem -Recurse -Filter *.xml -Path .\<YourModel>\AxTable |
  Select-String -Pattern 'AxTableFieldContainer' |
  Select-Object Path -Unique

Part 2 – Cleanup routines

Cleanup in F&O deletes data permanently; there is no recycle bin. Microsoft’s own guidance is to run cleanup routines only after the business has confirmed the data is no longer needed, and to test each one in a non-production environment first (Microsoft Learn). The retention periods below are starting points for discussion, not recommendations for any specific company.

Document management

There is no standard retention policy for attachments. Reduction comes from four directions:

Limit what comes in. Keep only the file types the business uses, set a size limit if your version offers one, and switch any Attach file document type with Location = Database to Azure storage or SharePoint. The change applies to new attachments only.
Clean orphans. The batch job Scan for orphaned document references finds attachments whose business record no longer exists and creates Deletes a bundle of orphaned document references jobs to remove them. Check under System administration > Inquiries > Batch jobs that it exists and recurs. Verify the job names and behavior in your version.
Watch deferred deletion. If attachment recovery (deferred deletion) is enabled, deleted attachments are kept for a number of days and keep consuming space until then. Verify whether your version has this setting and how it is configured.
Apply retention by document type. For attachments with no value after a period (delivery photos, integration files, generated PDFs), agree a rule per document type and source table and implement a custom batch job (pattern in Part 3).

Print archive

Prevent: remove the Archive destination from documents that are already emailed and logged, can be reprinted from the journal, or are stored in a DMS or tax portal. Review print destination settings saved on batch jobs too.
Clean: in Organization administration > Inquiries and reports > Print archive, filter by date and delete. Deleting the record removes its attached file. For large volumes, use a custom batch job or a third-party tool that adds a print archive cleanup (Docentric AX, for example, offers one in its free edition; evaluate any third-party option yourself).

Electronic reporting

Prevent: keep the Archive destination only for formats that really need a copy inside F&O. Use a SharePoint document type for the job archive if files must be kept long term.
Clean: in Electronic reporting jobs, filter by date and format, export the list as evidence and delete. Attached files are removed with the jobs. Remove configuration versions that are no longer used, keeping at least the current and the previous version.

Data management

Since September 2023, job history and related staging data older than 90 days are deleted automatically. For a shorter retention, use the Execution history cleanup feature; the old Staging cleanup routine is deprecated (Microsoft Learn).

In the Data management workspace, open Job history cleanup, set the number of days, the maximum execution hours per run and, if needed, export history before deleting. Schedule it daily, outside business hours.
Use Skip staging where the entity and the process allow it.
Review the frequency of recurring data jobs and fix entities that fail repeatedly.

Email, batch, alerts and logs

Routine	Path (may vary by version)	What it removes
Email history retention	Email parameters: Number of days to retain email history, plus the batch job SysEmailHistoryCleanupBatch	SysEmailHistory
Sent email cleanup	No standard routine in many versions; Microsoft support has suggested a custom X++ script	SysOutgoingEmailTable, SysOutgoingEmailData
Batch job history clean-up	System administration > Periodic tasks	BatchJobHistory, BatchHistory, BatchConstraintsHistory
Batch job clean-up	System administration > Periodic tasks	Finished batch jobs
Notification clean up	System administration > Periodic tasks	EventInbox, EventInboxData
Database log clean up	System administration > Inquiries > Database > Database log	SysDatabaseLog

For sent emails, delete only those already sent, never queued or failed ones, and test in a sandbox first. For the database log, also review Database log setup: auditing high-volume transactional tables is a common cause of growth. Records with electronic signatures cannot be deleted by the standard routine.

Sources for the email items are Microsoft support articles KA-23493 and KA-23879 on the Dynamics community site. Verify the parameter names and batch class in your version.

Functional history routines

They do not remove files, but they often clear the tables at the top of the PPAC drill-down. All need approval from the process owner.

Module	Examples
Sales and procurement	Sales update history cleanup, Order events cleanup, Purchase update history cleanup
General ledger and projects	Clean up ledger journals, Delete project journals (posted journals can no longer be reversed afterwards)
Inventory	Inventory journals cleanup, On-hand entries cleanup, Transfer order update history cleanup
Warehouse	Work creation history, Wave processing history, Mobile device activity log, Work user session log, Work exceptions log
Production and costing	Production orders cleanup, Clean up registrations, Clean up the costing sheet cache
Master planning	Plan version cleanup (monthly, while MRP is not running)

Some routines, such as Inventory dimensions cleanup and Inventory journal data correction, delete data without any log. Use them only with a clear reason and after testing.

A starting schedule

Adjust frequency and retention to the policy each customer approves.

Routine	Frequency	Starting retention
DMF job history cleanup	Daily	7–30 days for recurring integrations, up to 90 for manual loads
Batch job history clean-up	Daily	30–90 days
Email history	Daily	30–90 days
Sent emails (custom)	Weekly	Around 90 days
Notification clean up, batch job clean-up	Weekly	30 days
Orphaned document references	Daily or weekly	—
Print archive, ER jobs, old attachments	Monthly	Per document type and legal requirement
Database log	Monthly	As agreed with audit
Functional routines	Monthly or quarterly	As agreed with each process owner

For the first cleanup of a large volume, work from the oldest data forward, in slices (one year at a time, for example), outside period-end closing, and record the space released in PPAC after each slice.

Part 3 – Moving files out of the database and to your own storage

There are two different moves, and it helps to keep them apart:

Database → managed blob or SharePoint, which converts database usage into file usage (or SharePoint storage).
Managed blob → storage you own, which takes files out of F&O capacity altogether.

Option 1: SharePoint for new attachments (standard)

Set the document type’s Location to SharePoint. New files go to SharePoint Online; existing ones do not move by themselves. Current requirements include granting Sites.ReadWrite.All to the Microsoft Dynamics 365 finance and operations application in Entra ID, because the older Microsoft-managed connection has been deprecated, and avoiding SharePoint managed-device policies, which block the integration (Microsoft Learn). SharePoint storage has its own cost and governance; it is simply outside F&O capacity.

Option 2: migrate database attachments to Azure storage

For attachments with StorageProviderId = 0 and a filled FILE_: change the document type’s Location so the database stops growing, then run a custom batch job that reads each container, stores the file again through the document management API, updates the pointer, and clears the binary. Validate samples (open migrated attachments in F&O) before clearing anything, and run by year or document type.

Option 3: export to your own Azure Storage Account (custom)

This is the pattern I would consider for large legacy volumes. It is a design outline, not a tested product; each customer’s security, legal and access requirements will shape the details.

Select attachments by document type, source table, age and storage provider.
Read the content with the document management API (for example DocumentManagement::getAttachmentStream; Verify the method available in your version).
Send the stream to an Azure Storage Account the customer owns, ideally through an intermediary such as an Azure Function or Logic App using Managed Identity, so no storage keys live in F&O.
Use a deterministic path, for example <company>/<table>/<year>/<RecId>_<filename>.
Confirm the upload (size or hash) before deleting anything.
If users still need access, replace the attachment with a URL-type attachment that points to an endpoint issuing short-lived access (a short SAS, for example). Never store a long-lived SAS in a URL.
Delete the original attachment through DocuRef.delete() so the managed file is removed too.
In the Storage Account, use Cool or Archive tiers with lifecycle rules, and immutability for documents under legal retention.

A custom cleanup batch pattern (X++)

The skeleton below shows the shape of a SysOperation batch job that deletes attachments by document type, source table and age. It is illustrative and untested: review, compile and test it in your own environment, and adapt it to the tables you need (PrintJobHeader, ERFormatMappingRunJobTable, SysOutgoingEmailTable and custom logs follow the same idea).

// Illustrative only - review, compile and test before any use.
class XXXAttachmentCleanupService extends SysOperationServiceBase
{
    private const int CommitSize = 500;

    public void process(XXXAttachmentCleanupContract _contract)
    {
        DocuRef     docuRef;
        TableId     refTableId = tableName2Id(_contract.parmRefTableName());
        utcdatetime cutOff     = DateTimeUtil::addDays(DateTimeUtil::utcNow(),
                                                       -_contract.parmRetentionDays());
        int         maxRecords = _contract.parmMaxRecords();
        int         total, inBlock;

        if (_contract.parmRetentionDays() <= 0)
        {
            throw error("Retention must be greater than zero.");
        }

        if (_contract.parmSimulate())
        {
            select count(RecId) from docuRef
                where docuRef.TypeId          == _contract.parmDocuTypeId()
                   && docuRef.RefTableId      == refTableId
                   && docuRef.CreatedDateTime <  cutOff;
            info(strFmt("Simulation: %1 attachments would be deleted.", docuRef.RecId));
            return;
        }

        do
        {
            inBlock = 0;
            ttsbegin;
            while select forupdate docuRef
                where docuRef.TypeId          == _contract.parmDocuTypeId()
                   && docuRef.RefTableId      == refTableId
                   && docuRef.CreatedDateTime <  cutOff
            {
                // Optional: export to your own storage first (see Option 3)
                docuRef.delete();   // standard logic also removes DocuValue and the stored file
                inBlock++;
                total++;
                if (inBlock >= CommitSize || (maxRecords && total >= maxRecords))
                {
                    break;
                }
            }
            ttscommit;
        }
        while (inBlock >= CommitSize && (!maxRecords || total < maxRecords));

        info(strFmt("%1 attachments deleted.", total));
    }
}

Principles that matter more than the code itself:

Delete through the table’s delete() method. delete_from with skipDeleteMethod, skipDataMethods or direct SQL removes the row but can leave the file behind as an orphan in blob storage.
Commit in blocks, cap records per run, offer a simulation mode, and log what was removed.
New custom tables should be born with a retention parameter and a cleanup job; integration logs should keep a summary, not the full payload.

Governance and monitoring

Cleanup is easier to get right when the roles are clear:

Role	Responsibility
Business process owner	Approves the retention period for each kind of data
Tax / finance	Confirms legal retention and where the legally valid copy lives
F&O administrator	Configures and schedules the batch jobs
Developer	Builds custom cleanup and fixes customizations that create volume
Power Platform administrator	Follows capacity in PPAC

A light monthly routine keeps the problem from coming back:

Record database and file usage for each production environment in PPAC.
Compare the 20 largest tables in the drill-down with the previous month.
Confirm every cleanup job ran successfully.
After each sandbox refresh, rerun the attachment queries by year and source table.

Useful warning signs: growth of more than a few percent a month without a business reason, any new growth in attachments stored in the database, failed cleanup jobs, or a custom table entering the top 20.

Checklist

What to verify in your own environment

These points are based on experience and community sources rather than on official documentation for every version. Treat them as hypotheses to confirm:

Item	Why it needs checking
`StorageProviderId` values beyond 0 and 1 (SharePoint)	Values may differ; query your own data
Column and helper table names (`FILE_`, `TABLEIDTABLE`)	Physical names can change between versions
Menu paths and routine names	Microsoft moves and renames items; use page search
Orphaned attachment jobs and deferred deletion	Availability and behavior depend on version and features enabled
Email cleanup parameters and batch class	Based on Microsoft support articles, not core documentation
Third-party tools mentioned	Evaluate licensing, support and fit yourself
X++ sample	Illustrative and untested
Retention periods suggested	Starting points only; legal and business rules decide

Closing note

There is no single right answer for every customer. One environment’s problem is a print archive nobody cleaned for five years; another’s is a custom integration log keeping every payload; a third simply has a document type still pointing at the database since the AX 2009/2012 upgrade. Measure first, agree retention with the people who own the data, automate the cleanup, and keep watching the numbers.

If you have found other sources of growth, or other ways to deal with them, I would like to hear about them.

Sources

Privileged User Management no D365 F&O

2026-10-10T14:21:51.456-07:00

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:

Acesse System administration > Workspaces > Feature management.
Pesquise por User security governance.
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

Em Temporary role management, clique em New. O registro nasce com status Draft.
Informe o User ID, o tipo de sessão, o início e o fim.
Em Assign roles, escolha os papéis temporários. Se o acesso deve valer apenas para algumas empresas, use Assign organizations.
Um System administrator aprova mudando o Change status para Planned.
O batch processa a sessão (ou o admin clica em Process manualmente). No horário de início, o status passa para Active.
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

Em Privileged user management, clique em New. O registro nasce como Draft.
Informe o User ID e as janelas de início e de fim. A sessão pode durar, no máximo, 24 horas.
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.
Um System administrator aprova mudando o Change status para Approve.
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:

Crie um registro e informe o User ID.
Escolha Merge para manter os papéis atuais do usuário.
Informe início às 16:00 e fim às 16:30.
Em Assign roles, inclua Accountant e System user.
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:

Crie um registro com o mesmo User ID.
Defina a janela de gravação, por exemplo, das 16:05 às 16:30.
Mude o status para Approve.
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:

Baixe a gravação em Privileged user management > Recordings > Download.
Acesse System administration > Security > Security diagnostics for task recordings.
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

D365F&O - Atualizações via Power Platform

2026-09-30T06:18:30.697-07:00

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

Aceda ao PPAC → Environments → selecione o ambiente.
No cartão Resources, clique em Dynamics 365 apps.
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.
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.
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)

PPAC → ambiente de produção → Settings.
Em Updates, selecione Maintenance Settings.
Na secção Finance and Operations Maintenance Settings, escolha os Maintenance window days.
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

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

2026-08-25T03:54:03.983-07:00

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

Confirme versão atual, canal de atualização e data planejada
Inventário de customizações X++, extensões, integrações e ER
Separe: novo opcional, ativado por padrão, obrigatório, preview
Teste ponta a ponta: compras, vendas, pagamentos, fechamento, produção, planejamento, recebimento
Compare master planning antes x depois
Teste reconciliação bancária, liquidação em fila e filas de processamento
Valide ER: cópias, idiomas, destinos, códigos de barras
Teste regras de armazém com transportadoras, zonas e mudança de carga
Revise permissões, batch jobs e monitoramento
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

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

2026-08-11T04:08:03.018-07:00

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.

Fim do suporte ao Visual Studio 2022 para X++: o que muda com o PU74

2026-08-11T03:58:43.888-07:00

A Microsoft confirmou uma mudança relevante para quem desenvolve em X++ no Dynamics 365 Finance & Operations: a partir do Platform Update 74 (versão 10.0.49), o Visual Studio 2022 deixa de ser suportado para desenvolvimento em X++. A partir desse ponto, o Visual Studio 2026 passa a ser a única IDE suportada.

Se você mantém pipelines de build, VMs de desenvolvimento (Tier 1) ou CHEs para clientes, este é o momento de começar a planejar a transição — não a semana antes do upgrade.

O que a Microsoft anunciou

Na documentação oficial de Platform Updates da versão 10.0.49, na seção de melhorias de "Developer tools", a Microsoft declara que, a partir do PU74, o Visual Studio 2022 deixa de ser suportado para desenvolvimento em X++ e que apenas o Visual Studio 2026 passa a ter suporte.

Não é uma depreciação gradual como aconteceu no passado com versões mais antigas do Visual Studio (2015, 2017, 2019) — é um corte direto: uma versão sai, a outra entra.

Cronograma oficial

De acordo com a página de "Platform updates for version 10.0.49", o cronograma é o seguinte:

Fase	Data
Preview de release	Julho de 2026
Disponibilidade geral (self-update)	Setembro de 2026
Disponibilidade geral (auto-update)	Outubro de 2026

Ou seja: quem faz self-update já pode ser impactado a partir de setembro de 2026. Quem depende do ciclo automático da Microsoft será atualizado em outubro de 2026, independentemente de estar ou não preparado.

Quem é afetado (e quem não é)

É importante deixar claro o escopo dessa mudança:

Afeta: desenvolvedores X++, VMs de desenvolvimento Tier 1, ambientes CHE/UDE usados para build e debug, pipelines do Azure DevOps que compilam pacotes X++.
Não afeta diretamente: usuários finais da aplicação. Ninguém vai notar nada na tela do ERP no dia a dia — a mudança é inteiramente do lado das ferramentas de desenvolvimento.

Isso significa que o impacto é silencioso até o dia em que alguém tentar compilar em uma VM ainda rodando VS2022 após o upgrade para 10.0.50/PU74 — e a extensão simplesmente não funcionar mais.

O que fazer antes do upgrade

Algumas ações recomendadas para quem tem PU74 no roadmap deste ano:

Inventariar ambientes de desenvolvimento. Levante todas as VMs Tier 1, CHEs e UDEs atualmente utilizadas para desenvolvimento em X++ em seus projetos e clientes.
Planejar a instalação do Visual Studio 2026 nessas máquinas antes da janela de upgrade, para evitar descobrir o problema no meio de um go-live.
Revisar pipelines de build no Azure DevOps. Agentes de build hospedados (self-hosted) que compilam pacotes X++ também dependem da toolchain do Visual Studio — vale confirmar se o agente aponta para a versão correta.
Para ambientes CHE: considerar reprovisionar a VM de desenvolvimento assim que a Microsoft atualizar as imagens base para incluir o Visual Studio 2026, em vez de tentar fazer upgrade in-place da IDE.
Comunicar a mudança à equipe de desenvolvimento com antecedência — principalmente em times distribuídos por vários países e fusos horários, em que nem todo mundo acompanha as notas de release da Microsoft.

Por que isso importa

Esse tipo de mudança tende a pegar times desprevenidos justamente porque é "invisível" até o momento do upgrade. Diferente de uma feature nova que aparece na tela e gera perguntas dos usuários, uma mudança de toolchain de desenvolvimento só aparece quando alguém tenta compilar — e, nesse ponto, já é tarde para planejar com calma.

Para consultorias e squads que atendem múltiplos clientes e ambientes (como costuma ser o caso em rollouts multipaís), vale incluir essa checagem no checklist de pré-upgrade padrão, junto com os itens de sempre: backup, testes de regressão, DBSync, etc.

Fonte oficial

A informação está documentada oficialmente pela Microsoft em:

Platform updates for version 10.0.49 of finance and operations apps https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/fin-ops/get-started/whats-new-platform-updates-10-0-49

Vale a pena também acompanhar a página de release notes do Visual Studio 2026 para novidades da própria IDE: https://learn.microsoft.com/en-us/visualstudio/releases/2026/release-notes

Este post faz parte da cobertura de novidades da plataforma Dynamics 365 Finance & Operations aqui no blog. Se você está planejando o upgrade para PU74 e quer trocar experiências sobre a transição de ambientes de desenvolvimento, deixe um comentário.

GlobalUpdate script for service model: MROneBox on machine

2026-07-07T22:25:10.174-07:00

Agentes de IA no D365 F&O: Como eles facilitam o trabalho no dia a dia?

2026-05-26T02:08:25.028-07:00

Agentes de IA no D365 F&O: casos práticos do dia a dia

IA & Automação · D365 F&O

Agentes de IA no D365 F&O: como eles facilitam o trabalho no dia a dia

Maio 2026 · Leitura rápida (~3 min)

Os agentes de IA chegaram ao Dynamics 365 Finance & Operations para ficar — e estão a mudar a forma como as equipas financeiras e operacionais trabalham. Ao contrário de simples chatbots, estes agentes analisam dados, tomam decisões dentro de limites definidos e executam ações com mínima intervenção humana.

💡 Em termos simples: os agentes funcionam como um colaborador júnior que trata do trabalho rotineiro de forma autónoma e só escala para revisão humana quando surge uma exceção ou situação fora do padrão.

Investimentos em IA agentica no D365 F&O — 2026 Release Wave 1 (Fonte: Microsoft Learn)

🤖 Casos práticos: o que os agentes fazem por si hoje

Veja exemplos concretos de como os agentes de IA atuam em módulos do D365 F&O no dia a dia:

💳 Pagamento automático de faturas (Payflow Agent)

O problema: processar manualmente filas de pagamento consome horas e está sujeito a erros.

O que o agente faz: monitoriza a fila de pagamentos, identifica faturas prontas para pagar, verifica os dados bancários do fornecedor face ao mestre de dados, executa o processamento e lança os lançamentos contabilísticos — tudo sem intervenção humana para transações dentro da política definida.

✅ Resultado: redução de 70–80% no esforço manual em contas a pagar, segundo dados da Microsoft.

📄 Captura e correspondência de faturas (AP Automation)

O problema: equipas de AP a rever manualmente centenas de faturas por semana.

O que o agente faz: lê faturas em PDF, extrai os dados, faz a correspondência com as ordens de compra, aprende com as correções do utilizador ao longo do tempo, e encaminha automaticamente para aprovação com base nos limites configurados.

✅ Resultado: redução de 60–70% no processamento manual de faturas, com acuidade crescente a cada ciclo.

🔁 Reconciliação contabilística automática

O problema: o encerramento de período exige dias de reconciliação manual entre razão auxiliar e razão geral.

O que o agente faz: cruza automaticamente saldos do razão auxiliar com o razão geral, aplica regras de tolerância e lógica fuzzy para matches complexos (1-para-muitos e muitos-para-muitos), e sinaliza apenas as exceções para revisão humana.

✅ Resultado: encerramento de período mais rápido com a equipa focada apenas nos casos de exceção reais.

📬 Cobranças e gestão de recebíveis (AR Collections)

O problema: acompanhar clientes em atraso manualmente, sem priorização inteligente.

O que o agente faz: prioriza as atividades de cobrança com base no perfil de risco do cliente, gera comunicações de cobrança personalizadas, faz seguimento de faturas vencidas e recomenda estratégias de resolução com base no histórico de pagamento.

✅ Resultado: menos dias de vendas em crédito (DSO) e equipas de AR focadas nos clientes de maior risco.

📦 Planeamento de procura com Copilot (Supply Chain)

O problema: planificadores a analisar manualmente variações de procura sem contexto suficiente.

O que o agente faz: o Copilot analisa planos de procura em linguagem natural — o planificador seleciona um ponto no gráfico e pergunta ao Copilot "Quais os principais fatores que causaram este desvio?" e recebe a resposta imediatamente, com explicação dos drivers.

✅ Resultado: decisões de reabastecimento mais rápidas e com contexto — caso real documentado pela Microsoft com a Domino's Pizza UK.

🏭 Operações de armazém mais inteligentes

O problema: rotas de picking ineficientes e reequilíbrio de stock manual entre armazéns.

O que o agente faz: otimiza automaticamente as rotas de picking, deteta potencial rotura de stock e desencadeia workflows de compra, e o agente financeiro atualiza as projeções de fluxo de caixa em tempo real — tudo de forma coordenada.

✅ Resultado: menor tempo de deslocação em armazém, maior precisão no inventário e cumprimentos mais rápidos.

💬 Consultas em linguagem natural (Copilot + MCP)

O problema: controllers e CFOs dependentes de relatórios pré-definidos ou de apoio IT para obter dados específicos.

O que o agente faz: com a integração MCP da Wave 1 2026, é possível perguntar diretamente: "Qual o saldo de AP em aberto por fornecedor para faturas com mais de 45 dias?" — e receber dados estruturados e precisos, sem SQL nem navegação em menus.

✅ Resultado: autonomia de dados para equipas de gestão sem dependência de IT ou report builders.

🧠

Da automação reativa à operação agêntica

Os agentes de IA no D365 F&O observam, decidem e atuam — escalando apenas o que realmente precisa de atenção humana.

Operação agentica no ERP: do trabalho manual à automação inteligente (Fonte: Microsoft Dynamics 365)

Os agentes de IA no D365 F&O não substituem as equipas — libertam-nas para trabalho de maior valor. O objetivo é simples: o sistema trata do rotineiro, e as pessoas focam-se no estratégico. Com a 2026 Release Wave 1, esta visão está a tornar-se realidade módulo a módulo.

📚 Fontes e leituras complementares

🔗 Visão geral de Copilot e agentes no D365 Finance & Operations (Microsoft Learn)

🔗 D365 Finance 2026 Release Wave 1 — plano completo (Microsoft Learn)

🔗 D365 Supply Chain Management 2026 Release Wave 1 (Microsoft Learn)

🔗 Análise de planos de procura com Copilot — guia prático (Microsoft Learn)

🔗 O que são agentes de IA no D365 F&O? (Rand Group)

🔗 Planos 2026 Release Wave 1 — Dynamics 365 & Power Platform (Microsoft Blog)

🔗 IA agentica no Dynamics 365: como os agentes autónomos transformam o ERP (IESGP)

D365 F&O 2026 Release Wave 1: as principais novidades que chegam ao seu ERP

2026-05-26T01:57:51.631-07:00

D365 F&O 2026 Release Wave 1

Dynamics 365 F&O

D365 F&O 2026 Release Wave 1: as principais novidades que chegam ao seu ERP

Maio 2026 · Leitura rápida (~2 min)

A Microsoft anunciou o 2026 Release Wave 1 para o Dynamics 365 Finance & Operations, trazendo um conjunto relevante de melhorias focadas em automação, inteligência artificial e suporte a novos modelos de negócio. As atualizações estão a ser disponibilizadas de abril a setembro de 2026.

💡 O grande tema desta wave é a operação agêntica — onde agentes de IA trabalham de forma autónoma para automatizar processos financeiros complexos, acelerando o encerramento de período e a reconciliação.

Áreas de investimento prioritárias — Dynamics 365 Finance 2026 Release Wave 1 (Fonte: Microsoft Learn)

🚀 O que há de novo nesta wave?

🤖 Automação agêntica

Agentes de IA para automatizar tarefas de encerramento de período e reconciliação financeira.

🏢 Gestão de rendas

Suporte financeiro completo a modelos de negócio baseados em aluguer de ativos e receitas recorrentes.

🌍 Globalization Studio

Expansão das localizações e compliance fiscal em mais de 210 países, com automação via low-code/no-code.

🧾 Faturação eletrónica

Framework unificado e extensível para submissão de faturas eletrónicas em múltiplos mercados.

📊 Business Performance

Analytics, planeamento e insights financeiros numa única plataforma integrada.

🔁 Billing recorrente

Melhorias no módulo de cobrança por subscrição, contratos e reconhecimento de receita.

📈 Dynamics 365 Finance & Operations ERP inteligente para equipas financeiras modernas

D365 F&O posiciona-se como ERP inteligente e preparado para o futuro (Fonte: Microsoft)

Com esta release, a Microsoft reforça o posicionamento do D365 F&O como um ERP verdadeiramente inteligente — capaz de se adaptar a negócios em crescimento, com operações globais e necessidades de compliance cada vez mais exigentes.

Saiba mais nos recursos oficiais Microsoft

🔗 Visão geral — D365 Finance 2026 Release Wave 1 (Microsoft Learn)

🔗 O que há de novo na versão 10.0.48 (Microsoft Learn)

🔗 Blog oficial Dynamics 365 Finance (Microsoft)

🔗 Plano completo de release 2026 Wave 1 (Microsoft)

O Futuro do RSAT no Dynamics 365 Finance & Operations: Limitações, Cenários e Alternativas.

2026-05-20T02:11:50.333-07:00

Notice of Deprecation: Regression Suite Automation Tool (RSAT)

Microsoft is hereby announcing the deprecation of the Regression Suite Automation Tool (RSAT), effective May 15, 2027.

As of that date, Microsoft will no longer provide support, maintenance, bug fixes, or feature enhancements for RSAT.

Deprecation details

Effective date: May 15, 2027.
Support status: Beginning on the effective date, Microsoft will no longer provide support, servicing, bug fixes, or feature updates for RSAT.
Product availability: Customers may continue to use RSAT after the effective date; however, the product will remain available only on an unsupported basis.
Recommended next step: Customers should begin planning

Se você atua com testes no Dynamics 365 Finance & Operations (F&O), provavelmente já enfrentou um cenário recorrente: após cada release wave da Microsoft, uma parte significativa dos testes automatizados falha devido a pequenas alterações na interface.

Esse comportamento não é acidental — é estrutural.

Recentemente, a própria Microsoft sinalizou em eventos técnicos que o RSAT (Regression Suite Automation Tool) está “feature complete”, ou seja:

Não há previsão de novas funcionalidades
Não existe roadmap ativo de evolução
A ferramenta continua suportada, mas sem inovação

Esse posicionamento reforça a necessidade de reavaliar a estratégia de automação de testes no ecossistema F&O.

O que é o RSAT no contexto do D365 F&O

O RSAT é a ferramenta de automação de testes fornecida pela Microsoft para o Dynamics 365 Finance & Operations, com forte integração nativa com:

Lifecycle Services (LCS)
Azure DevOps
Task Recorder for D365

Seu funcionamento é baseado na gravação de tarefas (task recordings), capturando:

Cliques
Navegação
Interações na interface

Essas gravações são posteriormente reproduzidas durante execuções de teste.

Pontos fortes no F&O

Disponível sem custo adicional com o D365 F&O
Integração nativa com o ecossistema Microsoft
Familiar para usuários que já utilizam Task Recorder
Funciona bem para:
- Testes simples
- Cenários isolados
- Processos dentro de um único módulo

O Problema Estrutural do RSAT

O RSAT não entende processos de negócio — ele entende apenas as interações com a interface do usuário (UI).

Isso significa que:

Ele não valida o resultado do processo — apenas repete os passos que um usuário executou.

Impacto direto no F&O

O Dynamics 365 F&O recebe atualizações frequentes:

Release Wave 1 (abril)
Release Wave 2 (outubro)
Hotfixes recorrentes

Cada atualização pode alterar:

rótulos de campos
estrutura de formulários
fluxos de navegação
obrigatoriedade de campos

Resultado: testes gravados quebram.

Principais Limitações do RSAT no F&O

1. Falta de testes end-to-end entre módulos

No F&O, processos críticos atravessam múltiplos módulos, como:

Procure-to-Pay (Compras → Financeiro → GL)
Order-to-Cash (Vendas → Estoque → Financeiro)

O RSAT não cobre esses fluxos de ponta a ponta de forma eficiente.

2. Alta dependência de manutenção manual

A cada mudança na UI:

Testes precisam ser regravados
Desenvolvedores são envolvidos
Ciclos de regressão aumentam

Esse efeito é conhecido como “dívida de regressão”.

3. Dependência técnica

Apesar da gravação ser simples, a manutenção exige:

Conhecimento técnico
Acesso a LCS
Configuração em Azure DevOps

Isso limita a atuação de:

Analistas de negócio
Usuários-chave
Times de QA funcionais

4. Ausência de inteligência ou adaptação

O RSAT:

Não possui auto-healing
Não identifica mudanças na UI
Não adapta fluxos automaticamente

Se algo mudar, o teste simplesmente falhará.

5. Cobertura e visão limitada

Os resultados são geralmente:

Status pass/fail
Sem visão de cobertura por processo
Sem análise de risco

Isso dificulta a tomada de decisão antes do go-live.

Por que esse problema se agrava no F&O

O Dynamics 365 F&O é um ERP altamente integrado, onde:

Processos são interdependentes
Dados fluem entre módulos
Validações dependem de contexto

Testar apenas cliques não garante que o processo financeiro ou operacional foi executado corretamente.

Categorias de Alternativas ao RSAT no F&O

Atualmente, as alternativas adotadas seguem três abordagens principais:

1. Plataformas Low-Code

Exemplos: Leapwork, ACCELQ

O que oferecem

Criação visual de testes
Menor dependência técnica
Possibilidade de importar scripts do RSAT

Limitações no F&O

Ainda baseadas na UI
Quebram com mudanças na interface
Cobertura limitada para cenários cross-module

2. Frameworks Baseados em Código

Exemplos:

Selenium (C# / Java)
SpecFlow (BDD)

O que oferecem

Controle total sobre automação
Integração com CI/CD
Suporte a cenários complexos

Limitações no F&O

Alto custo de desenvolvimento e manutenção
IDs dinâmicos do D365 dificultam estabilidade
Forte dependência de equipes técnicas

3. Automação Baseada em IA (AI Test Agents)

O que muda no paradigma

Nesse modelo:

O teste não é uma sequência de cliques
O teste valida um resultado de negócio

Exemplos:

Sofy (agents especializados para D365)

Benefícios no F&O

Autoadaptação a mudanças de interface
Validação de processos completos (ex: PO → GL)
Redução significativa da manutenção
Execução mais rápida em ciclos de release

Como Evoluir do RSAT no F&O

A abordagem mais eficaz não é substituição imediata, mas sim evolução gradual:

Estratégia recomendada

Identificar processos críticos não cobertos
(principalmente cross-module)
Priorizar cenários de maior risco:
- Fechamento contábil
- Procure-to-pay
- Order-to-cash
Manter RSAT para:
- Documentação
- Testes simples
Expandir automação orientada a resultado

Conclusão

O RSAT continua sendo uma ferramenta funcional no Dynamics 365 Finance & Operations, especialmente em cenários simples e estáveis.

No entanto, sua arquitetura baseada em UI limita sua escalabilidade em um ambiente:

Altamente dinâmico
Orientado a processos
Com releases frequentes

O movimento atual do mercado não é apenas substituir ferramentas, mas evoluir o conceito de teste:

De automação baseada em cliques para validação baseada em processos de negócio.

Alternativas ao RSAT no D365 F&O

A seguir, algumas opções utilizadas atualmente:

✅ Ferramentas Microsoft

RSAT (oficial)
Integração com Azure DevOps Test Plans
Task Recorder (base para automação)

📌 Fonte oficial:

Microsoft Learn – RSAT documentation
https://learn.microsoft.com/dynamics365/finance/dev-itpro/perf-test/regression-suite-automation-tool

✅ Low-Code / No-Code

Leapwork
ACCELQ

✅ Frameworks customizados

Selenium + C#
SpecFlow (BDD)

✅ Plataformas com IA

Sofy (foco em D365)
Outras soluções emergentes de automação inteligente

Outra possibilidade que ainda não testei: Testing and validations - Finance & Operations | Dynamics 365 | Microsoft Learn

Agradeço ao Copilot pelo formato do texto!

April Microsoft Security Updates - Security Warnings Remote Desktop.

2026-04-29T08:03:00.000-07:00

Para todos os que utilizam o Remote Desktop (RDP) para acessar ambientes, para qualquer que seja a finalidade, e também para os usuários que utilizam aplicativos hospedados em servidores RDS, as atualizações de abril liberadas pela Microsoft alteraram a segurança e trouxeram mensagens de segurança que merecem atenção.

Mais detalhes: Understanding security warnings when opening Remote Desktop (RDP) files | Microsoft Learn

D365F&O 10.0.48 Release notes

2026-04-27T00:42:00.000-07:00

Boas senhoras,

Aqui está o Release notes da versão 10.0.48 Preview: https://learn.microsoft.com/pt-br/dynamics365/finance/get-started/whats-new-changed-10-0-48

Muita novidade relacionada a IA e também melhorias em processos do sistema.

Querem ajuda para manter o sistema atualizado, estou à disposição!

D365F&O 10.0.47 Release Notes

2026-03-11T03:06:00.000-07:00

Here está:

https://learn.microsoft.com/en-us/dynamics365/finance/get-started/whats-new-changed-10-0-47

Product Model Configuration errors.

2026-02-25T06:48:00.000-08:00

Ao utilizar o "Configurador de Modelos de Produto" no modulo de Gerenciamento de Informações de Produtos, as informações do produto não são carregadas ao clicar no botão "Testar".

Verificando as informações disponíveis no navegador, encontrei o seguinte erro:

Erro 404 - Not found.

O Event Viewer não contribuiu com informações uteis para solucionar o problema.

Eu ainda não conhecia bem esta funcionalidade, mas partindo do erro 404 passei a verificar como e onde este serviço/pagina estava hospedado no servidor.

Verifiquei que o Application Pool não tinha uma aplicação vinculada e a conta de serviço utilizada era diferente de outros servidores onde este recurso funciona:

No Sites, havia apenas uma pasta com o nome "ProductionConfiguration".

Impossível acessar uma pagina quando não há um site e um Application Pool.

A solucção aqui foi converter a pasta para um site e alterar a conta do Application Pool para a conta NetworkService.

Reiniciei IIS e depois disso o recurso voltou a funcionar normalmente.

Não sei por qual razão esta VM recém criada não veio corretamente configurada e necessitou deste ajuste manual. Só sei que foi assim!

GlobalUpdate scritp for service model: MROneBox. Erro ao aplicar um Service Update do D365F&O.

2026-02-09T03:29:00.000-08:00

Hoje novamente enfrentei este erro ao aplicar a versão 10.0.46 em alguns(48) ambientes de DEV...

Segui as seguintes opções de solução:

https://fsilvajunior.blogspot.com/2024/10/globalupdate-scrito-for-service-model.html

https://fsilvajunior.blogspot.com/2025/04/globalupdate-scrito-for-service-model.html

Nenhuma delas funcionou neste caso.

Analisando o log pude ver que houve erro no momento de atualizar o MR, encontrei a seguinte mensagem no log:

Error 1921. Service 'Management Reporter 2012 Process Service' (MR2012ProcessService) could not be stopped. Verify that you have sufficient privileges to stop system services.

O serviço do MR estava em execução, tentei parar ele mas a mensagem acima foi exibida novamente. Estava usando o user Admin da VM.

A unica opção foi dar um kill no serviço do MR. Depois do kill eu resumi o deploy e o problema foi resolvido!

Obs: eu já havia reiniciado a VM antes de iniciar o deploy.

Estranho, mas é isso ai.

D365F&O 10.0.46 Generally Available

2025-12-23T02:19:00.000-08:00

Pessoas, temos disponível a versão 10.0.46 liberada no LCS e Power Platform para testes!

What's new or changed in Dynamics 365 Finance 10.0.46 (December 2025)

What's new or changed in Dynamics 365 Sypply Chain 10.0.46 (December 2025)

Querem ajuda com este upgrade?

Querem testes automáticos para validar esta e outras atualizações do seu sistema com o DevOps?

Querem um assessment gratuito em sua infraestrutura para melhorar a segurança e reduzir custos?

Estou disponível!

francisco@mtxn.com.br

D365F&O, Git e Power Platform! Parte 5

2025-11-27T11:59:00.000-08:00

Na parte 1, falei sobre o Git e como migrar do TFVC para o Git.

Na parte 2, mostro como configurar o UDE via PPAC.

Na parte 3, vimos como configurar o VS 2002 com UDE e TFVC.

Na parte 4, mostrei como configurar o VS 2022 com o Git.

Agora, na parte 5, vamos ver como trazer os dados de produção para o ambiente UDE. Sem dados, não tem como trabalhar!

Faço-lhes a seguinte pergunta: Vocês têm dado hoje?

O processo utilizando um CHE é o seguinte:

Atualizamos uma sandbox, exportamos o .bacpac para o LCS, restauramos este .bacpac na VM CHE... Depois, poderíamos exportar um .bak para uma storage account e restaurá-lo em outras VMs CHE.

Todo o processo acima pode ser automatizado com o DevOps e muito Powershell. Caso não saibam como fazer, me chamem!$

O novo processo é extremamente simples e bem documentado, mas existem algumas frescuras que aprendi do pior jeito!

O banco vem direto de PROD para o UDE do desenvolvedor.

O primeiro detalhe é a localização dos ambientes. Certifique-se da localização correta de seu ambiente de produção.

Seu ambiente UDE precisa estar na mesma localização; caso contrário, não será possível atualizar o banco de dados.

Outro detalhe, ao criar um UDE "Managed Environment", tive problemas na restauração dos dados.

Para restaurar os dados em seu ambiente UDE, acesse seu ambiente de origem, produção ou algum outro, e clique na opção "Copy".

Aqui está o ponto de atenção para minimizar a quantidade de dados copiados da produção para o UDE. Seguindo a configuração da imagem abaixo, você terá os dados básicos copiados para o UDE. Para entender melhor, leia esta documentação: https://learn.microsoft.com/en-us/power-platform/admin/copy-environment?WT.mc_id=ppac_inproduct_env&tabs=new

Depois de ajustar as configurações e clicar em "Copy", o processo será iniciado. Meu ambiente de produção tem quase 200 GB de banco de dados. Após a conclusão da cópia, meu UDE tinha apenas 71 GB. O processo todo demorou 01 hora. Tenha atenção ao espaço disponível em seu Tenant!

Após a conclusão do restore, o ambiente volta com o "Administration Mode" habilitado. É necessário desabilitar ele para poder utilizar o ambiente normalmente

E pronto, agora seu ambiente UDE tem os dados e as customizações idênticos ao ambiente de produção!

Fontes:

https://learn.microsoft.com/en-us/power-platform/admin/copy-environment?WT.mc_id=ppac_inproduct_env&tabs=new

https://www.powerazure365.com/blog-1/dynamics-365-finops-unified-developer-experience

https://d365foadvicetips.com/2024/10/05/uae-efficient-environment-copying-in-dynamics-365-fo/

D365F&O, Git e Power Platform! Parte 4

2025-11-27T10:27:00.000-08:00

Na parte 1 falei sobre o Git e como migrar do TFVC para o Git.

Na parte 2 mostro como configurar o UDE via PPAC.

Na parte 3 vimos como configurar o VS 2002 com UDE e TFVC.

Nesta parte 4 vamos configurar o VS 2022 com o Git! Let's bora!

Consultem as partes anteriores e, com o VS2022 preparado, conectem-no ao seu projeto no DevOps:

Selecione o repositório, clique com o botão direito e selecione "Clone Repository".

Agora tenho o repositório salvo na minha VM.

Seguindo os passos anteriores, você poderá se conectar ao seu ambiente UDE.

Ao final destes processos teremos um ambiente pronto para uso, com conexão ao Repos Git e um ambiente UDE totalmente funcional.

Confesso que me perdi, repeti os processos de mapeamento vezes a perder a conta!!!

Mas o aprendizado é assim mesmo.

Conforme vou aprendendo, trabalhando, usando e descobrindo coisas novas, vou atualizando os posts ou criando novos!

Na parte 5 falaremos sobre como trabalhar com dados no ambiente UDE!

Obs.: Devo sempre dizer que não criei nada. O material sobre este assunto é amplo. Existem várias fontes. Em breve mencionarei as que utilizei!

D365F&O, Git e Power Platform! Parte 3

2025-11-25T02:58:00.000-08:00

Na parte 1 falei sobre o Git e como migrar do TFVC para o Git.

Na parte 2 mostro como configurar o UDE via PPAC.

Agora vamos configurar o Visual Studio e se conectar ao ambiente UDE criado.

Neste cenário de testes, criei uma nova VM com Windows 11. Nesta VM, instalei o Visual Studio 2022 Professional e o SQL Server Management Studio.

Durante a instalação do VS2022, adicionem o "Modeling SDK":

Abra o VS, clique em "Extensions > Manage Extensions", pesquise por "Power Platform Tools" e instale a extensão. Veja que a Microsoft já atualizou o logo! Depois de clicar em instalar, feche o VS e aguarde o processo de instalação.

Depois de instalado, abra o VS e clique em "Tools > Connect to Dataverse":

Escolha as opções de acordo com sua necessidade. Minha VM, por exemplo, não está no domínio da empresa. Marquei a opção "office 365" e quero ver todas as organizações às quais tenho acesso. Usar a opção de logar com a conta atual me trouxe problemas, por isso não a uso!

Após a autenticação, você verá a lista de organizações e ambientes a que você tem acesso. Selecione o seu ambiente UDE e clique em "Login".

Selecione a solution e clique em Done. É importante selecionar a solution diferente da "default". Quando eu souber a razão, eu volto aqui pra explicar!!!

Uma série de processos se iniciará. Download do Metadata, copia de cross-references e outros... apenas aguarde a conclusão. Assim que este processo for concluído, clique em "Yes" para dar continuidade ao processo de configuração:

Acesso o "Output" do VS e você verá que o processo de configuração está sendo executado em background. Aguarde!

Se abrir a pasta PackageLocalDirectory, vai ver que ela está sendo desconpactada. Aguarde, este processo demora um tanto!

Neste caso específico, ainda mapeei o UDE a um projeto do TFVC. Em posts anteriores mostrei como fazer isso, não vou repetir todo o processo aqui!

Concluímos aqui a configuração da VM Windows 11, com Visual Studio 2022 conectado ao DevOps TFVC.

A parte 4 será sobre a configuração do Visual Studio com o Repos Git!

D365F&O, Git e Power Platform! Parte 2

2025-11-23T08:07:00.000-08:00

Na parte 1, falamos um pouco sobre as novidades no uso do Git como repositório e sobre a migração do TFVC.

Sem reinventar a roda, a parte 2 trata de criar o UDE no Power Platform Admin Center (PPAC).

Os links abaixo, apesar de antigos, ainda são válidos:

https://fsilvajunior.blogspot.com/2024/05/dynamics-365-finops-unified-developer_26.html

Havendo novidades na criação de um UDE, atualizarei os posts acima.

Na parte 3 veremos como configurar o Visual Studio 2022 e iniciar os trabalhos!

D365F&O, Git e Power Platform! Parte 1

2025-11-23T07:39:00.000-08:00

Após ouvir as palestras e ver as demos durante o D365Summit em Lisboa, decidi que já era hora de aprofundar minha prática no uso do Git como repositório de código do D365F&O, bem como de utilizar o UDE como ambiente oficial de desenvolvimento e debug.

Após as palestras, ficou claro pra mim que o LCS não tem muito mais do que 1 ano de vida. Até hoje, vejo profissionais com dificuldades para utilizar o DevOps com o TFVC. Penso que, quanto antes iniciarmos o uso do Git com o D365F&O, mais chances teremos de minimizar os problemas quando chegar o momento em que nem sequer teremos a opção de usar o TFVC. E este momento está mais próximo do que vocês imaginam!

Obs: Falarei de "USE" e "UPE" em breve!

Inicio aqui uma série de posts para colocar em pleno funcionamento o UDE + Git + PPAC + DevOps no uso diário com o D365F&O!

Neste primeiro post vamos migrar um repositório de códigos to TFVC para O Git.

"Neste link você pode obter mais detalhes sobre as vantages e sobre como utilizar o Git com o D365F&O"

Neste momento, Dezembro de 2025, a migração do TFVC para o Git está extremamente simples. Não há necessidade de criar um repositório Git antes.

Acesse o DevOps, vá até Repos e clique na opção "Import repository":

No "Repository type" escolha o TFVC.

No "Path" informe o caminho da Branch a ser migrada. É importante informar a Branch correta!

Você tem a opção de importar o histórico de changesets da Branch, escolha entre 1 e 180 dias!

Por ultimo, informe o nome do Repos Git a ser criado e clique em "import".

Agora apenas espere a conclusão do processo:

Não tenho muitos changesets, mas note que o novo Repos no formato Git manteve as poucas mudanças que fiz antes da migração do TFVC para o Git:

Existem outros detalhes importantes muito bem documentados neste link: https://learn.microsoft.com/pt-br/azure/devops/repos/git/import-from-tfvc?view=azure-devops

Se seu projeto seguiu as boas práticas da Microsoft, a migração de TFVC para Git será fácil!

Se você é uma empresa cliente ou parceiro da Microsoft e precisa de apoio nesta migração, entre em contato!

Aqui está a Parte 2!

Fonte: https://www.powerazure365.com/blog-1/dynamics-365-finops-unified-developer-experience

D365F&O. TFVC ou Git como repositório?

2025-11-23T07:36:00.000-08:00

À medida que as organizações modernizam suas práticas de DevOps, a transição de sistemas de controle de versão centralizados, como o TFVC, para sistemas distribuídos, como o Git, tornou-se uma prioridade estratégica, especialmente para equipes que trabalham com o Microsoft Dynamics 365 Finance & Operations (F&O).

O Git não só permite uma colaboração mais eficiente e ciclos de entrega mais rápidos, como também se integra perfeitamente ao Azure DevOps Git, tornando-se a escolha preferida das equipes de desenvolvimento.

Por que usamos Repos no DevOps para o desenvolvimento do D365 F&O?

No desenvolvimento DevOps para Dynamics 365 Finance and Operations (F&O), os repositórios são usados principalmente para controle de versão. Isso permite que os desenvolvedores acompanhem as alterações em seu código ao longo do tempo, colaborem efetivamente com outros membros da equipe e gerenciem diferentes versões do código-fonte.

Também garante processos de desenvolvimento e implantação tranquilos, facilitando a ramificação, a mesclagem e as revisões de código, tudo no contexto de um sistema centralizado como o Git no Azure DevOps.

Principais benefícios do uso de repositórios no desenvolvimento do D365 F&O:

Colaboração: Vários desenvolvedores podem trabalhar no mesmo código-fonte simultaneamente, cada um fazendo alterações em sua própria ramificação e mesclando-as no código-fonte principal para evitar conflitos.

Controle de versão: Acompanhe todas as alterações no código, permitindo que você reverta facilmente para versões anteriores, se necessário.

Processo de revisão de código: Permita que os membros da equipe revisem as alterações de código entre si antes de mesclá-las na ramificação principal, melhorando a qualidade do código.

Estratégias de ramificação: Crie ramificações distintas para os ambientes de desenvolvimento, teste e produção. Isso permite testar e implantar novos recursos de forma isolada, sem afetar o sistema em produção.

Compilação e implantação automatizadas: Integre-se a pipelines de CI/CD no Azure DevOps para compilar, testar e implantar automaticamente alterações de código em diferentes ambientes com base em commits no repositório.

Git como sistema de controle de versão preferido

A maioria das equipes de desenvolvimento modernas do D365 F&O usa o Git como sistema de controle de versão subjacente em seus repositórios, devido à sua flexibilidade e popularidade.

Escolher uma estratégia de ramificação adequada (como a ramificação de recursos ou o desenvolvimento baseado em trunk) é crucial para a colaboração eficiente e para o gerenciamento de diferentes versões de código.

Importância do Git

O Git é um sistema de controle de versão moderno e distribuído, essencial nas práticas de desenvolvimento de software atuais. Ele permite que os desenvolvedores trabalhem de forma independente com uma cópia completa da base de código, o que possibilita maior desempenho e acesso offline. O Git simplifica a colaboração, oferecendo suporte a ramificações e mesclagens eficientes, o que ajuda as equipes a desenvolver recursos, corrigir bugs e experimentar com segurança, sem afetar a base de código principal.

Ele também oferece um histórico detalhado, facilitando a auditoria de alterações e o rollback, se necessário. Amplamente integrado a ferramentas de DevOps e pipelines de CI/CD, o Git garante a automação eficiente dos processos de build, teste e implantação. Sua natureza de código aberto e o forte suporte da comunidade fizeram do Git o padrão da indústria no controle de versão.

Principais comandos do Git e comparação com o TFVC:

Buscar (Fetch)

É importante buscar (fetch) e baixar (pull) antes de enviar (push). A busca verifica se há commits remotos que você deve incorporar às suas alterações locais. Se encontrar algum, baixe (pull) primeiro para evitar conflitos de mesclagem com o repositório remoto. Ao buscar uma branch, a janela Alterações do Git exibe um indicador abaixo do menu suspenso da branch, indicando o número de commits não baixados (unpulled) da branch remota. Esse indicador também mostra o número de commits locais não enviados (pushes).

Baixar (Pull)

Sempre baixe (pull) antes de enviar (push). Ao baixar (pull) primeiro, você evita conflitos de mesclagem com o repositório remoto.

Enviar (Push)

Ao criar commits, você salva automaticamente snapshots do seu código local. Use o comando Enviar (Push) para enviar os commits para o GitHub, onde você pode armazená-los como backups ou compartilhar seu código com outras pessoas.

Sincronizar (Sync)

Você envia commits (push) quando sua branch local estiver desatualizada em relação à branch remota. Se tentar enviar (push), uma caixa de diálogo solicitará que você baixe (pull) antes de enviar (push).

Use esta operação para baixar (pull) e enviar (push) de forma sequencial.

Falando de D365F&O, acesse o link abaixo para saber como iniciar o trabalho utilizando o Git como repositório padrão: https://fsilvajunior.blogspot.com/2025/11/d365f-git-e-power-platform-parte-1.html

Simplifying License Management for Dynamics 365 Finance and Operations

2025-09-25T01:52:00.000-07:00

A Microsoft anunciou novas alterações nos prazos para o correto licensiamento do F&O. Na FAQ já é possível ver esta alteração com as novas datas:

User Security Role Reporting and Technical Validation for Dynamics 365Finance and Operations Apps - FAQ

"Após 15 de janeiro de 2026, a implementação da notificação ao usuário começará 30 dias antes da renovação do contrato ou data de aniversário do cliente. Clientes com renovação em 15 de janeiro receberão uma notificação em 15 de dezembro de 2025. Como lembrete, apenas usuários que não possuem as licenças necessárias atribuídas no Centro de Administração do Microsoft 365 receberão essas notificações. No mês de renovação ou aniversário do cliente, todos os usuários precisarão ter uma licença atribuída para acessar os aplicativos de finanças e operações do Dynamics 365, conforme confirmado nos relatórios de licença. Semelhante às notificações, isso seguirá nosso processo de lançamento padrão e será implementado em todos os locatários comerciais ao longo de várias semanas. Estamos oferecendo aos clientes tempo para se prepararem com ferramentas e treinamento para dar suporte a qualquer ação necessária. Para usuários que já possuem licenças atribuídas, não haverá interrupção e nenhuma ação será necessária por parte do administrador."

Fiquem atentos aos prazos, acompanhem a FAQ e utilizem o link abaixo que em breve estará atualizado com as novas informações:

Simplifying License Management for Dynamics 365 Finance and Operations

Se precisarem de ajude, estou disponível!

XKTools - 12 - Update Web e Wif Config

2025-08-03T07:30:00.000-07:00

Acredito que muitos passaram pelo cenário onde não conseguiram importar novos usuários dentro de suas VMs.

A Microsoft alterou o sistema de segurança para evitar "gatos" no uso das VMs. Se quiser mais detalhes veja este link: https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/dev-tools/secure-developer-vm?WT.mc_id=DX-MVP-5004702

Para solucionar este problema precisamos de um Azure App Registration Azure App Registration e também vamos editar os arquivos web e wif config. O link da Microsoft obviamente possui as orientações necessárias, por ser um processo que exige atenção aos detalhes, "resolvi usar todo o meu conhecimento 😂", e pedi ao ChatGPT pra criar um script. Depois de várias tentativas e ajustes chegamos à ferramenta descrita aqui.

O processo para permitir importação de um novo usuário em uma VM de DEV passa pela reconstrução da autenticação do F&O da VM com o Tenant do Azure do cliente em questão. Para reconstruir esta autenticação vamos precisar do certificado digital da VM e editar os arquivos Web e Wif config. Vamos a isso.

Ao executar a opção 12 lhe será apresentada um ajanela do Windows solicitando que você escolha o certificado digital do site do F&O dentro da VM. O certificado tem exatamente o mesmo nome do site, escolha-o e conclua a exportação, um arquivo .CER erá salvo na pasta C:\Temp.

Vá ao seu App Registration e importe este certificado:

Agora vamos continuar com os demais detalhes dentro da VM. Pensando em diferentes VMs com diferentes estruturas de discos, lhe será perguntado qual o diretório da pasta onde estão localizados os arquivos do F&O, escolha a unidade correta e siga em frente:

Obviamente antes de editar o arquivo, geramos um backup:

Informe o Client ID do App Registration e clique ok:

Pronto, reinicie os serviços do F&O utilizando as opções disponiveis no menu e você poderá importar novos usuários em sua VM de DEV!