Roles and Permissions

Overview#

Access control in Fusion is layered. A person's ability to see, open, edit, delete or share a design is the combined result of their Autodesk account and license, their membership of the hub, their role in the project (directly or through a group), and possibly folder-level settings. When someone says "I cannot open that file", the cause is almost always one layer in that stack. This page explains each layer, shows how to plan access using least privilege, and gives a diagnostic routine.

The getting-started chapter lists the basic roles. Here we focus on the model underneath, how hub groups and folder-level roles combine, how permissions interact with references and sharing, and how the model compares with the separate permission system in Fusion Manage.

Note: Folder-level roles do not apply to legacy projects. Autodesk's documentation points to an Autodesk Support article, "How to upgrade a Legacy project to Folder-Level project in Autodesk Fusion", for teams that have not used Fusion in a while. Everything on this page describes folder-level projects.

Where to find it#

• Project members and roles: open the project (or one of its folders) in the Fusion web client and choose the Members and Permissions tab. Autodesk states that projects must be managed in the web client.
• Hub members, groups and hub-level options: profile image (top right) > Admin, then the Members, Groups, Projects and Hub Settings tabs.
• Account-level user management and licences: the Autodesk Account portal (covered in the admin page); licences are assigned to hub members (see Assign licenses to hub members in the Get Started help).

The layers of access#

Layer 1: Identity and license#

Everyone is an Autodesk ID. To edit in Fusion, a person needs a Fusion license assigned to them (or an education or Personal license). A person with Basic Access can still view projects and files including design history, comment and mark up files, and download files if their permissions allow. Basic Access applies when a license term expires, and when a Personal-license holder works in someone else's hub; everyone a Personal-license holder invites to their own hub also gets only Basic Access. So do not assume a hobbyist partner can co-edit your commercial team's data.

Layer 2: Hub membership#

A hub is created by an administrator and usually needs an invitation or approval to join. Hub roles are Member (can create and save Fusion designs) and Hub admin (member permissions, hub settings, security and other admin tasks). A separate Project creator toggle lets a member create projects; by default only hub admins can. (A Project contributor role is described as a legacy role no longer in use; avoid it.) Who may invite people is a hub setting: Admin invite only, Admin approval required, or No admin approval required. Role changes take effect immediately. Being in the hub does not automatically grant access to every project: a new project is secret, visible only to its creator and hub admins, until members are invited. Hub admins can see all projects and their contents.

Layer 3: Project and folder role#

Fusion has five roles. Permissions are cumulative: each role includes everything the roles below it can do.

The permissions reference also covers wiki pages (view, create and edit, delete and restore), project-member tasks (view members and roles, invite members and set access, remove members from a folder, create and manage groups, activate or deactivate members), and files and folders (view online, comment, open with Fusion, download, copy, create and edit, upload, rename, move, generate and share a public link, delete and restore, delete permanently). Use that table, not this summary, for the exact cell for a given role.

Some specific rules from the documentation: copying a design needs Viewer or higher at the source and Editor or higher at the destination; copying across hubs needs Reader at the source and Editor at the destination; Trash needs Editor or higher, and only folder admins can delete forever; archiving or restoring a project is a folder-admin task.

Layer 4: Groups#

Only hub admins can create and manage groups, and only in the Fusion web client. Groups must have unique names within a hub, cannot be nested, and cannot contain inactive hub members. A group counts as one member toward the 500-member project maximum, which is one reason to use them. All members of a group receive the group's role on the folder it is added to, but those permissions are superseded if the person has a higher role elsewhere (another group, a parent folder or a direct assignment): the highest role wins. Benefits: onboarding is one action, offboarding is one action, and an audit is readable. In the invite box you can also select Everyone to give the whole hub access, including future hub members.

Layer 5: Folder roles#

A member's project role is automatically applied to all of its folders and subfolders. A member can be given a higher role on a specific folder, which affects only that folder and its subfolders. A member cannot be given a lower role on a subfolder than on its parent, and a member can be assigned to a folder without having any project-level role. Autodesk recommends giving new members Viewer on the project and then raising access on specific folders. In practice this means a Released folder cannot be made more restrictive than the project role for a member: give the member no project role and grant access per folder instead (the No role option removes all permissions).

Inheritance rule: a subfolder inherits from its parent; overrides may only raise access. Overrides should be rare, because each one has to be discovered by a future administrator.

Planning least privilege#

A usable method in five steps (a general method, not an Autodesk procedure):

1. List the personas, not the people. For example: Design Engineer, Checker, Manufacturing Engineer, Supplier, Customer, Executive Viewer.
2. Define what each persona must do in plain verbs: read, comment, upload, edit, release, delete, invite.
3. Map to roles and folders. Because a folder role can only be equal to or higher than the member's project role, give a persona no project role where they should see only part of the project, then grant per folder.
4. Create one group per persona (hub admin task), add people to groups only.
5. Document the matrix in the project README so the next administrator does not have to reverse-engineer it.

A sample matrix using Fusion's role names (a blank means no role on that folder):

Remember that a Viewer cannot download or open with Fusion, only view and comment. Suppliers who need files need Reader. A person with no project role and folder-only roles still sees the names of older (pre-September-2026) folders in the project.

What permissions do not cover#

Permissions control access to files; geometry can travel through other channels. Keep these in mind:

• References. A person who opens an assembly needs access to the projects holding its external components; without it the reference cannot be loaded. (General caution: viewers of the assembly still see the components that are loaded, so check what an assembly pulls in before sharing it.)
• Exports. Anyone who can download (Reader or higher) can export STEP, F3D or IGES and copy it elsewhere, and Basic Access users can export models in Fusion. Permissions reduce risk; they are not digital rights management.
• Public links. A public link is available to anyone who holds the URL, subject to the hub's file-sharing switch and any password. See the sharing page.
• Version history. Access applies to every version, including old ones. Basic Access users can view design history. If you accidentally saved sensitive data and removed it in a later save, anyone with access can still open the earlier state through the History dialog. The documentation does not describe deleting a single version; the safe recovery is a clean copy of the design (the copy resets history) in a restricted project.

Step by step: onboard a contractor safely#

1. Confirm the contractor has an Autodesk ID and decide whether they need to edit (licence) or only review.
2. Check the hub's invitation setting (admin only, admin approval, or open). You can also type an email address in the project's Add or search members and groups box; people who are not yet in the hub are sent an invitation.
3. Ask a hub admin to create or reuse a group named "External - Contractor" (only hub admins manage groups).
4. Set the group's role to the lowest that works (Viewer is enough for reviewers who only comment; Reader if they must download; Editor only for people who truly modify).
5. Add the group to the specific project or folder only; do not use Everyone.
6. Ask the contractor to sign in and confirm they see exactly the intended folders and nothing else.
7. Add a calendar reminder to review the access when the engagement ends and remove the group membership.
8. Record the grant in your access log: who, what, why, expiry date.

Step by step: offboarding#

1. Before the user's departure, list the files they own or last edited (sort by modified by in the Data Panel or use the admin reports).
2. Reassign ownership of active work: move items, or make a new owner save the latest version as theirs.
3. Remove the person from groups and projects, or deactivate them as a hub member (a hub admin task; inactive members cannot be added to groups). Data in a hub they personally own remains theirs.
4. Check that no public links they created remain active; revoke or recreate them.
5. Confirm references still resolve for the people who consume their components.

Auditing and troubleshooting#

When access is wrong, work through the layers in order:

1. Is the user signed in with the right Autodesk ID? Many "missing project" issues are a second account or a personal email versus a work email. (General troubleshooting experience.)
2. Are they in the correct hub? Use the hub switcher.
3. Do they appear in the project member list, directly or via a group? Check both.
4. Is the folder role different? Open the folder's Members and Permissions tab and check the person's directly applied role and group roles; the highest wins.
5. Do they have the licence needed for the action? A Basic Access user can view, comment and export but cannot save changes.
6. Is the reference target accessible? An assembly may open but show missing components because one library project is not shared with the person.
7. Has the invitation been accepted? Pending invites show as not yet members.
8. Cache or sign-in state. Sign out and in, or refresh the web client. (General troubleshooting step.)

For periodic audits, screenshot or record the member lists each quarter and compare against the HR roster. The hub admin Members tab can be searched and filtered.

Fusion Manage roles (a different system)#

If your organisation uses Fusion Manage (a separately licensed product that can be used with Fusion or independently), permissions there are a separate system. An administrator creates PLM roles (for example Customers [R/W]), each attached to one workspace and made of permissions, and assigns them to groups (Admin > Groups, then Add PLM workspace access). Group members inherit the roles, and every workspace in a group must have at least one role. Standard change-management roles include Problem Reports [C], [REVIEW] and [R/W]; Change Requests [R] and [R/W]; Change Orders [R] and [R/W]; Change Tasks [R/W]; and Change Approval Templates [R] and [R/W]. Approval is not a role you add on top: approval permission on a change request or change order is granted at runtime to the coordinator and approvers selected for each one, and a [R] role holder can still perform workflow transitions if they were selected as a responsible user. That layer does not control who sees a CAD file in the Data Panel; it controls who sees and edits the managed item records, change orders and so on. Keep the two systems aligned by group naming. See the Fusion Manage page.

Options reference#

Tips and pitfalls#

Tip: Always have at least two people who can manage members (Manager or Folder Admin), and more than one hub admin, so that holiday or departure does not lock the team out.

Tip: Name groups by function, not by person or project phase: "Checkers" will still make sense in two years.

Warning: Giving everyone Editor "to be safe" is how files get deleted. Most teammates need Editor on their own subfolders and Viewer elsewhere.

Warning: Removing a person from a library project can break the references of everyone's assemblies in their view, because they lose access to the target files. Check Where used first.

Warning: Do not rely on obscurity: a file with a hard-to-guess name is still reachable by anyone with project access.

Practice exercise#

Imagine a six-person company with two engineers, one checker, one supplier contact, one owner and one customer reviewer. Create a persona-by-folder matrix like the sample above for a project with five folders. Then answer: Who needs the Folder Admin or Manager role? What is the minimum access for the supplier? Which action in the offboarding list would you perform first for the departing engineer? Expected result: a one-page matrix with groups named by function, no more than two administrators, and a supplier limited to the Reader role on a single folder.

Related#

• Hubs, Projects and Folder Architecture (this section)
• Sharing and Public Links (this section)
• Admin Console and Team Best Practices (this section)
• Fusion Manage and PDM Concepts (this section)
• Getting started: Hubs and Projects