Skip to main content

Electronic Signatures in Dynamics 365 Finance and Operations

I recently came across the Electronic Signatures feature in Microsoft Dynamics 365 Finance and Operations (D365FO) that enables secure authorization of critical changes or actions within the system. Traditionally, security roles are used to manage access and control edits, but electronic signatures provide an alternative layer of control—especially for regulated industries or audit-sensitive environments.

What is an electronic signature?

An electronic signature confirms the identity of a person who is about to start or approve a computing process. In some industries, an electronic signature is as legally binding as a handwritten signature. You can use electronic signatures for critical business processes. Some processes have built-in electronic signature capabilities. You can also create custom signature requirements for any database table and field.

Electronic signatures have built-in digital signature functionality. Every user who signs documents must obtain a valid cryptographic certificate. When a document is signed, the private key that is associated with that certificate is validated. Electronic signature information is recorded in a log to provide an audit trail. To set up electronic signatures, see Set up electronic signatures.

Electronic signature example

Let’s review with a simple example.
Set up reason codes for electronic signatures
Before electronic signatures can be used, you must set up reason codes. A valid reason code is required whenever a document is signed. The reason code indicates the purpose of the electronic signature. For example, a reason code can indicate legal approval.
  1. Go to Organization administration > Setup > Electronic signature > Electronic signature reason codes.
  2. Select New and in the Reason code field, enter a value.
  3. Enter a value in the Description field.
  4. Select Save and Close the page.

Electronic signature requirements

Go to Organization administration > Setup > Electronic signature > Electronic signature requirements to create a custom requirement for electronic signatures
  1. Go to Organization administration > Setup > Electronic signature > Electronic signature requirements.
  2. Select New and in the Name field, enter a name for the process that requires electronic signatures.
  3. In the Table name field, select the dropdown button to open the lookup. Find and select the table that store the data that must be signed. Then select the link in the selected row.
  4. In the Field name field, select the dropdown button to open the lookup. Find and select the table field that you want to monitor. 
  5. Select one of the following values to specify when a signature is required, the Save and Close the page.

In the screenshot above, I selected the table name 'CustTable' and the field 'PaymMode', then enabled the 'Signature required' toggle. While this toggle is enabled, the system will always trigger an electronic signature validation when the 'Method of payment' field is updated on the Customer table.


The Method of payment was initially set to 'Check'. I changed it to 'Refund' and clicked the Save button, which triggered the Electronic Signature window. Both the Reason Code and Comments fields were mandatory, and after entering the required information, I clicked OK to complete the action.
Labels:

Comments

Post a Comment

Popular posts from this blog

User Security Governance (Preview) feature in D365 FO

Let's take a first look at User security governance . It is the latest set of features in the D365F&O 10.0.43 update which provides useful tools to System administrators for role management, licenses auditing, enhanced audit trails and versioning, supported with some useful very useful reports around license usage, separation of duties violations etc. Key aspects of this feature include: Role Management: Improved tools for creating, modifying, and managing user roles. Audit Trails: Enhanced tracking of changes made to security settings, helping administrators monitor and review security configurations. Compliance: Tools to ensure that security settings comply with organizational policies and regulatory requirements. Feature management A new feature called (Preview) User security governance has been added to Feature management to control the overall functionality. Navigate to System administration > Security > Security governance to explore all the features. Security analy...
Post a Comment
Read more

Conditionally Hiding Menu Items in D365 FinOps Menus Without Using Feature Keys

In Microsoft Dynamics 365 Finance and Operations (D365 F&O), menu items are the links that can be clicked on to access forms, reports, classes, jobs, and queries. Feature keys are typically used to control the visibility of menu items based on user licenses. However, there are scenarios where you might want to hide menu items conditionally without relying on feature keys.  This can be accomplished by extending the 'SysMenuNavigationObjectFactory' class and modifying the checkAddSubMenu(...) method.  Suppose we want to hide the  Vendor payment journal menu item under Accounts payable > Payments > Vendor payment journal Steps 1. Create an extension of the SysMenuNavigationObjectFactory class [ ExtensionOf ( classStr (SysMenuNavigationObjectFactory))] internal final class SysMenuNavigationObjectFactory_PS_Extension { } 2. Create a Chain of Command (CoC) for the checkAddSubMenu method [ ExtensionOf ( classStr (SysMenuNavigationObjectFactory))] internal final...
Post a Comment
Read more

Microsoft Dynamics 365 FSCM Licensing - New Multi-License Mapping on Menu Items

Licensing in enterprise systems has long been a game of mapping menu items to license types, ticking boxes, and hoping your role design didn’t trigger unexpected costs. But with the 2025 updates to Dynamics 365 Finance and Operations, Microsoft has flipped the script—ushering in a smarter, more flexible model that reflects how users actually work. Let’s break it down. In the legacy model, each menu item was tied to a single license type. For instance, if a user accessed MenuItemA that had a Finance license type on it, they needed a Finance license. If they accessed MenuItemB with SCM assigned on it, they needed SCM. Simple? Yes. But also rigid, prone to over-licensing, and blind to real-world role overlap. Example:  This model treated licensing like a static blueprint—ignoring the nuance of blended roles, attach licenses, and shared responsibilities across departments. Fast forward to 2025. Microsoft’s new licensing logic is object-level, dynamic, and context-aware. Now, a single m...
2 comments
Read more