Maconomy security model: from access control to D365 role-based security, segregation of duties, and split-platform licensing

How Maconomy's access-control model — roles, company access, approval authority, and service identities — translates into D365's role/duty/privilege framework, organisation-scoped security, and the licensing obligations of a split Finance/Dataverse architecture.

What you will be able to do

• Describe how Maconomy access control maps to D365 roles, duties, and privileges
• Explain legal-entity and business-unit scoping in D365 versus Maconomy company access
• Design a segregation-of-duties policy that spans Finance and Dataverse where Project Operations is selected
• Identify licensing obligations introduced by adding Project Operations or Dynamics 365 Sales
• Plan the migration of service accounts, OAuth applications, and privileged administration

Introduction

Maconomy provides access control through roles that grant function-level and company-level entitlements, approval authority through workflow configuration, and authentication through modern identity protocols including OAuth and multi-factor authentication.

The D365 security framework

D365 Finance uses a layered security model that differs structurally from most source systems:

From company access to organisation-scoped security

In Maconomy, a user's access to a company is a discrete assignment: the user either has access to Company A or does not. D365 provides multiple scoping mechanisms:

Segregation of duties

Segregation of duties is not an afterthought — it is a design input that constrains how roles are assembled. D365 provides system-enforced SoD through SecuritySegregationOfDuties rules:

Split-platform security: Finance and Dataverse

When Project Operations is selected, the security design spans two independent platforms:

Service accounts, integration identities, and privileged access

Maconomy integrations may use named service accounts with broad system access. D365 replaces this with Microsoft Entra application registrations:

Licensing implications of the target architecture

Security design and licensing are coupled. The programme must understand which licences each user population requires:

Authentication and identity

Maconomy supports modern authentication including OAuth and multi-factor. D365 uses Microsoft Entra ID exclusively for authentication:

Batch and background job security

batch jobs execute under the submitting user's identity or a designated service account; batch groups control which Application Object Server (AOS) nodes process which jobs; job-level permissions are governed by the executing user's security role;

Joiner, mover, leaver and access review

Automation through Entra lifecycle workflows, group-based assignment, and access-review campaigns replaces manual provisioning and reduces the risk of orphaned access.

Knowledge check

Summary

Maconomy's access-control model provides the input — who needs access to what — but the D365 target requires a fundamentally different expression of that intent through roles, duties, privileges, and organisation scope.