How Unit4's attribute-based organisational model — where cost centres, departments and locations are dimension values, not dedicated objects — translates into D365's typed organisational hierarchy.
Unit4's organisational model is the first surface where the conceptual mismatch with D365 F&O becomes visible, and it conditions every later decision about dimensions, posting rules and consolidation.
A Client in Unit4 is the top-level isolation boundary — a separate database in ABW, or a tenant partition in ERPx. Each Client has its own configuration, its own currency setup, its own period calendar and its own master data. Clients do not share data natively; cross-Client reporting is an extract-and-consolidate exercise.
Below Company level, Unit4 has no formal organisational hierarchy. There is no equivalent of SAP's Plant, no equivalent of IFS's Site. Instead, operational structure is encoded as Attribute Values on the chart of accounts — typically the A2 attribute for Cost Centre or Responsibility Centre, A4 for Department, Faculty or Service Line,…
Unit4 does not allow any Attribute Value to be combined with any Account on any posting line. The constraint mechanism is the Account Rule (covered in depth in the Posting Engine module), but at the organisational level the key behaviour is this: an Attribute Value can be explicitly permitted, required or forbidden for a given Account…
The mapping target in D365 is not a single object but a split across multiple D365 constructs:
The consequence of Unit4 having no dedicated org objects below Company is that the D365 org design must be built from first principles, informed by how Attribute Values are actually used rather than what they are labelled.
Unit4's Relation is a polymorphic master record. The same acrrelation row can be a Customer, Supplier and Employee at the same time, with Relation Type or Relation Group flags deciding which validation, workflow, FlexiFields and posting behaviour apply. D365 has no equivalent single table.
FlexiFields are not all the same thing. A field called CONTRACT_REF might mean master-service-agreement ID on a Customer Relation, framework agreement ID on a Supplier Relation and employment-contract ID on an Employee Relation. The Attribute-to-Destination matrix must therefore partition by Relation Type, not by field name alone.
The high-level mapping Company -> Legal Entity is easier to remember when the D365 tables are visible.
Several source-reference phrases are worth making explicit because they describe real migration traps.
Use this checklist to make sure the Relation-and-FlexiField model has been split into every D365 target that needs it.
Unit4's organisational model is elegant and flexible but leaves no authoritative org chart for a migration to translate. The design work is interpretation: understanding how Attribute Values are used and deciding what they should become in D365.