Structural Modeling Best Practices: Common Mistakes That Compound Through a Project
November 7, 2026
No Comments
The first week of a new Autodesk Construction Cloud project decides more about how smoothly the next twelve months go than almost any other single step in the whole project lifecycle. Get the folder structure, roles, and permissions right at the start, and the platform stays genuinely usable as the project scales. Get it wrong, and you spend months quietly fighting a structure that was never really designed, just accumulated.
This is a practical, step-by-step walkthrough for a project admin setting up a new Construction Cloud project from scratch, written for someone doing this for real on a UAE project rather than reading abstract platform documentation.
A new ACC project begins with Document Management holding a single default folder — Project Files — with everything else left for the project team to build. Experienced administrators strongly recommend setting up this file structure deliberately before anyone starts uploading real project content, rather than letting the structure emerge organically as files accumulate, which tends to produce an inconsistent mess that’s genuinely difficult to reorganize later without disrupting live work.
A practical starting structure typically separates folders by discipline (Architecture, Structure, MEP), by information state (Work in Progress, Shared, Published, Archive), or often by both in a nested arrangement — discipline folders at the top level, with WIP/Shared/Published subfolders inside each. Folder organization inside Document Management follows alphabetical and numerical ordering only, so if you want folders to display in a specific logical sequence rather than alphabetically, a numbered prefix (01-WIP, 02-Shared, 03-Published) is the practical way to control that ordering.
If you’re setting up a template to reuse across multiple projects — common for firms running several similar UAE projects — the specific recommendation from experienced ACC administrators is to keep that template lean rather than comprehensive. Avoid including folders like Consumed or Shared directly in the template, since doing so risks creating duplicate or conflicting folders once the template gets applied to an actual project and those folders get created again through normal project activity. A clean, minimal template that captures your standard discipline and state structure, without baking in folders that the platform or your workflow will recreate naturally, avoids this specific headache.
Construction Cloud supports three distinct ways to grant folder access, and understanding the real tradeoff between them before you start assigning permissions saves considerable rework later.
| Permission Type | Best Suited For | Scaling Tradeoff |
|---|---|---|
| Individual | Narrow, restricted areas (e.g. admin-only folders) | Precise but becomes hard to manage as the team grows |
| Role-based | Coordination areas where function matters more than identity | Scales well; new team members inherit access automatically by role |
| Company-based | Main project folders shared across an entire firm’s team | Simple to administer; less granular within that company’s own team |
Most well-run UAE projects don’t pick just one of these — they combine them deliberately: company-based permissions for broad main folders every consultant firm needs access to, role-based permissions for coordination-specific areas where the person’s function (BIM Coordinator, Design Lead) matters more than their employer, and individual permissions reserved specifically for admin-only folders that should stay restricted to a small, named group regardless of role or company.
This is a platform mechanic worth understanding explicitly before you build out a deep folder structure: subfolder permissions must either match the parent folder’s permission level, or be set to a greater level of access — they cannot be set to a lower level than their parent. In practice, this means you can restrict a subfolder further than its parent for a specific subset of users, but you cannot use a subfolder to grant broader access than the parent folder itself allows. Planning your folder hierarchy with this rule in mind up front avoids running into a permissions dead-end once the structure is already populated with real files.
Roles in Construction Cloud are managed at the account level, under Account Admin, where an account admin can add, rename, or remove roles and set each role’s default access level — typically either Project Administrator or Project Member. A project admin retains the ability to override a role’s default access on a specific project if that particular project genuinely needs a different arrangement, but starting from a sensible account-level default for each role (BIM Coordinator, Design Lead, Site Engineer, Client Reviewer) means new project setups don’t require reinventing the same role definitions every time.
For a UAE firm running multiple concurrent projects, getting roles right once at the account level — rather than per-project — is a meaningful time saving across every subsequent project setup, and keeps access expectations consistent for staff who move between projects.
Project administrators automatically have Manage-level access across all folders, and it’s genuinely tempting, especially early in a project when things are moving fast, to grant that same broad access to more people “to keep things moving” without bottlenecking on a single admin. This is explicitly flagged by experienced administrators as a common and risky mistake — every person with Manage access can alter permissions, move or delete content, and bypass the folder-level restrictions that were set up deliberately for a reason.
The practical discipline is keeping genuine admin-level access limited to the small group who actually need it to administer the project, and handling the day-to-day need for broader upload or review access through role-based or company-based permissions at a lower access tier instead.
Construction Cloud bundles several distinct modules — Docs for document management, Model Coordination for clash detection and federated model review, Build for field management, Cost for budget tracking, and others — and not every UAE project needs every module active from day one. Activating modules your team isn’t ready to use adds configuration overhead and onboarding confusion without adding real value; the more practical approach is activating what the current project phase genuinely requires (typically Docs and Model Coordination from the design phase onward) and adding further modules — Build, Cost — as the project moves into construction and those capabilities become relevant.
A perfectly configured project structure still fails if the wider project team doesn’t understand how to use it. Practical onboarding for a new Construction Cloud project means a short, concrete walkthrough for every discipline lead — not just circulating a written guide — covering where to upload, what the WIP-to-Shared-to-Published states actually mean in practice, and who to ask when something isn’t behaving as expected. Autodesk’s own onboarding guidance for Autodesk Build specifically frames this early onboarding investment as directly shaping how smoothly the rest of the project runs on the platform.
Even a well-planned setup benefits from a genuine review after the first two or three weeks of real project activity, once actual usage patterns — not assumptions made at kickoff — reveal where the structure is working and where it’s causing friction. A folder nobody uses the way it was intended, a permission level that’s too restrictive for a role that turned out to need broader access, or a naming convention nobody is actually following consistently are all far easier to correct at week three than at month six, once hundreds of files already exist inside the structure as originally set up.
For a typical mid-sized multi-disciplinary UAE project, a realistic timeline looks like: folder structure and initial permission model decided and built in the first few days, before any real project content is uploaded; roles confirmed and any project-specific overrides applied in parallel; initial team onboarding delivered in the first week once the structure is ready to receive real uploads; and a genuine setup review scheduled for roughly three weeks in, once the team has actually been using the system under real project pressure rather than in a sandbox.
A setup that exists only in one admin’s head is a genuine project risk, and it’s a more common gap than most teams realize until the person who built the structure moves to another project or leaves the firm entirely. Writing down the actual folder logic, the permission model and why specific roles were given specific access levels, and the naming convention in a short, concrete reference document — not a lengthy policy nobody will read, just enough that a new project admin can understand the reasoning in ten minutes — protects the setup from quietly degrading every time there’s a staffing change on the project.
This matters more on longer UAE projects than it might seem at first glance. A project running two or three years will very likely see its original BIM Coordinator or project admin move on at some point, and a successor inheriting an undocumented structure tends to either leave it alone out of caution — even where it genuinely needs adjusting — or change things without understanding why they were set up a particular way in the first place, reintroducing problems the original setup had already solved.
A genuinely practical headache on larger UAE projects is the steady stream of access requests from consultants, subcontractors, and client representatives joining the project at different points, each needing a specific, often narrower slice of access than a full project team member. Handling these requests consistently — rather than granting whatever access level is fastest to set up in the moment — depends on having the role and company-based permission structure from Steps 3 and 5 actually built out clearly enough that a new access request maps cleanly onto an existing role, rather than requiring a bespoke permission decision every single time someone new joins the project.
Projects that skip this groundwork tend to accumulate a messy, inconsistent patchwork of individual permission grants over time, where nobody — including the project admin who granted them — can confidently explain months later why a particular person has the specific access they have. Revisiting and cleaning up that patchwork later is considerably more work than building the role structure properly in week one would have been.
Many UAE projects don’t run as one continuous phase from design through handover — they move through distinct stages (concept, detailed design, tender, construction, as-built) sometimes with gaps between them, or with a different lead consultant taking over at a later stage than the one that started the project. A Construction Cloud setup that assumes one continuous team from day one to handover can run into real friction when a new contractor or consultant joins partway through and needs to be onboarded into an existing, already-populated structure rather than a fresh one.
Planning for this explicitly — documenting the structure clearly enough that a new stage’s incoming team can be onboarded efficiently, and deciding in advance how access gets transferred or expanded as the project moves between stages — avoids a scramble later when a transition point arrives and the project admin realizes the current structure wasn’t really built with that handover in mind.
Reading a setup guide gets a project admin most of the way there, but the genuinely useful skill — knowing how permission inheritance actually behaves once you’ve built three levels of nested folders, or recognizing when a role definition needs adjusting versus when the real problem is a training gap — comes from doing this hands-on, on a realistic project structure, rather than only on a live project where mistakes are expensive to unwind. Orbit’s BIM 360 / Construction Cloud course in Dubai works through exactly this setup process hands-on, covering folder structure, permissions, and role configuration as practical, repeatable admin skills.
Before inviting the full project team in and letting real content flow, it’s worth running through a short, concrete checklist rather than trusting that each step above was done thoroughly. Confirm the folder structure reflects actual project discipline and phase needs rather than a generic template applied without adjustment. Confirm permission levels have actually been tested — not just assigned — by having a sample user from each role try to access what they should and attempt what they shouldn’t, catching misconfigurations before the whole team is relying on them. Confirm the naming convention is written down somewhere every team member can actually find it, not buried in a document nobody’s opened since kickoff. And confirm there’s a genuinely clear answer to “who do I contact if something isn’t working” — because that question will come up in week one regardless of how well everything else was set up, and a vague answer there undermines confidence in the whole system before it’s had a chance to prove itself.
A single default folder called Project Files. Everything beyond that — discipline folders, WIP/Shared/Published states, subfolder structure — has to be deliberately built by the project team rather than assumed to exist automatically.
Most well-run projects use a combination: company-based permissions for broad main folders, role-based permissions for coordination-specific areas, and individual permissions reserved for genuinely restricted, admin-only folders. Picking just one approach for an entire project usually under-serves some part of the team.
No — subfolder permissions must match or exceed the parent folder’s permission level. You can restrict a subfolder further than its parent, but you cannot use it to grant broader access than the parent folder allows.
Granting broad Manage-level admin access to more people than genuinely need it, often to avoid bottlenecking on a single admin early in a project. This undermines the folder-level restrictions the structure was built to enforce.
No — activate what the current project phase genuinely needs (typically Docs and Model Coordination during design) and add further modules like Build or Cost as the project reaches the phases where those capabilities become relevant.
Sources consulted: IMAGINiT — ACC Best Practice: Folder Setup, IMAGINiT — ACC Best Practice: Permission Setup, IMAGINiT — Managing Roles for Autodesk Construction Cloud, Autodesk — Onboarding to Autodesk Build.