80% of CDE problems are structural

When a common data environment starts to hurt, the complaints always sound like software. I cannot find anything. I do not have permission for this folder. Every team names files their own way. Search is useless. And because they sound like software, the natural reaction is to look for other software: another platform, another module, another migration.

After configuring a CDE in Forma for a large-scale airport infrastructure program, my diagnosis is different: 80% of those problems are not software problems. They come from a structure nobody sat down to design before starting.

Three decisions that solve most of it

Folders designed before creating the first one. A CDE structure should mirror how project information flows: what gets produced, who reviews it, where it gets published. When the structure copies the company org chart, every department builds its own corner, duplicates bloom, and finding the current drawing becomes an act of faith. The right structure gets designed on paper, discussed with the teams, and only then created on the platform.

Permissions by inheritance, not folder by folder. Every hand-assigned permission is a future inconsistency waiting for its moment. Inheritance does the heavy lifting: you define access at the right level of the tree and child folders receive it on their own. When someone asks for an exception, the question is not how to assign it, but why the structure is asking for it. Very often the exception is the symptom of a misplaced folder.

Modules enabled by role. Turning everything on for everyone looks generous and is the fastest way to kill adoption. A user who logs in and sees eight modules that are not theirs concludes the platform is complicated and goes back to email. Each role should see what it uses: reviewers see reviews, publishers see publishing. Adoption grows when everyone's screen looks like their job.

Design before handing out access

None of this requires buying anything. It requires something scarcer: sitting down to design before handing out access, which is exactly the step that gets skipped when everyone is in a hurry to start the project. The hurry is understandable, but the cost is high: a badly born structure does not fix itself, it degrades. Every week that passes there are more files inside, more habits formed, and more resistance to reordering.

There is a fourth practice that multiplies the other three: testing the structure before imposing it. In the airport program, no structural change went straight to production: it was built in a test hub, validated with real cases, and only then replicated to the production template. Structure is also a product, and like any product, it improves when it has a safe place to be wrong.

That is why, when a CDE feels like an enemy, my first review is not advanced configuration. It is structural: how the folders stand, how permissions inherit, what each role sees. That is where 80% of the pain lives, and 80% of the remedy too.