Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE1: Operational Management

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE1: OPERATIONAL MANAGEMENT

CONTENT Introduction Why the Three Lines of Defense Matters in D365FO LINE 1 Operational Management in D365FO Role-Based Access Control Segregation of Duties (SoD) Enforcement Workflow Approvals in Core Processes Field-Level Audit and Setup Change Monitoring Sample Scenario Conclusion

INTRODUCTION 

As regulatory expectations increase and ERP systems take a central role in financial reporting, organizations are under pressure to demonstrate effective governance within their core business applications. In the context of Microsoft Dynamics 365 Finance and Operations (D365FO), aligning system capabilities with the Three Lines of Defense (3LoD) framework has become a practical way to structure risk and control activities.

The Three Lines of Defense model is a well-established framework used to separate responsibilities for risk ownership, compliance oversight, and independent assurance:

• First Line: Business operations responsible for executing controls
• Second Line: Risk and compliance functions that guide and monitor control performance
• Third Line: Internal audit functions that provide independent assurance

This article explains how D365FO can support all three lines of defense by leveraging built-in features such as workflow approvals, segregation of duties (SoD), security role configuration, audit trails, and external monitoring tools. It is written for consultants, compliance professionals, and ERP stakeholders who are responsible for strengthening internal controls, especially in regulated environments (e.g., SOX-compliant organizations).

By the end of this article, you will understand how to map D365FO features to each line of defense, what implementation activities to prioritize, and how to structure your environment to meet both compliance and operational needs. Screenshot indicators are included throughout the article to help you illustrate the guidance using your own sandbox data.

WHY THE THREE LINES OF DEFENSE MATTERS IN D365FO

Modern regulators and auditors expect ERP environments to reflect the Three Lines of Defense (3LoD) model:

• LINE 1: Operational Management owns risk and executes controls.
• LINE 2: Risk & Compliance oversees, advises, and monitors.
• LINE 3: Internal Audit provides independent assurance.

Dynamics 365 Finance & Operations (D365FO) offers native functionality—augmented by common ISV tools such as Fastpath or RSM Guardian—to embed each line directly in the application. Implementing these capabilities up-front reduces external audit findings, accelerates SOX readiness, and lowers the cost of ongoing compliance.

LINE 1 | OPERATIONAL MANAGEMENT IN D365FO

The First Line of Defense is composed of operational users—those in finance, procurement, inventory, or accounts payable—who are responsible for executing daily business processes and applying system controls as part of their regular duties. These are the people who create journals, submit purchase orders, manage vendors, and approve transactions.

In Dynamics 365 Finance and Operations, these users can directly perform their responsibilities in a way that enforces preventive and detective controls, ensuring they own the associated risks while remaining compliant with internal policies and external regulations.

Let’s explore how this works in practice.

Role-Based Access Control: D365FO uses a security model based on the roles, duties, privileges, which allows you to strictly limit user access to only those tasks they are responsible for. This means each user can be aligned with the specific business function they perform—such as AP clerk, GL accountant, or procurement manager—without having unnecessary access to sensitive or conflicting tasks.

For example, an accounts payable clerk can be granted access to create and edit invoices, but not post journals or create vendors.

By enforcing least privilege access, this model helps organizations meet the core requirement of Line 1: enabling business users to operate efficiently while containing access risk. 

System administration > Security > Assign users to roles

Segregation of Duties (SoD) Enforcement: While access control is about what a user can do, SoD is about what combinations of access should not exist. D365FO provides built-in SoD rules and conflict-checking tools that help prevent users from having access to incompatible duties—such as being able to both create a vendor and approve a payment.

The system allows you to:

• Define SoD rules between duties (e.g., "Vendor master maintenance" and "Vendor payment approval")
• Check for violations when assigning roles
• Enforce review and approval workflows for exceptions

SoD enforcement supports Line 1 by preventing control failures at the point of access assignment and ensuring business users are only responsible for the right set of tasks.

System administration > Security > Segregation of duties > Segregation of duties rules

Workflow Approvals in Core Processes: To ensure operational users follow proper approval paths before high-risk actions are taken, D365FO includes a Workflow engine for many key transaction types, such as:

• Vendor edits
• Purchase requisitions and purchase orders
• General ledger journal entries
• Expense reports
• Vendor invoice journals
• Vendor payment journals

Workflow ensures that a second individual reviews and approves key actions before the transaction is posted or finalized—enabling proper oversight without relying on manual follow-up. This is a critical component of Line 1, as it ensures controls are built into business processes, not applied reactively.

For example, a workflow can require that any purchase order over $25,000 must be approved by a finance manager, even if submitted by an authorized clerk. You can find this end-to-end scenario here.

Accounts payable > Setup > Accounts payable workflows

Field-Level Audit and Setup Change Monitoring: In many control environments, configuration data is just as sensitive as transactional data. The Database Log in D365FO allows you to track changes to high-risk fields—for example, when someone changes a vendor's bank account number or modifies the posting profile for a journal.

This capability supports Line 1 by creating transparency and accountability for operational teams responsible for configuration or master data. Once enabled, the database log tracks:

• Who changed the field
• When it was changed
• What the old and new values were

Although this feature is often reviewed by the second or third line, its purpose is to empower operational users to self-monitor and prevent unintentional misconfigurations.

Enable database logging for a critical table such as VendBankAccount and show the change log after a test update.

System administration > Setup > Database log > Database log setup

Sample Scenario: Let’s walk through an end-to-end example that shows how Line 1 is supported in a real-life AP process:

1. Vendor clerk initiates a vendor change request via the Vendor changes workflow.

2. Workflow routes the request to an AP supervisor for approval.

3. The clerk creates a vendor invoice journal and submits it into Journal approval workflow.

4. The invoice is posted only after a second-level approver signs off.

5. Security roles and SoD rules ensure the same user cannot both create a vendor and approve their invoices.

6. Any change made to vendor bank info is recorded in the Database Log.

Each of these activities is completed by a business user—not the compliance or IT team—meaning risk is being managed where it originates: within business operations.

CONCLUSION

Operational users are the first line of defense in managing risk within Dynamics 365 Finance and Operations. As shown in this article, D365FO provides native capabilities—such as role-based security, segregation of duties enforcement, workflow approvals, and field-level logging—that enable these users to execute controls effectively as part of their daily responsibilities. Embedding such functionality directly into core processes ensures that risks are addressed where they originate: within business operations.

This article is the first in a three-part series on enabling the Three Lines of Defense in D365FO. The next installment will focus on Line 2: Risk and Compliance, and how system capabilities can support oversight, guidance, and control monitoring activities.

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.

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.