The first structural decision on any implementation, and the hardest to reverse. Learn the four containers D365 offers for modelling an organisation, the tests that tell them apart, and what each choice costs you at period close, in security, and in intercompany trade.
If you take only one structural decision seriously on a Dynamics 365 Finance & Operations implementation, take this one.
Before the tests, the definitions. Each container exists to answer a different kind of question.
Run any real-world organisational unit through these questions in order. The first "yes" wins.
When a sponsor asks why you are resisting creating twelve legal entities, this is the answer. Each one brings:
An organisation hierarchy in D365 is a tree of legal entities and operating units, created for a stated purpose. The purpose is the important part: it is what makes the hierarchy do something rather than merely describe something.
A frequent source of confusion for people arriving from single-company systems is that D365 shares some data across the whole environment and scopes other data to a legal entity. Knowing which is which prevents a lot of duplicated effort.
One registered company operating from a head office, a factory and two distribution centres. This is the simplest and most common mid-market shape, and it is often modelled far more heavily than it needs to be.
Organisation designs fail in two opposite ways, and both are recoverable only at high cost.
The organisation model is the first irreversible decision on a D365 implementation, and the one most often made by analogy with the previous system rather than from first principles.