Managing Content Structure & Access

Created: November 23, 2017 | Updated: October 01, 2025

Content structure and access management for a Workspace can be performed from both the Admin – Explorer page (by an Administrator) or the main Projects page (by a Workspace member with sufficient rights). The commands and features on these pages allow you to:

Browse the folders and Items within the Workspace. You are able to create, edit and remove folders and so build the structure of the Workspace. Removed folders and items are sent to the Trash where they can be permanently deleted or restored.
Define folder-level and Item-level sharing. This controls who is able to see what content is in the Workspace and, at the folder level, whether other users can simply view a folder and its content, or also edit it (effectively releasing/committing/uploading design data into it).
Specify if a folder or item (such as project) inherits its share permissions from its parent folder. This is the default condition.

In terms of content structure and management, the Projects and Explorer page interfaces differ in terms of capabilities and convenience:

The Workspace Projects page delivers a simple approach to folder and project item management, which is available to Administrators, project/item Owners and other users with sufficient editing rights.
Note: With this interface you cannot edit or set share permissions for the top-level Projects folder (by default), or create another top-level folder.

The majority of Workspace structure and permission management tasks can be performed from the Projects page commands.
The Workspace Explorer page, which is similar to the Altium Designer Explorer panel and available to Administrators only, provides management access to all folders and items, including project Release data, Components, Managed Content, etc.
Note: With this interface you cannot share a design project or move folders and items.

The Explorer page provides detailed control over the Workspace structure and permission settings, including access to the top-level Projects folder.

Sharing Folders and Items

The Altium 365 Workspace folder structure features an advanced permission inheritance scheme based on the propagation of sharing permissions from Parent to Child objects – the latter being a folder or design items such as Projects, Components, BOM files, Templates, and so on. This arrangement simplifies the process of organizing a Workspace folder structure and its sharing permissions to match the access requirements of Company Users and Groups of users.

A Workspace provides the following sharing capabilities:

Folder-level Sharing – providing the ability to control who is able to see what content in the Workspace by sharing folders. This allows control over whether other users can simply view a folder and its content, or also edit it (effectively releasing/committing/uploading design data into it). A single Workspace can be partitioned into various effective 'zones' of content but with controlled folder-level permissions, which allows the content to be made selectively visible or hidden as required, giving the right people, the right access, to the right data.
Item-level Sharing – providing the ability to control who can see and access which Items in a shared folder. This more specific level of sharing allows you to overrule (or add to) the permission set an Item has inherited from its parent folder. Provided a user has access to the folder itself, they will then be able to view/edit (as permitted) Items within that folder that are shared with them.

When specifying the sharing permissions for an item object (such as a Component, Template, etc) using the Workspace Explorer interface, the item's share settings will also apply to its constituent Revisions. You can add/remove permissions from individual Revisions within that hierarchy, but the permission change will not propagate down the hierarchy itself – it is not inherited by the Revisions below it in the hierarchy.

Internally, access to Workspace objects is determined by a hierarchical Access Control List (ACL) that determines the permissions associated with Folders, Projects and Items. The list specifies who has access to that object and if it can be modified. For example, if a particular project’s Share settings includes View (read-only) permissions for Librarians then it is accessible to members of the Librarians group, but cannot be Edited, Moved or Removed (or re-shared) by those members – unless they are an Administrator or the project Owner.

The above sharing capabilities will adhere to the Workspace permission inheritance scheme. In the simplest sense, permissions applied to a folder will propagate down the folder hierarchy through the parent-child relationships – from folder to sub-folder, down the chain.

This permission inheritance structure is maintained (unless intentionally disabled at some point in the hierarchy) when folders are added to the hierarchy, and also when permissions are added within the hierarchy. Where additional permissions are applied to a folder that is not the top-level folder – it is within the hierarchy – they will be inherited down the hierarchy from this level, without affecting the existing permissions.

Add Edit rights (Read/Write) for the Engineers user Group to the top folder in the A-B-C folder hierarchy.

The new permission entry (Engineers Read/Write) is automatically applied to all folders in the hierarchy through parent-child permission inheritance.

Add Read-only rights (Read) for the Librarians user Group to Folder B hierarchy – its permission set will be 'extended’ by this addition

The new permission entry (Librarians Read) is applied to the B folder and inherited by all folders below it in the hierarchy.

A design Project (or other item type) is created or uploaded into Folder C. It will inherit the share permissions from Folder C.

Extend the permission set of Folder C by adding read-only rights (Read) for the Managers Group.

The added Managers Read permission is inherited by the design Project. Note that share permissions for Design and Managed BOM Projects are managed through the Share window dialog in the Workspace Projects page.

Those with administrator-level privileges (members of the Administrators group) will be able to see and manage all folders and Items. A non-administrative Workspace user can access only those folders and Items they have created (are the 'owner' of), or those that have been shared with them via suitable permissions.

In the Workspace Projects page, project folder permissions can be accessed and changed from the interface’s Share options. Select a folder entry and then the upper button or the Share option from the entry’s menu to access the Share Item window. Note that:

by default – when a Workspace is first activated – the top-level Projects folder is not accessible in the Projects page but will become available if other top-level folders are created. The Explorer page interface can always access the Projects folder.
the window’s interface and functionality operate in the same manner when sharing a Project – this includes the ability to change the Item (folder) Owner.

Share permissions configured for the Team 1 project folder – full access for the US Engineering team and ECAD Managers can view only. Projects within this folder inherit these permissions, adding to the inherent administrator and owner write permissions.

Share permissions for a project folder that has been added by a user, which will inherit its permissions from the parent folder (Team 1). The parent folder was created by a different user (Harold Smith) who ‘owns’ that folder, so write access to the new folder is granted for this user also.

Share permissions configured for the Team 2 project folder – full access for the EU Engineering team and ECAD Managers can view only. Projects within this folder inherit these permissions, adding to the inherent administrator and owner write permissions.

In the Explorer page, sharing controls are accessed by right-clicking over the navigation tree entry for the folder (or Item) and using the Share Folder (or Share Item) command from the context menu. The Share window will appear, from where access permissions for the folder/Item can be modified as required.

Share permissions for a template item, as inherited from the parent Component Templates folder.

Things to be aware of:

In terms of permissions, a user/group has Read/Write access when the Can Write (Edit) option is enabled. If this option is disabled, they have Read (View) access only.

Enabling Edit access to a Folder/Item for a User/Group is effectively adding another permission to its permission set (ACL), and changing that access back to View is effectively removing a permission from the set.
In terms of user interface sharing permission selections:
- A checked Can Write option (read/write) in the Explorer page is equivalent to Can Edit being selected in the Projects page.
- An unchecked Can Write option (read-only) in the Explorer page is equivalent to Can View being selected in the Projects page.
To remove an existing user/group from having shared access to a folder/item:
- on the Projects page, select the user/group tile's Remove option in the Share Item window.
- on the Explorer page, click the user/group entry's associated Remove control () in the Share window.
By default, a folder/item will only be available to its owner (initially its creator) and all members of the Administrators group. These permissions are inherent and do not need to be explicitly added. Owners and Administrators have Read/Write (View/Edit) permissions.
To allow all users of the Workspace to see a folder/item:
- in the Projects page Share Item window, set the Workspace Members tile access option to Can View, or Can Edit for full write access.
- in the Explorer page Share window, select the Add Anyone control and uncheck its Can Write option, or leave it checked for full write access.
  
  Be aware that doing the above will potentially grant Read/Write access to all Workspace members. If you want to lock access down to a specific set of users and/or groups, you must set Workspace Members for No access (Projects page) or remove the Anyone entity (Explorer page).
Unlike other items, a design project item's sharing permissions cannot be managed through the Explorer page. They are instead specified in the Share Item window accessed from the Projects page. See the Workspace Projects page for detailed information.

Inheritance-controlled Sharing Restrictions

Some levels of user access, such as Can View or No access in a folder's Share Item window, may be unavailable for selection because they would contradict (demote) the permission set inherited from its parent folder. By default, the folder share permissions are full write access for all users – Workspace Members Can Edit as shown in the Share Item window, or Anyone can Write as shown in the Explorer page Share window.

In this default case for example, the options to demote a folder’s inherited permissions (from Workspace Members Edit to Workspace Members View or No Access) are disabled to prevent an inadvertent disconnection in the permissions hierarchy structure. Note that you can always promote (increase) the level of sharing access since this simply 'adds' to the existing permission set inherited from the parent folder.

To intentionally disconnect the Parent to Child permission inheritance for this folder, so a different (reduced) level of access can be applied, uncheck the Inherit parent folder permissions option in the Share Item window’s Advanced Settings. With the folder no longer inheriting permissions from its parent, its own access permissions can be changed without restriction. See the section below for more information.

The Inherit permissions from parent folder option is initially enabled by default, and is always enabled for newly created folders.

Similarly, when changing folder share permissions through the Workspace Explorer page you are prevented from demoting permissions inherited from the parent folder. Uncheck the Share window's Inherit permissions from parent option to intentionally disconnect permissions inheritance from its parent folder (Projects in this case).

Along with folders and Projects, the permission inheritance system also applies to Items (such as Components) and their constituent Revisions. These exhibit the same permission inheritance behavior, and include the option to enable/disable that inheritance (under Advanced Settings in the Explorer page Share dialog).

Permission Inheritance Continuity

The share permissions inheritance continuity through the Workspace folder hierarchy, as outlined above, is maintained unless a folder’s permission inheritance from its Parent folder is explicitly disconnected (disabled) at some point. The Parent to Child propagation of permissions for a folder (or project/Item) is disabled by unchecking its Inherit permissions from parent option, as available in the Share Item dialog. While that folder will no longer inherit any permissions changes made to its parent, and the permissions hierarchy is effectively disconnected (disabled) at this point, the inheritance remains contiguous below this level.

The full depth of folder permissions inheritance will be restored if that 'disconnected' folder's Inherit permissions from parent option is enabled again. It then will re-inherit the parent’s permissions (if not already present) to restore the parent-child permissions integrity.

An example of a folder hierarchy (A-D) with contiguous permissions inheritance. The Engineers Write permission has been added at the top Folder A level (or above) and this has propagated down the hierarchy to Folder D.

Disabling the parent-child permissions inheritance at Folder C by unchecking the Inherit permissions from parent option in the folder’s Share dialog.

The permissions inheritance continuity is disconnected between Folders B and C, but retained in the hierarchy sections above and below this point.

Adding Managers Write as a new access permission to Folder A.

The added permission is inherited by Folder B. That is, it propagates down the contiguous permissions inheritance section of the hierarchy only (A-B), but not to folder C because the B-C (parent-child) inheritance is disabled.

Adding Librarians Read permission to Folder C. Also, the existing Folder C permissions could be demoted or removed since they are no longer bound those of the parent Folder B.

The added permission is inherited by Folder D. That is, it propagates down the contiguous inheritance section of the hierarchy (C-D).

Re-enabling the parent-child permissions inheritance at Folder C by checking the Inherit permissions from parent option in the folder’s Share dialog.

Permissions inheritance is again contiguous through the folder hierarchy because the Folder B to C (parent→child) inheritance is enabled. Folder C (and below) inherits the Manager Write permission from Folder B to maintain the full parent-child inheritance relationship.

In compliance with the enabled permission inheritance scheme, a folder/item's permissions can be promoted and added to (effectively the same action) but not demoted from those of its parent. This also applies if an added permission for a Group/User will be common to both the Parent and Child entities:

When adding a permission to a folder it will effectively overwrite the same permission in a child folder if it is at a lower access level. For example, if the Librarians Read/Write permission is added to a folder and its child folder has an existing Librarians Read entry, this will be promoted to a Librarians Read/Write entry.
In essence, Write-level access has been added to the parent folder, and this is inherited by the child folder. Permission inheritance is maintained.
Conversely, when adding a permission to a folder it will not affect the same permission in a child folder if it has a higher access level. For example, if the Librarians Read permission is added to a folder and its child folder has an existing Librarians Read/Write entry, this will not be changed (demoted) to a Read level entry – it remains at its existing permission level.
In essence, Read-level access has been added to the parent, and this already exists in the child folder. Permission inheritance is maintained.

When a permission entry is removed from a folder, this change will propagate down the hierarchy (where permissions inheritance is enabled) regardless of its applied access level (Read or Write). For example, if a folder has Librarians Read access permissions but its child folder permissions have been elevated toLibrarians Write, then removing the parent’s Librarians entry will also remove the child’s Librarians entry.

The folder permissions inheritance logic described here also applies to project Items (Design and Managed BOM projects). A project is always a child of a parent folder and will inherit its permissions, and the permission inheritance can be disabled in the same way as for a child folder.
Project permissions are edited through the Share Item window in the Workspace Projects page.

Moving Folders

Workspace folders can be moved to any other location in the folder structure through the Projects page (see Workspace Projects page) or the Explorer pane in Altium Designer (see Organizing Your Workspace).

The way in which a moved folder’s share permissions are determined depends on the inheritance relationship to its existing parent folder:

When a folder’s Inherit parent folder permissions option is enabled (the default condition), the action of moving that folder into another folder will cause it to:
- inherit the permission set from its new parent folder (including that folder's Owner).
- lose its original inherited permissions.
  - * A folder/project’s 'inherited' permissions are those adopted from its parent – they have been inherited.
- retain its previous extended permissions.
  - * A folder/project’s 'extended' permissions are those that have been specifically added to extend user access – they have not been inherited from its parent.
In short, the old parent’s permissions are replaced by the new parent’s permissions, but any that were added will move with the folder.

When a folder’s Inherit parent folder permissions option is disabled (it does not adopt its parent’s permissions), the action of moving that folder into another folder will cause it to:
- retain its original permissions.
- retain the disabled state of its Inherit parent folder permissions setting.
In short, it is literally a move event with no other changes. This could be regarded as the safest way to move a folder and its contents, since it avoids the possibility of unexpected changes in permissions due to inheritance from its new parent folder.

In this example, folders A-B-C are in a hierarchy that includes inherited Engineers Write permissions. Folder C permissions have been extended by the addition of Contractors Read. Alternatively, an individual User could have been added.

Moving folder with Permission Inheritance enabled. Folder C will be moved into Folder D, which features a different permission set. Note that permissions Inheritance is enabled for all folders (the default condition).

The moved Folder C is now a child of Folder D and will inherit its parent's Mechanical Read permission. Folder C also will lose its original inherited permissions (Engineers Read/Write) but retain its extended (added) permissions (Contractors Read).

Moving a folder with Permission Inheritance disabled. The Share window’s Inherit permission from parent option has been disabled (unchecked) for folder C. Also, an additional Managers Read permission has been added.

Folder C will be moved into Folder E, which features a different permission set. Note that permissions Inheritance is disabled for Folder C, which is ‘detached’ from its parent (Folder D) in permissions inheritance terms.

The moved Folder C will retain both its original permission set and its Inherit permission setting (disabled). It is moved into Folder E without permission alterations, and will not inherit any permissions changes made to its parent, Folder E.

Before moving a folder or project into another folder, it is highly recommended that you first check the target folder permissions because by default (Inherit parent folder permissions enabled) these will be inherited by the moved folder/project. For example, the target folder permissions could have a higher level of sharing than desired, such as editing rights or access for all users, which will then apply to the relocated folder/project

Note that the folder permissions inheritance logic described here also applies to moving projects (Design and Managed BOM projects). A project is always a child of a parent folder, and its permission inheritance state is enabled/disabled by the Inherit parent folder permissions option in the same way as a child folder.

Managing Project Creation Permissions

With the default Workspace settings, projects created or uploaded by Workspace members are stored in the Projects folder, available with write access to all users (as inherited from the parent Projects folder), and are directly accessed through the Projects page. This simple arrangement is convenient for users, but allows any member of the Workspace to create accessible projects in this primary (top-level) location. To implement more advanced control over who can create (and access) projects in the Projects folder, or additional sub-folders, Workspace administrators can define the project folder sharing permissions through the Explorer page, or in Altium Designer, the Explorer panel.

As outlined above, folder permissions are accessed in the Workspace Explorer page from the Share Folder option of a folder entry’s right-click context menu. For example, the Projects folder access can be changed by setting the default permission (Anyone) to read-only (deselecting Can Write) or by removing it entirely, and then adding access permissions for specific users (Add User) or groups of users (Add Role) as required.

The updated write permissions will determine which Workspace members can create (or upload) projects to the Projects folder – in the example shown above, only those who are members of the Managers group. The permission constraints will also apply to users creating a new project in Altium Designer.

For a structured folder hierarchy where permissions and user/group access are configured accordingly, such as progressively opened down the folder tree, this approach can provide suitable levels of permissions access for users and groups based on the target folder.

Default Project Creation Permissions

As an alternative to the default arrangement where a newly added project will inherit the permission set of its parent folder, you can specify a fixed set of permissions for all new projects by enabling the Default Permissions for new projects option in the Projects view of the Admin – Settings page. This arrangement may better suit a less structured folder permissions hierarchy where all user projects are created in a specific location, such as the Projects folder.

This option is available when you have a higher level of Altium Solution access.

When enabled, a newly created project will adopt the permissions specified by this option rather than inheriting its parent folder permissions. The option’s initial settings match the Workplace's default settings – write access for all users – and can be changed to suit your needs. An example of this might be Write (edit) access for Engineers and View (read-only) access for Librarians.

To specify a fixed set of access permissions for newly created (or uploaded) projects enable the Default permissions for new projects option in the Admin - Settings page, which is initially set to the default condition of Write access for all Workspace members.

Select the desired permission sets for newly created projects – in this example, only Engineers Write and Librarians Read. Note that Administrators and the project Owner (creator) always have full write access.

When a user creates/uploads a new project, the specified default permissions are applied rather than those adopted from the project’s parent folder (Projects), as shown in the project’s Share dialog.

The window’s Inherit parent folder permissions option is automatically disabled for a new project when the Default permission for new projects option (in Admin - Settings) has been enabled.

Points of note:

Administrators always have write access to all projects (and folders), so this setting cannot be changed (it is Read-only).
The Project Owner (the user who created a project) has full access to a project, and by inference its parent folder because folder write permissions are required to create a new project.
The application of a fixed project permission set (as outlined above) is unlikely to include the permissions of the parent folder, so the project parent-child (folder-project) permissions inheritance is disabled automatically – slide #4, above. If it is manually re-applied to the project, then the parent folder’s permission set will be added to the project – see Permission Inheritance Continuity above for information.
The described permission adoption behavior for new projects also will apply when cloning a project.

Project Creation Without Folder Write Access

When a user without write access to the Projects folder (or some other folder that has been specified as the default storage location) performs a project Create or Upload, the system will automatically create a user-specific Personal Folder structure for storing the new project. This appears as a top-level folder based on the member’s email address, with a My Projects sub-folder that stores that user’s projects. The folder structure/hierarchy is owned by and available to the signed-in user only (and administrators), and is not visible to other users.

If the user performs a project Create or Upload within a folder they have write access to, then the project is stored in that folder.
If the user performs a project Create or Upload within a folder they have read-only (View) access to and is not the default storage location, then the process is blocked () and the top-level My Projects folder structure is created for that user if it does not already exist.
For the Projects folder permissions example shown above, projects created by users who are members of the Managers group will be included in the Projects folder as normal because they have full Edit rights to that folder. Other users have read-only (View) access to the Projects folder, so their new projects are stored in their My Projects folder.
if a project residing in a Workspace member’s My Projects folder is shared with others users (via Workspace Members, Groups, or specific usernames), then it will appear in the top-level view of the Projects page for those users.

From a Workspace administrator’s perspective, the member’s personal folders are collected under a top-level Home folder, as evident in the Projects page and the Explorer page folder hierarchy – and also the Altium Designer Explorer pane folder tree.

Downloading an Item Revision

For Workspace members, Project content (source files, generated files, released data, etc) can be downloaded through the project’s Design and Releases views. In the Explorer page you can directly download data from the interface by clicking the Download control () to the right of the entry for an Item Revision.

Using the control at the parent Item level will download data for the latest revision of that Item.

Navigating the Workspace Structure

While project-orientated navigation of Workspace content is available to all Workspace members through the Projects and Components pages, Workspace administrators can navigate and access all content through the Explorer page interface, as outlined below.

The ways in which to navigate Workspace content through the browser interface.

The results of an example search.

Administrators can navigate to Workspace content:

By clicking on a folder name whose contents you wish to peruse.
By using the search feature. Enter a keyword based on an Item's ID, Comment or Description, and then press Enter or click the magnifying glass icon (). The entire Workspace will be scanned and results of the search listed, in terms of matching Items.

After a search, you can return to the normal view of the Workspace content by clicking the Admin – Explorer page entry again, in the browser interface's navigation tree on the far left. Alternatively, clear the search field and press Enter.

Additional Features

The following additional features can be found when browsing content through the Workspace's browser interface:

Navigate – this command, found on the right-click context menu for an Item, is used to quickly take you to that Item in Altium Designer's Explorer panel. Altium Designer will be opened in order to do this (you'll be prompted if you want to open X2.exe – Altium Designer's source executable).

If Altium Designer is already running, that instance will be used.
Full item info – this command, found on the right-click context menu for an Item Revision, is used to present a view listing all detail for that Revision. In effect, it is simply a view that includes all of the various aspect views available for that Item Revision (except Summary).

Using the command at the parent Item level will present details for the latest revision of that Item.
Follow/UnFollow – use the Follow command, found on the right-click context menu for a folder of Type Components, to follow the folder. Any activity within the folder being followed (component creation, release, revision state change, or deletion) will be flagged through an email notification sent out from the Workspace (provided email notifications have been enabled for the Workspace by an Administrator). Use the UnFollow command to stop following component activity within that folder.
Remove Folder – use this command, found on the right-click menu for a folder, to move that folder and all its content (sub-folders and Items therein) to the isolated Trash area for the Workspace. Entities in the Trash can then be permanently deleted, or restored, as required. If removing a project folder, any associated releases and manufacturing packages will also be moved to the Trash.
Remove Item – use this command, found on the right-click menu for an Item, to move that Item to the isolated Trash area for the Workspace. Entities in the Trash can then be permanently deleted, or restored, as required. If removing a Component Item, you also have the opportunity to move its associated models to the Trash at the same time. Note that these can only be deleted if they are not being used elsewhere (by one or more other components).

Printer-friendly version

If you find an issue, select the text/image and pressCtrl + Enterto send us your feedback.