Strengthening Internal Controls with User Termination in D365FO

CONTENT Introduction Importance of User Termination in a SOX Environment Terminate User and Remove Their Security Roles Alternative: Disable User and Remove Their Security Roles Address Workflow Delegations Monitor Batch Jobs Monitor Disabled and Deleted Users via Database Logging Conclusion

STRENGTHENING INTERNAL CONTROLS WITH USER TERMINATION IN D365FO

Introduction

User lifecycle management is one of the most critical aspects of securing any ERP system, and Microsoft Dynamics 365 Finance and Operations (D365FO) is no exception. From the moment a user is onboarded to the time their access must be revoked, organizations must ensure that system access aligns with employment status and compliance requirements.

In a Sarbanes-Oxley (SOX) regulated environment, user termination becomes more than just a technical activity—it is a key internal control. When employees, contractors, or consultants leave the organization, their access to the system must be promptly revoked to prevent unauthorized activities, reduce fraud risk, and maintain the principle of least privilege.

This article explains the steps, options, and considerations for terminating users in D365FO. It provides practical instructions, highlights SOX compliance implications, and points out potential pitfalls if termination is not handled effectively.

Importance of User Termination in a SOX Environment

SOX Section 404 requires companies to establish and maintain adequate internal controls over financial reporting. One of these controls is ensuring that only authorized personnel have access to financial systems like D365FO.

Failure to properly terminate users creates several risks:

• Unauthorized Access: Former employees may still be able to log into the system.
• Segregation of Duties (SoD) Violations: Inactive but enabled accounts could be exploited, creating audit findings.
• Workflow Disruption: Unattended approvals may remain pending if workflow delegations are not reassigned.
• Batch Job Failures: Critical scheduled processes may stop running if they are tied to a disabled user account.

Therefore, an effective user termination process in D365FO must include technical steps (role removal, account disabling, workflow reassignment) as well as compliance checks to verify that no residual risks remain.

Terminate User and Remove Their Security Roles

The preferred approach is to terminate users directly in D365FO using the HR framework. If your environment integrates HR and system access, user termination can be initiated from the Employees form.

1. Navigate to Human Resources > Workers > Employees.

2. Select the employee record.

3. In the Action Pane, under Personnel actions, click Terminate.

4. Select the termination action, enter the termination date, and save the record.

If personnel actions workflows are enabled under HR Shared Parameters, the termination can be routed for approval before becoming effective.

5. OPTIONAL: Execute the termination workflow if selected personnel action type requires a workflow approval.

Workflow submission

  Workflow approval  

Workflow completion

Employee determination

Once the termination is processed, you should also ensure the user’s security roles are removed. This step is critical because it directly revokes system privileges and ensures compliance with SOX. 

NOTE: A standard termination workflow in Dynamics 365 for Finance and Operations (D365FO) does not automatically disable a user account. The standard workflow process in Human Resources primarily handles the worker's employment status, moving them from active to terminated. The user account and security roles must be handled separately.

6. User termination and security role removal 

User termination and security role removal - Before

User termination and security role removal - After

Alternative: Disable User and Remove Their Security Roles

In some organizations, HR and IT systems are not fully integrated, or there may be licensing constraints preventing full use of the HR module. In these cases, you can directly disable a user account in D365FO.

1. Go to System Administration > Users > Users.

2. Select the user record.

3. Toggle the Enabled field to Off.

4. Remove all assigned security roles as shown in the previous section.

This approach is faster but less structured compared to personnel action termination. However, it still meets the SOX requirement of revoking access promptly.

Address Workflow Delegations

Terminated users may still be assigned workflow tasks or delegation rules. If these are not reassigned, business processes (such as vendor invoice approvals, purchase requisition approvals, or journal approvals) could stall. There isn’t any screen that shows all delegations in D365FO, but there is a workaround — a table stores that information: WorkflowWorkItemDelegationParameters

To identify active delegations, use the following link in your environment:

<yourD365FOurl>/?mi=SysTableBrowser&tablename=WorkflowWorkItemDelegationParameters

This opens the table browser to review current workflow delegation records.

Any delegations tied to the terminated user should be reassigned to active employees.

Monitor Batch Jobs

Another critical check is to monitor background batch jobs. Many automated processes in D365FO—such as periodic invoicing, financial consolidations, or integrations—run under a specific user account. If a terminated user owns a batch job, the process may fail after their account is disabled.

To monitor this:

1. Go to System Administration > Inquiries > Batch Jobs.

2. Review the Run by field for each job.

3. Recreate critical jobs with a valid service account or another active user.

This review is especially important during offboarding to prevent system disruptions.

Monitor Disabled and Deleted Users via Database Logging

As a detective control, organizations can enable Database Logging in D365FO to track changes to user accounts. This ensures auditability of user termination activities and provides evidence during SOX testing.

Recommended logging events include:

• User creation
• User deletion
• User enabled/disabled changes
• Security role assignments and removals

For example user activation/deactivation can be followed as below:

Note that the above screen shows enabled and disabled users, giving admins full visibility to take necessary actions.

Database logging not only provides assurance but also strengthens the organization’s ability to demonstrate compliance during external audits.

Conclusion

User termination in D365FO is not just about removing access—it is about safeguarding financial data, preventing fraud, and ensuring compliance with SOX requirements. By following a structured process that includes terminating or disabling users, removing security roles, reassessing workflow delegations, monitoring batch jobs, and tracking changes through database logging, organizations can significantly reduce risk.

An effective termination process bridges the gap between IT operations and compliance, providing assurance to management, auditors, and regulators. Whether you use the HR-driven personnel action approach or the direct disablement method, what matters most is consistency, timeliness, and proper documentation.

In short, closing the door properly when a user exits is just as important as granting them access in the first place.

Enabling the Three Lines of Defense in Dynamics 365 Finance & Operations - LINE2: Risk and Compliance Oversight

ENABLING THE THREE LINES OF DEFENSE IN DYNAMICS 365 FINANCE & OPERATIONS - LINE2: RISK AND COMPLIANCE OVERSIGHT

CONTENT Introduction Line 2 Risk and Compliance Oversight in D365FO-Centric Organizations Governance Through Monitoring: A Functional View Oversight of Security Role Changes and Privilege Escalation Monitoring Segregation of Duties Violations and Exception Approvals Evaluating the Effectiveness of Workflow Controls Analyzing Field-Level Configuration Changes Performing Periodic Risk Reviews and Reporting A Second Line Scenario: From Oversight to Intervention Conclusion

INTRODUCTION 

The purpose of the Second Line of Defense within the Three Lines of Defense (3LoD) framework is not to execute business controls, but to ensure that those controls are functioning consistently, remain aligned with risk tolerance, and are subject to ongoing review. In Microsoft Dynamics 365 Finance & Operations (D365FO), Line 2 does not directly perform journal postings, approve transactions, or assign user roles—that’s the job of Line 1. Instead, Line 2 is accountable for designing policy frameworks, overseeing access governance, monitoring control adherence, and responding when execution deviates from expected behavior.

This article explains how D365FO supports Line 2 professionals—compliance officers, internal control owners, and risk managers—in supervising control environments without directly interfering with operational workflows. It is written for readers who already understand D365FO’s built-in features such as role-based access, segregation of duties (SoD), workflow approvals, and audit trails. Instead of re-explaining these tools, we focus on how Line 2 uses them for governance and monitoring purposes.

LINE 2 | RISK AND COMPLIANCE OVERSIGHT IN D365FO-CENTRIC ORGANIZATIONS

Line 2 functions as the system’s compliance backbone, tasked with embedding internal control principles into application governance. These responsibilities include:

• Establishing risk-aligned access policies
• Defining SoD rules and exception handling criteria
• Monitoring workflow effectiveness across departments
• Reviewing audit trails and configuration changes
• Providing structured guidance to Line 1 users
• Liaising with auditors and reporting on internal control health

In D365FO, these tasks can be performed using native capabilities—augmented where necessary by ISV tools like Fastpath, RSM Guardian, or custom Power BI dashboards. Line 2 does not need to rely on external documentation or manual audits. Instead, the ERP system itself becomes the control environment, enabling real-time oversight of daily operational activity.

GOVERNANCE THROUGH MONITORING: A FUNCTIONAL VIEW

While Line 1 users rely on D365FO to execute controls, Line 2 uses the same system to oversee them. Below, we explore how this oversight manifests in the application.

1. Oversight of Security Role Changes and Privilege Escalation

Access provisioning is handled by IT or business operations (Line 1), but Line 2’s responsibility is to monitor whether those assignments adhere to policy.

In practice, this involves:

• Reviewing changes in user role assignments on a regular cadence
• Identifying users who have gained elevated privileges outside of standard provisioning processes
• Investigating any deviation from the principle of least privilege

While D365FO does not natively provide historical change tracking for user-role assignments, organizations often implement supporting tools or audit reports to capture this activity. Alternatively, Database Log can be enabled to track changes in the underlying security tables.

2. Monitoring Segregation of Duties Violations and Exception Approvals

Line 2 does not create SoD rules—that’s a shared responsibility between compliance and system administrators. But Line 2 governs how these rules are enforced and how exceptions are handled.

Typical activities include:

• Reviewing SoD violation reports and understanding the business context behind them
• Approving or rejecting temporary access exceptions requested by Line 1 users
• Validating that approved exceptions have compensating controls in place (e.g., increased monitoring or dual approval)

The objective is not to prevent the business from operating efficiently, but to ensure that risk-acceptance decisions are conscious, documented, and periodically re-evaluated.

3. Evaluating the Effectiveness of Workflow Controls

While Line 1 users initiate and participate in workflows (e.g., invoice approvals, vendor edits), Line 2 has a supervisory role to play: Are those workflows functioning as intended?

Key evaluation points include:

• Are workflows consistently routing to the correct approvers?
• Are approvals happening within expected timeframes?
• Are any steps being auto-approved due to escalation thresholds?
• Is there evidence of override behavior (e.g., approval by system administrators)?

These checks are often performed using the Workflow history log in D365FO or through exported workflow datasets analyzed in Power BI.

4. Analyzing Field-Level Configuration Changes

Control failures are not always transactional—they often begin in setup and master data. A well-designed workflow or SoD policy can be rendered ineffective if a key configuration setting is changed.

Line 2’s responsibility is to track changes to sensitive fields and ensure that:

• Only authorized users are making changes to configuration records (e.g., vendor bank account, posting profiles)
• All changes are traceable and explainable
• Recurring or off-hours changes are flagged for further review

D365FO’s Database Log feature supports this type of oversight. When enabled for the appropriate tables, it records the user ID, timestamp, and before/after values for each change.

5. Performing Periodic Risk Reviews and Reporting

Line 2 is accountable for translating system data into actionable risk insight. This typically includes:

• Monthly or quarterly reports on SoD exceptions, workflow behavior, and sensitive field changes
• User access reviews for high-risk roles (e.g., system administrators, finance approvers)
• Assessment of policy violations and recurring control issues
• Recommendations to IT or Line 1 leaders for control remediation or enhancement

Tools like RSM Guardian or Fastpath streamline this process by aggregating control data into prebuilt dashboards. However, even without ISVs, D365FO’s native data entities, export functions, and logging capabilities enable meaningful review cycles—if structured properly.

SAMPLE SCENARIO: FROM OVERSIGHT TO INTERVENTION

Consider this common use case:

A temporary SoD exception was approved last month, allowing a user to both create and approve vendors.

During a monthly review, Line 2 notices that this exception is still active—even though the stated expiration date has passed.

Further investigation reveals the same user submitted and approved three vendors, one of which was used in a high-value payment.

Line 2 flags the issue, revokes the role combination, and recommends a retrospective review of the payment by Internal Audit.

This type of oversight intervention highlights the true value of Line 2 in D365FO—not just spotting violations, but ensuring controls remain active, relevant, and risk-aligned.

CONCLUSION

The Second Line of Defense brings structure, oversight, and assurance to the control environment. In Dynamics 365 Finance & Operations, Line 2 professionals are not responsible for day-to-day transactions—but they are accountable for ensuring that the system itself enforces compliance principles.

By continuously monitoring role changes, SoD conflicts, workflow behavior, and audit logs, Line 2 can enforce risk policies without disrupting operations. The end result is a governance model where compliance is embedded within the ERP—not layered on top of it.

The final article in this series will focus on Line 3: Internal Audit, where we examine how independent assurance can be delivered using D365FO’s data and reporting capabilities.

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.