Sunday, June 15, 2025

Designing Approval Workflows in Dynamics 365 Finance with a SOX-Compliance Lens











DESIGNING APPROVAL WORKFLOWS IN DYNAMICS 365 FINANCE WITH A SOX-COMPLIANCE LENS

CONTENT

Introduction
Why Every SOX Control Framework Must Include Robust Approval Workflows
How D365FO Workflow Maps to SOX Control Objectives
Control Design Choices That Auditors Will Question
Test of Design (TOD) - Configuring a SOX-ready Purchase Order Approval
Test of Effectiveness (TOE) - Executing a Sample Purchase Order Workflow
Extra: Workflow Escalation: Ensuring Control Continuity
Conclusion

INTRODUCTION 

In today’s regulatory landscape, internal controls are no longer optional—they are an operational necessity. For organizations subject to the Sarbanes-Oxley Act (SOX), especially Section 404, demonstrating that transactions are properly authorized, reviewed, and traceable is critical to passing an external audit. Dynamics 365 Finance and Operations (D365FO) offers built-in workflow capabilities that, when thoughtfully configured, can enforce these control requirements directly within the system. This article explores how to design and implement approval workflows in D365FO that satisfy SOX compliance expectations, with a focus on practical configuration guidance, control alignment, and audit-readiness.

WHY EVERY SOX CONTROL FRAMEWORK MUST INCLUDE ROBUST APPROVAL WORKFLOWS

Section 404 of the Sarbanes-Oxley Act (SOX) requires management to assert—and external auditors to attest—that the company maintains effective internal control over financial reporting. In practice that means every financially significant transaction must be:

1. Authorized by the right people,

2. Executed in line with documented policies, and

3. Evidenced so that an auditor can reconstruct who approved what, when, and why.

Dynamics 365 Finance & Operations (D365FO) contains a flexible workflow engine that can satisfy all three conditions—if you design it properly. Approvals, when combined with Segregation of Duties (SoD) rules, prevent the classic “create and approve my own transaction” scenario that violates SOX assertions.

HOW D365FO WORKFLOW MAPS TO SOX CONTROL OBJECTIVES

To effectively support SOX compliance, organizations must align system capabilities with specific control objectives—and Dynamics 365 Finance offers the features needed to do just that.








CONTROL DESIGN CHOICES THAT AUDITORS WILL QUESTION

Even with strong workflow tools, poorly structured configurations can raise red flags during audits; understanding what auditors scrutinize helps avoid preventable issues.





CONFIGURING A SOX-READY PURCHASE ORDER APPROVAL (TEST OF DESIGN - the parts auditors ask for)

The steps below follow a purchase order (PO) scenario because POs hit multiple SOX-sensitive accounts—Commitments, Accruals, and ultimately COGS. Replicate the same pattern for vendor invoices, journal vouchers, or project change orders.

Scenario

  • Every PO must be approved by a Procurement Manager who is not the originator.
  • POs ≥ USD 25 000 receive a second approval from Finance.

Step 1 Enable change management for POs

1.Navigate to Procurement and sourcing > Setup > Procurement and sourcing parameters.

2.On the General tab, activate Enable change management.





3.Set Allow override of settings per vendor to No to prevent policy bypass.



Step 2 Create a new workflow

1.Navigate to Procurement and sourcing > Setup > Procurement and sourcing workflows.

2.Click New > Select Purchase order workflow.



3.Click Run.








4.Workflow editor is loaded.








5.Workflow editor pops-up.















Step 3 Add approval elements

1.In the graphical editor, drag Approve purchase order onto the canvas.



2.Double click on the approval element.


3.Select the sub-approval step and go to step properties.




Step 4 Approval step configuration

Basic settings: Directives for the approver.



Assignment: Approver assignment.

Select participant.


Switch to Role based tab.

Select User group participants in the type of participant.

Select Purchase order approvals in the participant field.



Let's add another approval step ford the Director review & approval.








Basic settings: Directives for the approver director.



Assignment: Approver assignment. Select the director's name here.





Condition: Indicate if this step will be executed under a certain condition.

According to our scenario, order needs to be approved by the director if purchase order's total amount is equal or greater than $25K. 














Save and activate the workflow.

New workflow is ready.










Note that first level approval will be sent to "Purchase order approval" user group. Let's make sure that the user group has the correct users.

Navigate to System administration > Users > User groups



Make sure that approvers are in the correct users.

Another important workflow control is to prevent the submitter from approving the workflow.

Navigate to System administration > Workflow > Workflow parameters.






Note: I will not activate this parameter for the demo purpose.

EXECUTING A SAMPLE PO APPROVAL  TO DEMONSTRATE EVIDENCE (TEST OF EFFECTIVENESS - the parts auditors ask for)

Go to Procurement and sourcing > Purchase orders > All purchase orders and create a new PO.

I've created a purchase order and submitted it to workflow approval.

Click Workflow > Submit

Enter a justification comment.

Workflow approval step 1 has been created.


Log in as Approver user. In the work items assigned to me section, open the record.


 
Let's approve the order by selecting Workflow > Approve.

The next step is to check workflow history to see if there is an action item. Note that there is another approval pending, the director approval due to the total amount is greater than $25K.

Let's approve the order, again

Check the workflow history now. Note that the approval workflow is now completed. 

AUDIT NOTE: Retrieving evidence is the most important point here. Take necessary screenshots of workflow history that shows approver user IDs, timestamps, comments and system/workflow version - exportable to excel for auditors.

Note that order status is now Complete.



NOTE: Demonstrate at least two additional edge cases

  • Requester tries to approve own PO—system throws an error and says submitter cannot be approver;
  • Approver misses 1-day SLA—workflow escalates automatically. Details have been explained below.

EXTRA: Workflow Escalation: Ensuring Control Continuity

In a SOX-compliant environment, timeliness of approvals is just as critical as the approval itself. Workflow escalation ensures that if an approver does not take action within a defined time frame, the task is automatically reassigned to another authorized user—typically a control owner. 

In Dynamics 365 Finance, escalation is configured within the workflow step properties:

Navigate to the approval step in the workflow editor and find the related step, open the properties.











Under "Time limits", set a duration (e.g., 1 day).















Go to Escalation tab.















My configuration says:

▶️ If the workflow step is not approved in 1 day, then it will be assigned to user admin,

▶️ If the workflow step is not approved in 4 hours, then it will be assigned to user Dadiyaman,

▶️ If the workflow step is not approved in 2 hours, then it will be automatically Rejected.

This mechanism ensures control continuity, avoids bottlenecks, and demonstrates that the organization has safeguards against delayed approvals—an important consideration during SOX audits.

CONCLUSION

Designing effective approval workflows in Dynamics 365 Finance is not just a matter of system configuration—it is a control activity that directly supports SOX compliance. When implemented with a clear understanding of control objectives, approval workflows can enforce proper authorization, support Segregation of Duties, and generate the audit evidence needed to validate financial governance.

This article demonstrated how to design and execute a SOX-compliant purchase order approval process in D365FO, from activating change management to enforcing dual-level approvals and workflow escalation. Each workflow design choice—such as preventing self-approvals, using value-based conditions, or defining time-bound escalation paths—should be mapped back to a specific control objective in your organization’s risk and control matrix (RCM).

Ultimately, the goal is to move beyond simply routing transactions for approval. A properly designed workflow provides assurance to management and auditors that transactions are reviewed by the appropriate personnel, decisions are logged and traceable, and control breakdowns are systematically prevented. With D365FO’s workflow engine, compliance teams can build these safeguards directly into the business process—creating a strong line of defense against financial misstatements and audit findings.

Saturday, June 7, 2025

Turning Document Routing Agent into a Compliance Enabler in Dynamics 365 Finance & Operations



TURNING DOCUMENT ROUTING AGENT INTO A COMPLIANCE ENABLER IN DYNAMICS 365 FINANCE & OPERATIONS

CONTENT

Introduction
Implement Printer Access Controls
Monitor and Log Print Jobs
Set Up Role-Based Document Routing Policies
Include DRA in Your ITGC Walkthroughs
Ensure DRA is Covered in Business Continuity and Disaster Recovery (BC/DR) Planning
Conclusion

INTRODUCTION

In most ERP implementations, the Document Routing Agent (DRA) is seen as a basic utility for printing documents from the D365FO cloud environment to on-premises printers. While its technical function is straightforward, DRA plays a far more critical role in compliance—especially in industries governed by internal controls and audit scrutiny.

When configured intentionally, DRA strengthens Segregation of Duties (SOD), enhances data confidentiality, and supports IT General Controls (ITGCs) by providing visibility into how and where sensitive documents are output. This article repositions DRA from a background tool to a frontline compliance enabler, supported by practical configuration guidance. 

IMPLEMENT PRINTER ACCESS CONTROLS

Compliance Concern

In financial systems, printers are often treated as generic hardware—but they are in fact data endpoints. Unrestricted printer access can result in payroll reports, AP checks, or tax filings being printed in unmonitored locations. This exposes sensitive information to unauthorized users and violates least privilege and data segregation principles. Without access controls, even users outside of finance may inadvertently (or maliciously) access confidential documents.

Configuration Guidance

  • In Print Management >> Document Type Setup, assign specific printers per legal entity, document type, and user group.
  • Use Entra Id (Azure Active Directory) (AAD) groups in the DRA setup to scope printer access by role.
  • Disable “default printer fallback” to prevent routing documents to unintended devices.

Example: Map payroll printers only to HR security groups and remove visibility from general business users.

MONITOR AND LOG PRINT JOBS

Compliance Concern

In the event of a dispute or audit inquiry, the inability to trace document output—who printed what, when, and where—can be viewed as a control failure. Unlike financial transactions, printing often occurs outside standard logging unless deliberately configured. For high-value outputs such as checks and invoices, this gap leaves organizations vulnerable to fraud, forgery, or data mishandling.

Configuration Guidance

  • Enable logging on the DRA server using Windows Event Viewer or custom PowerShell scripts.
  • Export and archive logs in a secure location tied to document IDs or journal references.
  • Consider Power BI dashboards or SIEM integration for ongoing monitoring and anomaly detection.

Example: Capture DRA logs related to payment batch ID 30992, noting user, timestamp, and destination printer.

SETUP ROLE-BASED DOCUMENT ROUTING POLICIES

Compliance Concern

If the same person can initiate, approve, and print a payment document, SOD policies are undermined. Often overlooked, printer access can provide the final control point for fraudulent activities. By failing to route documents based on role or business unit, organizations leave a back door open to financial manipulation.

Configuration Guidance

  • Align document routing rules with security roles and approval hierarchy.
  • Ensure that users responsible for initiating financial transactions are restricted from accessing print devices assigned to payment or reporting outputs.
  • Use conditional routing in Print Management to dynamically assign printers based on the user’s business unit or document type.

Example: Assign check printing rights exclusively to an “AP Supervisor” role with no posting rights, separating duty from execution.

INCLUDE DRA IN YOUR ITGC WALKTHROUGHS

Compliance Concern

Despite being critical to delivering physical financial outputs, DRA is often excluded from ITGC documentation and walkthroughs. Yet, its failure—whether due to expired certificates, misconfiguration, or access gaps—can delay audits, compromise controls, and disrupt compliance reporting. Regulators increasingly demand visibility into end-to-end control paths, including how documents move from system to paper.

Configuration Guidance

  • Document DRA setup, including machine location, service account, and certificate renewal process.
  • Retain screenshots of Print Management and DRA settings for audit folders.
  • Include DRA in quarterly IT control reviews and walkthrough narratives with auditors.

Tip: Demonstrate a full “initiate → approve → print” chain using real data during control testing.

ENSURE DRA IS COVERED IN BUSINESS CONTINUITY AND DISASTER RECOVERY (BC/DR) PLANNING

Compliance Concern

DRA outages—whether caused by server failure, software patches, or expired certificates—can halt printing of essential documents. In time-sensitive environments like payroll or tax, missing a print deadline may result in non-compliance, delayed payments, or regulatory fines. Yet DRA is often overlooked in BC/DR plans, leaving a critical gap in continuity readiness.

Configuration Guidance

  • Monitor DRA service uptime and certificate validity using scheduled tasks or Azure Monitor alerts.
  • Deploy redundant DRA instances on multiple machines to ensure high availability.
  • Define an alternate output channel (e.g., secure PDF delivery) and test it regularly as part of DR simulations.

BC Planning Tip: Document DRA failover procedures and simulate a test during quarter-end processing.

CONCLUSION

The Document Routing Agent in D365FO may appear to be a technical detail, but it plays a critical role in the secure and compliant delivery of financial documents. When overlooked, it can introduce control gaps—especially around data confidentiality and segregation of duties. When properly governed, however, DRA becomes a practical compliance enabler that reinforces ITGC, supports audit readiness, and ensures continuity for key financial outputs.

Organizations should treat DRA with the same discipline applied to financial workflows and security roles. By doing so, they not only strengthen their ERP control environment but also close a commonly missed gap in the end-to-end integrity of business operations.

Saturday, May 31, 2025

Excel (Add-in) Data Entity Identification for Security Purposes in Dynamics 365 Finance and Operations (D365FO)



EXCEL (ADD-IN) DATA ENTITY IDENTIFICATION FOR SECURITY PURPOSES IN DYNAMICS 365 FINANCE AND OPERATIONS (D365FO)

CONTENT

Introduction
Understanding the Two Types of Data Entities
Why You Need Excel Entity Names in Security Roles
How to Identify the Correct Excel Data Entity Name
Most Common Excel Add-in Data Entities
Conclusion

INTRODUCTION

In Dynamics 365 Finance and Operations (D365FO), Excel Add-in integrations are frequently used by business users to update journal data efficiently. However, granting access to Excel-based data entities requires precise identification of entity names, because they are different than data management entities. This article explains the distinction between standard data entities and Excel Add-in (Office integration) data entities, and provides a structured approach for identifying the correct entity names needed when configuring security roles.

UNDERSTANDING THE TWO TYPES OF DATA ENTITIES

There are two primary types of data entities in D365FO. Although they both enable access to system data, they are used in different contexts and have distinct characteristics:

1. Data Entity (Used in Data Management Projects)

  • Purpose: Primarily used for data import/export, data migration, system integrations, and data projects in the Data Management Workspace.
  • Accessed via: Data Management Framework (DMF) or Integration APIs.
  • Characteristics:
    • Supports staging tables and data validation.
    • Can handle large volumes of data.
    • Often includes all required fields for complete record creation.
    • Suitable for IT and system administrators.

2. Excel Data Entity (Used in Excel Add-in)

  • Purpose: Designed for end users (e.g., accountants, planners) to update or manage transactional data directly in Excel, like journal lines, forecast lines, budget register entries, etc.
  • Accessed via: “Open in Excel” button on D365FO forms or from Excel using the Excel Add-in.
  • Characteristics:
    • Easy-to-use interface with filtering and lookup capabilities.
    • Often shows only a subset of fields relevant to day-to-day operations.
    • Real-time read/write interaction with D365FO.
    • Security-aware (only shows what the user has permission to access).

⚠️ Note: Not every data entity is exposed for Excel; only entities designed for Office integration are surfaced in Excel Add-ins. That’s why they have different names.

Example for Comparison: The data entity used in Data Management is not the same as the one used for the journal line Excel Add-in. Confusing these can result in incomplete security configurations.

Functional Name: Purchase trade agreement journal lines

  • Data entity name: Open purchase price journal lines V2
  • Excel data entity name: PurchOpenPurchasePriceJournalLineV2Entity










WHY YOU NEED EXCEL ENTITY NAMES IN SECURITY ROLES

When assigning permissions, especially for users expected to use Excel integrations, identifying the correct Excel data entity name is critical. Without it, users may have access to the journal forms but will not see the "Open in Excel" button.

Common use cases that require Excel Add-in access:

  • General Ledger (GL) Journal Lines
  • Inventory Counting Journal Lines
  • Trade Agreement Journal Lines
  • Vendor Invoice Journal Lines

This method is widely used to update journal lines in bulk. However, if the security role doesn’t include the specific Excel entity, the integration features will be hidden or restricted.

HOW TO IDENTIFY THE CORRECT EXCEL DATA ENTITY NAME

In D365FO, identifying the correct Excel Add-in data entity is necessary when configuring security roles, especially if users rely on the “Open in Excel” feature. The entity name used for the Excel integration is not always obvious, and often differs from the one used in Data Management. This section outlines practical steps for identifying the exact data entity tied to the Excel Add-in, ensuring users are granted appropriate access without over-provisioning.

OPTION 1: The Excel Template Name

Most of the time, the downloaded Excel template's file name includes the entity name.







OPTION 2: The Excel Template Designer

In D365FO, navigate to Procurement and sourcing >> Prices and discounts >> Trade agreement journals.

Select a journal with Relation: Price (purch.) and click lines.

Click Open in Microsoft Office and choose the relevant data entity.








System downloads the excel template.

Open the downloaded template and click design in the Excel Add-in.














Click + Add table or + Add fields.














Select data entity source field will reveal the actual source data entity.













This field shows you the exact data entity name, not the excel data entity name.















This helps identify the standard entity used in the integration, which can then be translated to the Excel entity name. Once you know the data entity name, apply the following pattern:

[Module prefix] + [Entity name] + "Entity"

Module prefix: e.g., Invent, Purch, Sales, Ledger

Entity name: As retrieved from the template

Example: 

If the source entity is OpenPurchasePriceJournalLineV2 then

the Excel entity would be PurchOpenPurchasePriceJournalLineV2Entity as shown below











Special Case: Multiple Entities in One Template

In some cases, the Excel template contains multiple excel data entities. You may need to do some investigation to identify the name of the secondary entity—for example, in general ledger journal lines.

Navigate to General ledger >> Journal entries >> General journals.

Click Open in Microsoft Office and choose the relevant data entity.








System downloads the excel template.

Open the downloaded template and click design in the Excel Add-in.











Note that you are seeing two data entities, unlike the usual view. So both entities should be accessible by the same security role.

⚠️ Note: Another way to identify the presence of multiple data entities is by checking the downloaded Excel file name. If it ends with "Template," it indicates that multiple entities are included.

Click + Add table or + Add fields.












Select data entity source field will reveal the actual source data entity.












This field shows you the exact data entity name, not the excel data entity name.













Now you can apply the below formula and identify exact required excel data entity name for your security configuration.

[Module prefix] + [Entity name] + "Entity" = LedgerLedgerJournalLineEntity (No need to use 'Ledger' two times)

If you grant access to excel data entity LedgerJournalLineEntity, user can use export to excel add-in feature.










MOST COMMON EXCEL ADD-IN DATA ENTITIES

Here are the most frequently used Excel data entities, especially in journal-heavy environments:

  • General Ledger (GL) Journal Lines: Requires access to both header and line entities
  • Inventory Counting Journal Lines: Only one entity is required
  • Trade Agreement Journal Lines: Different entities may be activated depending on the price type
  • Vendor Invoice Journal Lines: Requires access to both header and line entities

CONCLUSION

Identifying the correct Excel Add-in data entity name is essential when configuring security roles in D365FO. Without it, even experienced users might be blocked from using the Excel integration features they rely on for daily operations. Use the methods outlined above—especially downloading templates and checking the entity structure—to accurately assign permissions. As always, keep in mind that Excel Add-in entities are security-aware, so careful role configuration ensures both usability and compliance with least privilege principles.

Understanding Telemetry Pricing for Dynamics 365 Finance & Operations (D365FO)

UNDERSTANDING TELEMETRY PRICING FOR DYNAMICS 365 FINANCE AND OPERATIONS (D365FO) CONTENT Introduction D365FO Telemetry Capabilities Key Pric...