Friday, March 28, 2025

Practical Guide to General Ledger Allocations in Dynamics 365 Finance and Operations












PRACTICAL GUIDE TO GENERAL LEDGER ALLOCATIONS IN DYNAMICS 365 FINANCE AND OPERATIONS

CONTENT

Introduction
How to fit into month-end process
Use cases
Allocation rule types
Real Business Scenario
Conclusion

INTRODUCTION

In Dynamics 365 Finance and Operations (D365FO), allocation journals are used to systematically distribute general ledger (GL) account balances across multiple accounts, departments, or financial dimensions based on predefined rules. These rules can support both fixed and variable allocations, helping automate routine distribution processes. 

This article explains the logic of the allocation process, its types, and provides an end-to-end demonstration through a real business scenario.

Let's get started.

HOW TO FIT INTO MONTH-END PROCESS

Allocation journals are used to distribute amounts from one financial dimension or account to others based on a defined logic (e.g., percentages, fixed amounts). They’re often created and posted during the month-end close for the following reasons:

  • Accurate Departmental Reporting: You want each department or project to reflect its fair share of corporate costs.
  • Consistent and Repeatable Process: Allocation journals can be automated using predefined rules and run at each month-end.
  • Auditability: D365FO lets you post allocations as actual ledger journal entries, which helps with transparency and audit trails.

ALLOCATION RULE TYPES










1. Fixed Percentage

Distributes the source amount based on predefined percentages.

  • Use case: You know the exact percentage split (e.g., 40% to Department A, 60% to Department B).
  • Setup: You define a list of destination accounts/dimensions and assign a percentage to each.

Example:

You allocate $1,000 from the IT expense account:

  • Dept A: 40% → $400
  • Dept B: 60% → $600

2. Fixed Weight

Distributes the source amount based on weight factors, which are not percentages. D365FO calculates the distribution ratio based on the relative weights.

  • Use case: You have proportional metrics (e.g., square footage, number of PCs) but not exact percentages.
  • Setup: You assign weight values (like 2, 3, 5) to each destination, and D365FO does the math.

Example:

You allocate $1,000 based on weights:

  • Dept A: 2
  • Dept B: 3
  • Dept C: 5
  • Total weight = 10
  • Allocated: A: $200, B: $300, C: $500

3. Equally

Splits the source amount evenly across all specified destinations.

  • Use case: You want a simple equal split across all recipients.
  • Setup: You list the destination dimensions, and D365FO splits the amount evenly.

Example:

You allocate $900 equally to three departments:

  • Dept A: $300
  • Dept B: $300
  • Dept C: $300

4. Basis

Distribute the source amount based on the selected main account and/or financial dimension balances. If the account is a statistical account, the balance may reflect figures such as the total number of employees or the square footage of a facility.

  • Use case: You want to distribute marketing expenses across departments based on their head counts.
  • Setup: You define statistical accounts, and D365FO splits the amount based on the account balances (head counts).

Example:

You allocate $1,000 marketing expenses based on number of department employees:

  • Dept A: 7 people  → $233
  • Dept B: 13 peopl → $433
  • Dept C: 10 peopl → $333

USE CASES

Here are some common use cases:

1. Monthly Overhead Allocation

Use Case: Allocate indirect costs (e.g., utilities, rent, insurance or administrative salaries) to cost centers or departments.

Example: Rent of $50,000 is allocated to departments based on square footage.

2. Marketing or Sales Campaign Cost Allocation

Use Case: Allocate campaign expenses to various products, business lines, or regions.

Example: A $100,000 campaign is split among 5 product lines based on projected revenue contribution.

3. Intercompany Cost Allocations

Use Case: Allocate costs between different legal entities within the same organization.

Example: Corporate headquarters costs are allocated to subsidiaries.

4. Statistical Allocation Based on Ledger or Statistical Accounts

Use Case: Allocate costs based on statistical measures like machine hours, labor hours, or square footage.

Example: Maintenance costs are distributed based on machine usage hours tracked in statistical accounts.

5. Period-End Accruals and Adjustments

Use Case: Perform recurring allocations for accruals, amortizations, or revenue/cost deferrals.

Example: Amortizing an annual insurance cost monthly across the fiscal year.

6. Allocation of Payroll Costs

Use Case: Allocate salaries and wages to projects, departments, or cost centers.

Example: A project manager's salary is split 50/50 between two active projects.

7. Budget Allocations

Use Case: Distribute budgeted amounts across accounts or dimensions for planning and analysis.

Example: A marketing budget is allocated to various campaigns or geographies.

REAL BUSINESS SCENARIO

The company has $12,000 of IT expenses posted to a shared IT department. The goal is to reallocate this cost to three departments based on fixed percentages:

  • Dept A – 20%
  • Dept B – 30%
  • Dept C – 50%

We’ll create a ledger allocation rule, and run it to generate a journal that moves the expense from the shared IT department to the other three.

Step 1: Create the Ledger Allocation Rule

Navigate to General ledger >> Allocations >> Ledger allocation rules.

Click +New.

Rule name: IT_ALLOC_FIXED.

Description: IT cost allocation by fixed percentage.

Switch to General tab.

Select the allocation method Fixed percentage.

Select the allocation journal name.

Click Source.

Click +New.

Select IT Expense Account.


Click destination.



Click +New.

Enter the Fixed percentage value as 20.

Select To account as 601410.

Select the first department.


Activate the allocation rule.


Step 2: Run the Allocation Rule

Navigate to General ledger >> Allocations >> Process allocation request.

Select the rule.



Click OK.

Step 3: Review the Allocation Journal

Navigate to General ledger >> Allocations >> Allocation journals


Note that New button is not active since an allocation journal cannot be created manually. It has to be generated by the system based on the allocation rules.

Click Lines.


Review the journal lines. These entries mean:

You’re debiting Dept A/B/C for the new allocated amounts

You’re crediting the IT Dept to remove the cost

All is happening within account 601410 in our example.

Step 4: Post the Allocation Journal

Click Validate (to check for errors) and then click Post.




Done! The allocation is now posted in your GL.

CONCLUSION

Allocation journals in Dynamics 365 Finance and Operations are essential for systematically distributing costs across financial dimensions based on predefined logic. They support a wide range of allocation methods, including fixed percentage, weight-based, equal, and basis-driven approaches, allowing organizations to align cost distribution with operational drivers. When integrated into the month-end process, these journals improve reporting accuracy, support auditability, and reduce manual adjustments. A well-defined allocation setup ensures consistency, simplifies recurring entries, and enhances the transparency of financial data across departments or legal entities.

Sunday, March 16, 2025

Understanding Azure App Registration and Client Secrets in Real-Life Scenarios


UNDERSTANDING AZURE APP REGISTRATION AND CLIENT SECRETS IN REAL-LIFE SCENARIOS

CONTENT

Introduction
What is Azure App Registration?
Understanding Client Secrets
Real Business Scenario
Best Practices for App Registration and Client Secrets
Conclusion

INTRODUCTION

Modern businesses rely on cloud-based applications like Dynamics 365, Power Apps, and various third-party services. To ensure seamless integration, secure authentication, and automated data access, organizations need a structured approach. Azure App Registration, a component of Microsoft Entra ID (formerly Azure Active Directory), plays a crucial role in enabling applications to authenticate securely without manual user intervention.

This article provides a practical understanding of Azure App Registration and Client Secrets, explaining their significance, implementation, and real-world applications. You will learn:

  • Why Azure App Registration is a must for modern business apps
  • How Client Secrets facilitate secure authentication
  • A real-life example demonstrating automation using there technologies
  • Best practices to enhance security and operational efficiency

Let's get started.

WHAT IS AZURE APP REGISTRATION?

Azure App Registration provides a secure method for applications to authenticate and interact with Microsoft services such as Dynamics 365, Microsoft 365, and Azure resources. By registering an application in Microsoft Entra ID, you establish its identity and enable secure API access:
  • Client ID: A unique identifier for the registered application, like a driver’s license number.
  • Client Secret: A confidential key used for authentication (similar to a password for the application).
  • Tenant ID: A unique identifier that associates the application with an organization’s Microsoft Entra ID directory.
Why Does Your Business Need It?
Businesses rely on secure, automated data exchange between applications to reduce manual work and improve efficiency. Without a structured authentication method, organizations often resort to insecure or inefficient workarounds, such as shared passwords or manual exports.

Azure App Registration ensures:
  • Automated Access – Business applications can retrieve and update data without user intervention.
  • Stronger Security – Eliminates the risks of storing user credentials in applications.
  • Seamless Integration – Power Apps, Power BI, and third-party tools can connect securely to Microsoft services.
  • Regulatory Compliance – Ensures controlled access to sensitive data, supporting SOX and GDPR requirements.
By implementing Azure App Registration, businesses can streamline operations while maintaining security and compliance.

UNDERSTANDING CLIENT SECRETS

A Client Secret is a confidential key used by an application to authenticate itself when requesting access to Microsoft services. Unlike a user's password, a Client Secret is used for application-only authentication, meaning the app, not a person, is granted access to resources.

How Authentication Works with Client Secrets?
When an application wants to connect to a Microsoft service (such as Dynamics 365 or Microsoft Graph API), it follows these steps:

1. The application sends a request to the Microsoft Entra ID token endpoint, including:
  • Client ID (to identify the app)
  • Client Secret (to prove its identity)
  • Tenant ID (to specify the organization’s Azure directory)
  • Scope (defining the level of access requested)
2. Microsoft Entra ID verifies the credentials and, if valid, issues an OAuth 2.0 access token.
3. The application uses this token to securely interact with Microsoft services (e.g., retrieving user-role data from D365FO).
4. The access token expires after a set period, requiring the app to request a new token using the same process.

Security Considerations
  • Do not store Client Secrets in source code or environment variables.
  • Use Azure Key Vault to store and manage Client Secrets securely.
  • Implement token expiration policies and regularly rotate secrets.
  • Consider Managed Identities as a more secure alternative for Azure-hosted applications, eliminating the need for Client Secrets altogether.

REAL BUSINESS SCENARIO

Let’s dive into a scenario of how companies use Azure App Registration and Client Secrets to tackle real-world problems.




Scenario: Automating D365FO User Access Reviews

Problem Statement: A financial services company using Dynamics 365 Finance & Operations (D365FO) needs to conduct periodic user access reviews for SOX compliance. The challenges include:
  • User-role assignments must be reviewed periodically, but manually exporting the data is time-consuming.
  • IT cannot grant auditors direct access to sensitive security data.
  • Managers require an intuitive way to review and approve access assignments without using complex processes/reports.
Solution: Automating Access Reviews with Power Platform
  • By leveraging Azure App Registration, Power Automate, and Power BI, the company automates user access reviews as follows.
  • The company needs an automated process to extract user-role assignments, store them in Power Apps for review, and visualize them in Power BI for compliance reporting.
This solution automatically extracts user-role assignments from D365FO, stores them in Dataverse (Power Apps Table), and provides a Power BI dashboard for monitoring. 

Main solution steps are as follows:
  • Register an App in Azure AD for Secure Access
  • Extract User-Role Assignments from D365FO
  • Store and Process Data in Power Apps
  • Generate Power BI Dashboards for Compliance Teams
Step 1: Register an App in Azure AD for Secure Access

To access D365FO data via APIs, we need to register an application in Azure AD.

1. Go to Azure AD:
  • Click + Add > App registration.

2. Register the App:
  • Name: D365FO User Access Review App
  • Supported account types: Choose Single Tenant (if internal) or Multi-Tenant (if external users need access). The purpose of this selection is to let a internal or a third party application to communicate.  Select Single Tenant for internal use.
  • Redirect URI (optional): Leave this field blank, as it is not required for this scenario. It is only needed in user login scenarios where a Power App relies on a human user signing in with their own Microsoft credentials (e.g., their D365FO or Microsoft 365 login) to access data. In contrast, this setup involves the app running independently with its own credentials (Client ID and Secret). Technically, such user-based authentication falls under a “delegated permissions” scenario, where the app acts on behalf of the user by using their identity to authenticate.
  • Click Register.

3. Grant API Permissions for D365 Finance and Operations Access:
  • Go to API Permissions > + Add a permission
  • Select Dynamics ERP.
  • Choose permission type:
    • Application Permissions: Use this if your Power App runs without a user logging in (e.g., a Power Automate flow pulling data automatically). This is “app-only” access, using the Client ID and Secret. This fits best in our scenario.
    • Delegated Permissions: Use this if a user signs into the Power App and it pulls data on their behalf (e.g., they click a button to refresh the list). This uses the user’s login.
  • Go to API Permissions > + Add a permission
  • Select the permission level.
  • Click Add permissions.
  • Grant admin consent: Azure AD requires an admin to approve these permissions before they’re active. This ensures only authorized apps get access to D365FO. 
    • If you are admin, click Grant admin consent for <your tenant>.
4. Generate Authentication Credentials
  • Go to Certificates & secrets > Client secrets.
  • Click + New client secret.
  • Set an expiration date.
  • Click Add.
  • Copy the Secret Value. It won't be visible later.
5. Store the Credentials Securely
  • Save Client ID, Tenant ID, and Client Secret in a secure location (Azure Key Vault recommended).
Step 2: Extract User-Role Assignments from D365FO

Once the Azure AD app is registered, you can extract security role assignments from D365FO using data entities.

1. Identify the Data Entity:
  • Use System administration >> Data management workspace in D365FO.
  • Locate the entity "Security user role association"(SecurityUserRoleAssociations).
2. Export data manually for testing.
3. Automate data extraction
  • Use the OAuth 2.0 token obtained from Microsoft Entra ID.
  • Call the OData API endpoint to fetch security role data.
Automate data extraction with OData API: Power Apps (or any external service) needs to use OAuth 2.0 authentication to securely access the SecurityUserRoleAssociations data entity in D365 Finance & Operations (D365FO).
  • You must construct an OAuth 2.0 access token using your Client ID, Client Secret, and Tenant ID before making API calls to D365FO.
  • Extract data in JSON or CSV format for further processing.
4. Schedule Automated Extraction
  • Schedule periodic data extraction using Power Automate or Azure Logic Apps.
Step 3: Store and Process Data in Power Apps

1. Use Dataverse to store extracted data securely.
2. Create a Power App that allows compliance teams to:
  • Review user-role assignments (by sending D365FO security data to Power Apps) in an interactive interface.
  • Approve or reject access changes based on predefined policies.
3. Automate Review Notifications: Use Power Automate to trigger notifications to compliance teams:
  • Send alerts when new roles are assigned.
  • Flag high-risk role assignments for immediate review.
  • Generate audit logs for tracking access reviews.
Step 4: Generate Power BI Dashboards for Compliance Teams

1. Connect Power BI to Dataverse to visualize access review data dynamically.
2. Create Key Reports displaying:
  • Users with excessive roles.
  • Pending access approvals by managers.
  • Trends in security role assignments over time.
3. Enable Automated Report Generation
  • Set up scheduled reports for audit teams.
  • Generate compliance reports with key risk indicators.

BEST PRACTICES FOR APP REGISTRATION AND CLIENT SECRETS

1. Use Azure Key Vault to store Client Secrets securely.
2. Enable Role-Based Access Control (RBAC) to restrict secret access.
3. Implement token expiration policies and rotate Client Secrets periodically.
4. Prefer Managed Identities for Azure-hosted applications to avoid using Client Secrets.
5. Use Conditional Access Policies to limit app access based on security conditions.

CONCLUSION

Azure App Registration and Client Secrets play a vital role in enabling secure, automated application authentication in Microsoft environments. By understanding how to configure them properly and following best practices, businesses can streamline operations, enhance security, and ensure compliance.

Through real-world scenarios like automating D365FO user access reviews, organizations can see the tangible benefits of leveraging these technologies efficiently. With proper implementation and security controls, Azure App Registration provides a robust solution for modern enterprise applications.

Monday, March 3, 2025

Decoding Security Changes in D365FO - A Deep Dive into Object Identifiers



















DECODING SECURITY CHANGES IN D365FO - A DEEP DIVE INTO OBJECT IDENTIFIERS

CONTENT

Introduction
Audit Data Form Basics
Three Buttons: A Quick Intro
Zooming in: Show Object Identifiers
Practical Examples
Conclusion

INTRODUCTION

Security configuration in Microsoft Dynamics 365 Finance and Operations (D365FO) is a form—shaping roles, duties, and privileges to match business needs while ensuring control and traceability. The Security Configuration’s Audit Data Form, accessible via System Administration > Security > Security Configuration, is your lens into those changes, logging every adjustment with precision. This form isn’t just a record—it’s equipped with tools like the Show Object Identifiers, View Permissions, and Compare Permissions buttons, each offering a unique angle on your security setup. While all three are powerful, Show Object Identifiers stands out for unveiling the technical essence of your configurations, making it a key ally for functional consultants.

Let’s dive into details.

AUDIT DATA FORM BASICS

The Audit Data Form is a longtime feature, reached by navigating to Security Configuration, selecting a role, duty, or privilege, and clicking the Audit Data button—a familiar fixture for D365FO admins. It presents a grid of essentials: the user ID of who made the change, the timestamp (e.g., March 16, 2025, 7:30 PM PDT), the event type (creation, modification), and what was altered—like adding “Generate purchase orders” to the “Purchasing Agent” role. It’s your foundation for tracking security moves, built into the system for years and relied upon for accountability and troubleshooting.

THREE BUTTONS: A QUICK INTRO

The form’s real depth comes from its trio of buttons:

  • Show Object Identifiers: Reveals technical IDs (AOT names or GUIDs) behind security objects, linking your work to the system’s core.
  • View Permissions: Details the permissions tied to an object, showing what access it unlocks.
  • Compare Permissions: Compares permissions before and after a change, highlighting shifts.

While View Permissions and Compare Permissions excel at scope and change analysis, Show Object Identifiers takes the lead for its ability to expose the technical DNA of your security objects. Let’s explore it in depth.

ZOOMING IN: SHOW OBJECT IDENTIFIERS

Hit Show Object Identifiers in the Audit Data Form, and you’re peering into the system’s blueprint. For standard roles or duties, it displays AOT names—readable labels from the Application Object Tree (AOT), like PurchasingAgent for the “Purchasing Agent” role, VendTableEdit for vendor edits, or InventJournalPost for posting inventory journals. These tie directly to D365FO’s metadata, offering a clear map for developers and savvy consultants alike.

Create a custom role, though, and it shifts gears: you’ll see a GUID (Globally Unique Identifier)—think 6ce4069a-9009-4342-9ea4-647418c65f8e. This 36-character string isn’t random; it’s a system-assigned code ensuring your custom role is unique across all D365FO instances, environments, and tenants. Unlike AOT names for Microsoft’s prebuilt objects, GUIDs track your creations without needing AOT naming—a developer’s domain. That complexity—hyphens, hex digits—guarantees no overlap, even if two consultants craft “Custom Warehouse Manager” roles independently.

Navigate to System administration >> Security configuration.

Click Audit data button.


All security layer changes are listed in Audit data form.

Click Show object identifiers.


A new column that contains system values of custom security components appears as below.


Why This Matters to a Functional Consultant

You’re configuring roles, not coding—so why bother with these identifiers? Here’s how Show Object Identifiers fits your world:

1. Precision in Collaboration

Teaming up with developers or support? “Fix my new role” is vague; “Check role 6ce4069a-9009-4342-9ea4-647418c65f8e” or “Tweak AccountsPayableClerk” is exact. It’s a direct line to the object, slashing confusion and speeding up solutions.

2. Troubleshooting with Insight

Users can’t post adjustments after you add “Manage inventory adjustments.” The Audit Data Form logs it, but the name’s broad. Show Object Identifiers might show InventJournalEntry—not InventJournalPost, the posting key. That pinpoint clarity skips the guesswork, fixing issues fast.

3. Documentation That Endures

Your process docs or client handovers shine with identifiers. “Added VendInvoiceApproval to Accounts Payable Clerk” or “Built role 6ce4069a-... with X duties” lets successors trace your work precisely in D365FO, even years later.

4. Consistency Across Environments

Moving configs from dev to production? AOT names (SalesTableEdit) and GUIDs (6ce4069a-...) stay constant, unlike display names that might shift with translations. Your security holds steady through every hop.

5. Spotting Overlaps or Gaps

Roles like “Maintain vendors” and “Approve vendor invoices” might overlap. Identifiers (VendTable vs. VendInvoiceDocument) reveal permissions, helping you catch redundancies (duplicate edits) or misses (no approval rights) without manual slog.

PRACTICAL EXAMPLES

Consider a “Warehouse Supervisor” role where “Manage inventory adjustments” doesn’t allow saving. Show Object Identifiers might display InventJournalEntry instead of InventJournalPost, pinpointing the fix. Alternatively, a custom “Order Processor” role logged as 6ce4069a-9009-4342-9ea4-647418c65f8e enables precise discussions with technical teams when access issues arise, leveraging the GUID for clarity.

Daily Necessity? Not Quite—But a Lifesaver When It Counts

This button isn’t a daily essential for standard role assignments or basic testing. Its value emerges in complex scenarios—resolving discrepancies, collaborating across teams, or ensuring accuracy in intricate setups. The GUID’s complexity is a system feature, not a consultant’s burden, but its availability enhances problem-solving capabilities.

CONCLUSION

The Show Object Identifiers button within the Audit Data Form provides functional consultants with a critical tool for navigating D365FO’s security framework. By exposing AOT names for standard objects and GUIDs for custom roles, it facilitates accurate communication, efficient troubleshooting, and robust documentation. While not required for routine tasks, its utility in addressing technical challenges and maintaining configuration integrity across environments is significant. Consultants can leverage this feature to enhance their effectiveness, ensuring security configurations are both functional and verifiable. For scenarios requiring deeper analysis or technical coordination, this button offers a reliable resource to support informed decision-making.

Practical Guide to General Ledger Allocations in Dynamics 365 Finance and Operations

PRACTICAL GUIDE TO GENERAL LEDGER ALLOCATIONS IN DYNAMICS 365 FINANCE AND OPERATIONS CONTENT Introduction How to fit into month-end process ...