Hubs, Projects and Folder Architecture

Overview#

The getting-started chapter explained what a hub, a project and a folder are. This page goes one level deeper and treats the structure as an engineering decision. The way you lay out hubs, projects and folders determines who can see what, how references between designs behave when files are moved, how painful an audit or hand-over will be, and how quickly a new hire can find the current revision of a part. A structure that is "fine" for three designs becomes a daily source of friction at three hundred.

Three levels matter, and each one controls something different:

The guiding rule is: put hard walls at the hub and project level, and use folders for organisation and finer access control. If two groups must never see each other's data, they belong in different projects (or different hubs). If they merely need tidy separation or different roles on different areas, folders are enough. One caveat from Autodesk's documentation: in folders that existed before September 2026, a member with access to any folder can still see the names of every other folder in the project; projects created from that date show members only the folders they can access.

Where to find it#

• Data Panel: the list of hubs (teams) is at the top; click it to switch hubs. Projects are listed beneath, and folders appear when you open a project. You can create projects, folders, pin projects and archive projects here.
• Fusion web client: Autodesk states that you must use the Fusion web client to manage projects (members, groups, project details). Open it from the Data Panel with Open in the Web, or at the Fusion web client address.
• Project members and roles: open the project (or a folder) in the web client and choose the Members and Permissions tab.
• Project details: the Project Details tab on the right of the web client (name, image, type, activity log).
• Hub administration: profile image (top right of the web client) > Admin, with Members, Groups, Projects and Hub Settings tabs.

Hubs: how many do you need?#

Most individuals and small teams need exactly one hub. A hub is created by an administrator and is where members create, share and edit projects; a Personal-license holder owns the hub they create. Extra hubs are justified in a few cases (this list is general guidance, not Autodesk data):

1. Different legal entities or clients. A consultancy working for several clients may want a hub per client so that membership, billing and eventual data hand-over are clean.
2. Different subscriptions. Hubs map to the account that pays; separate subscriptions often mean separate hubs.
3. Acquisition or spin-off. A hub is a clean unit of ownership. If you later end up with too many hubs, a hub admin of both hubs can merge them (see below).

Reasons that are not good enough: separating departments (use projects), separating product lines (use projects), or separating "work in progress" from "released" (use folders, lifecycle or milestones).

Warning: Data cannot be dragged between hubs the way it can between projects. Autodesk's Copy across hubs command (web client, right-click > Copy across hubs) needs Reader access or higher at the source, Editor or higher at the destination folder, a destination hub in the same region, and a Fusion subscription on the destination hub that supports it. It runs as a background job, shares no references with the original, assigns a new part number, places the data in a time-stamped Copy_<hub>_<date-time> subfolder, flattens subcomponents to one level and resets history. Folder admins can also transfer whole projects across hubs. Decide the hub boundary early.

Hub merge. A hub admin of both hubs can merge two collaborative-editing hubs. The hubs are read-only during the merge, hubs with tasks or task boards are not supported, manufacturing-tool and component libraries must be exported first, and the merge is irreversible and cannot be paused. Not available in Fusion for education.

Projects: sizing and scope#

A project is the right container when a set of people share a purpose and a lifetime. Good project boundaries are:

• One product or product family. All the parts, assemblies, drawings and documentation for the "Model X Controller" live together.
• One customer engagement. Everything for a contract, which can be archived when the engagement ends.
• One shared library. Fasteners, standard brackets, purchased components, materials, templates. Libraries usually need broad read access and narrow write access, so they deserve their own project.

Poor boundaries are "everything the mechanical group does" (becomes a junk drawer, hundreds of unrelated files, permissions nobody can reason about) and "one project per person" (defeats collaboration).

Project lifetime#

Think about the end of a project when you create it. Ask: who will archive it, and when? Many teams adopt an explicit lifecycle for projects: Active, Maintenance (read-mostly, few editors), Archived. Fusion has a built-in archive state: a folder admin right-clicks the project in the Data Panel (or uses More > Archive in Fusion Home, or the drop-down in the web client) and chooses Archive. Archived projects cannot be accessed by project members. A folder admin restores them from the ARCHIVED tab in the web client, but permissions are not saved when you archive, so they must be recreated after a restore. To free storage, an archived project can be deleted; deletion is permanent, and previously shared links stop working.

Project descriptions and README files#

Folder admins can change a project's name, image and type in the Project Details panel; the documentation does not describe a free-text description field, so put purpose, owner, naming convention and contact in a README instead. Many teams also keep a short 00_README document (a PDF or text file uploaded to the project root) that describes the folder layout and rules. Autodesk also documents wiki pages in projects (web client), which suit the same purpose. It costs ten minutes and saves every future member an hour.

Folders: a layout that survives growth#

Folders can be nested. As general guidance (not an Autodesk limit), deep nesting makes paths long and navigation tedious, so aim for two to three levels in practice. Three patterns work well.

Pattern A: by function#

00_Admin
01_Requirements
02_Design
   Assemblies
   Parts
   Purchased
03_Drawings
04_Manufacturing
05_Simulation
06_Release
99_Archive

Good for single-product projects. The numeric prefixes force a stable sort order when you sort by name.

Pattern B: by subsystem#

Chassis
Drive
Electronics
Enclosure
Shared
Release

Good for mechatronic products where subsystem owners work mostly independently. Each owner controls their folder, and cross-subsystem references go through the Shared folder.

Pattern C: by status#

Work-in-progress
Review
Released
Obsolete

Tempting but dangerous. Moving a file between folders to change status makes references and external links more fragile, and it duplicates information that versions, milestones and lifecycle states (covered in the following pages) already track. If you want status, use those features, not folders. A small hybrid works: a single Released folder holding only frozen deliverables exported as PDFs or STEP files, with the working data staying put.

Tip: Keep the working design files in stable locations for their whole life. A reference holds a link to a file; moving files is supported and Fusion tracks the reference, but heavy reorganisation in a populated project will still produce a wave of "out of date" notices and confusion. Reorganise early, rarely, and announce it.

Naming conventions#

Names are the cheapest metadata you have. Pick a convention and write it down.

Rules that prevent trouble: avoid characters that other systems reject (/ \ : * ? " < > |), avoid trailing spaces, avoid "final", "final2", "new" and dates in names (versions exist precisely so you do not do this), and keep the name of the document inside Fusion identical to the filename you export so a STEP file can be traced to its source.

Part numbers belong in the component's Part Number property too, because bills of materials and drawings read that property, not the document name. When you copy a design you choose New Part Number or Shared Part Number; hub admins can enable shared part numbers and physical properties in the hub settings.

Step by step: build a standard project structure#

1. Open the Data Panel and confirm the correct hub in the hub switcher.
2. Click New Project and give it the project code name. By default a new project is secret: only you and hub admins can see it. (Creating projects needs permission from a hub admin; by default only hub admins can create projects.)
3. Open the project and use New Folder to create the top-level folders from your chosen pattern. Create them in the order you want them to appear, and keep the numeric prefixes.
4. Add a 00_Admin folder and upload the README and any templates.
5. In the web client, open the Members and Permissions tab. Add the project lead with a high role (Manager or Folder Admin), then add collaborators and groups by role. Autodesk recommends starting new members as Viewer and raising access per folder (details on the roles page).
6. Create an initial empty Fusion design in 02_Design named with your convention, set units, and save it. This verifies the folder works and gives the team a pattern to copy.
7. Share the project link with the team and ask each member to confirm they see the layout and can save a test file where they should.
8. Pin the project (hover over it in the Data Panel and click Pin) so it is easy to reach; pinned projects get a PINNED filter.

Project templates and reusable structure#

The documentation describes no one-click "template project" that clones a project with its folders. Practical alternatives:

• Keep a template project with the folder skeleton and starter documents, and use Copy (right-click a design or folder, available to Viewer or higher, with an optional Include Drawings checkbox) to copy folders and files into each new project.
• Store design templates (units, appearances, a title-block drawing template) in a shared library project, and have members start new work from them.
• Document the setup as a checklist like the one above, so it is repeatable by anyone.

Note: not confirmed in Autodesk's Fusion documentation: scripted folder creation through the Autodesk Platform Services Data Management API. It is a general option for developers and needs developer credentials; check Autodesk's platform documentation.

Cross-project references#

Designs may reference components stored in other projects, which is how shared libraries work. Consequences to plan for:

• A person opening the referencing design needs access to the referenced project, otherwise the reference cannot be loaded. (The exact minimum role is not stated in the documentation; test with a Viewer.)
• Removing a person from the library project removes their access to every design that uses it.
• Autodesk states that you can rename, copy and move designs (with their related drawings) to new folders and projects without breaking their associative relationships. When you save a new design that has design references, the Save dialog only lets you save within the same project. Use the Used In and Uses tabs afterwards to confirm.
• Prefer a small number of widely used library projects over many tiny ones.

Cleaning up and keeping the structure healthy#

Schedule a quarterly review:

• Move abandoned experiments and test files to Trash (Editor or higher). Before deleting, check the Used In tab in the Data Panel's expanded design details, which lists designs that use the file.
• Move finished work to an archive folder or project.
• Remove members who no longer work on the project.
• Check storage consumption against your plan.
• Confirm that the README still describes reality.

Deleting is a two-step process. Move to Trash puts a design or folder (with its contents and structure) in the project's Trash folder; Restore in the web client returns it to its original location, and only folder admins can Delete forever. The documentation does not state an automatic purge period for Trash.

Options reference#

Tips and pitfalls#

Tip: Name projects with a short code first (MXC Controller) so the alphabetical list groups related work and the code can double as a part-number prefix.

Tip: Create one "Sandbox" project where anyone can experiment. It keeps trial files out of product projects and can be purged freely.

Warning: Folder-level roles exist (except in legacy projects), but folder names in pre-September-2026 folders stay visible to every project member, and a design that is referenced from elsewhere can still be seen through the referencing assembly (general caution). For genuine confidentiality use separate projects. Hub admins can see all projects and their contents.

Warning: A single flat project with hundreds of files and no folders is the most common structural failure. Introduce folders before the 30th file, not after the 300th.

Warning: A Personal-license holder owns their hub, and everyone they invite has only Basic Access (view, comment, download if permitted). Do not use a personal hub as team storage.

Practice exercise#

Design a project for a small product, "Desk Lamp", that has a base, an arm, a head and a purchased LED module. Do the following:

1. Pick a project code and write the project description in one sentence.
2. Choose Pattern A or B and create the folder tree with at least five folders.
3. Define a naming rule and name the five documents you will create.
4. Add a README in the admin folder that lists the rules.
5. Create the first empty design, save it, and confirm it appears in the correct folder.

Expected result: a project any teammate could navigate without asking questions, with a documented naming rule and a saved first version.

Related#

• Roles and Permissions (this section)
• Sharing and Public Links (this section)
• Admin Console and Team Best Practices (this section)
• Getting started: Hubs and Projects
• Getting started: Data Panel Basics