Groups play a vital role within Figshare, impacting various aspects of the system, including user management, data presentation, storage quota management, custom metadata management, and more. While it is important to carefully consider several other factors when setting up (or modifying your organisation’s Group structure), the group structure that you implement must fit within the solution you have purchased, so your implementation project manager will guide you through the decision making process and Figshare's implementation team will configure the initial group structure for you as a part of your implementation project.
Groups in Figshare are organised hierarchically. Each Group has exactly one parent and may have any number of subgroups beneath it, with a maximum depth of ten levels. The top-level organisational Group represents the root of the hierarchy, and all other Groups in the system will exist as subgroups below this top-level Group. Certain configuration options differ for these subgroups.
It is recommended that you regularly review your Group structure and configurations to ensure they meet the evolving needs of your organisation. Maintaining clear documentation and providing training for System Administrators around the use of Groups will help ensure consistency and effective management of Groups, ensuring efficient and secure data management across your organisation.
This document will outline how to manage Groups within Figshare, as well as the key areas that should be considered when configuring Groups. If you have any questions or would like further guidance, please raise a support ticket and we will be happy to help.
Viewing Group structure and summary information
To access your portal’s Group structure, navigate to the Administration area. The first tab is the ‘Groups’ tab. This tab provides an overview of Group structure, provides summary information for Groups, and can be used to manage Groups.
The Groups table displays the Group hierarchy and a number of different Group properties:
Name - The display name of the Group, as set on the Group ‘Configuration’ page.
Users - Displays the total number of users assigned to that Group. Clicking on the count will display a popover which shows how the count is made up of ‘direct’ members of the Group and ‘indirect’ members (i.e. inherited users, that are direct members of a subgroup). More information about user creation and management can be found here.
Projects - Displays the count of ‘Group projects’ associated directly to that Group. More information about the difference between ‘Group projects’ and ‘Individual projects’ can be found here.
Storage - Displays the allocated quota and total quota in the ‘Group projects’ space for the Group. More information about managing storage in Figshare can be found here.
Actions - The actions menu provides options to create a subgroup, to configure a Group, and to delete a group (where applicable).
It is possible to search Groups by name and sort the table by each of these properties. When sorted or searched the hierarchical Group structure is not displayed.
Creating and configuring Groups
To configure Groups, click the ‘Actions’ menu and select ‘Configure group’ to access the configuration page. It is also possible to select ‘Create subgroup’ to create a new Group below the selected Group in the hierarchy. Any Administrator, Group Admin or Group Owner can create Groups.
The properties that can be configured through this section are:
Group settings
Group title - Sets the name that will appear within your portal to identify the Group. This field can contain special characters. The name set at Group creation will be used for the default Group URL. The name can be updated at a later date but the URL will not automatically update.
Group description - A text field with a limit of 1,000 characters that will be displayed as a pop up on the portal Group page. Note: It is possible to include a ‘mailto’ link in the description by adding this as a tag -e.g. <a href= "mailto: repository@lilliput.ac.uk"> repository@lilliput.ac.uk</a>
Public URL - The URL for any Group that has been made public. This is prepopulated with the institution URL followed by the title of the Group. For further details see the ‘Options for configuring Group URLs’ section below.
Make group public - Determines whether a Group is displayed publicly in your Figshare for Institutions portal. The Group will become public and will have a portal page only if this flag is set and there is public content to be displayed.
Embargo section - Determines if the Group should be displayed as an option when configuring restricted access for items. More information about embargoes and restricted access can be found here.
Review process - Determines if content uploaded to the Group should be subject to a review process. If a review setting has been implemented at an institutional level, then the toggle will automatically be set to ON and cannot be changed.
Storage
Initial quota per user - This sets an initial storage quota for users of this Group and will overwrite the value set at the institutional level, on the ‘Storage’ tab.
Total quota for group projects - Sets the total quota for Group projects for all Group projects in the Group and any subgroups.
Initial quota per group project - Sets a default minimum initial storage quota for any new Group project created within the Group. This storage will be used for items uploaded as part of a Group project only. More information about Group projects can be found here.
More information about managing storage can be found in this support article.
Roles
In this section you can assign Group roles to users. All Groups must include a Group owner. A Group can only have one owner at a time. If an owner is removed, then another owner must be added. The Group roles that can be assigned to users are:
Owner
Admin
Data Steward (available if the ‘Data Steward’ role has been enabled via a support request)
Reviewer
Fellow (available if the ‘Fellow’ role has been enabled via a support request)
More information about roles can be found in this support article.
HR feed association
If your repository is set up to create accounts through an HR feed, you will see that information here, otherwise you can ignore this section. The HR feed association section displays the HR feed association for this Group. This is replicated from the HR feed tab. Any changes made here are reflected in the HR feed tab and vice versa. More information about HR feed association can be found in this support article.
Custom metadata fields
Custom metadata fields can be used to expand the stock set of metadata fields available in Figshare for Institutions and are configured at the Group level. All items, collections and projects that belong to this Group will include these custom metadata fields.
Inherited metadata fields - These are the set of custom metadata fields that are set globally on the ‘Metadata’ tab. These custom metadata fields are inherited by all Groups in the hierarchy and cannot be edited at the Group level.
Group-based metadata fields - These are specific Group-based metadata fields that will only apply to items, collections and projects that belong to this Group. These fields do not cascade to subgroups.
More information about configuring custom metadata fields can be found in this support article.
Options for configuring Group URLs
The URL can be modified on the Group configuration page if a group has not been made public. If you would like to modify the URL for a Group that has been made public, please submit a support ticket. Currently figshare can only support URLs in the following format:
Top level: http://InstitutionName.figshare.com
Groups: http://InstitutionName.figshare.com/GroupName
All group URLs, (whatever their level in your hierarchy), will need to follow the ‘/’ after figshare.com as above. If you would like to include the parent group that a subgroup belongs to you could use a variation of the following example with hyphens (-):
Groups example 2: http://InstitutionName.figshare.com/ParentGroupName-GroupName
Deleting Groups
Groups can be deleted through clicking on the action menu and selecting ‘Delete group’. Please note Groups can only be deleted in situations where a Group has not been made public, does not contain published items that are public and does not have any associated subgroups. In the situation that a Group cannot be deleted the ‘Delete group’ option will be inactive.
Deleting a Group will remove all associated members, content and settings from the Group and cannot be undone. Users and private content in a Group that has been deleted will be moved to the institutional level.
Considerations when determining your Group structure
As outlined above, Groups play a vital role within Figshare, impacting various aspects of the system. It is important to carefully consider several factors when setting up or modifying your organisation’s group structure.
You can choose to have public Figshare portal pages for any number of Groups within your organisation. For example, rather than having just a public portal for all content from the ‘College of Engineering’, you could have portals for each subgroup within e.g. ‘Chemical Engineering’, ‘Mechanical Engineering’ and ‘Biomedical Engineering’ etc.
When creating this structure you should consider:
The ‘lowest level’ public portal you would like to: display content publicly from, allocate project quota to, view reports/statistics on, and set custom metadata fields.
You can create up to ten levels of the hierarchy below the top-level Group, but note lower level subgroups can only be associated to one parent Group above.
Whether you are able to correctly map a user to a particular group (either at account creation, or by specifying the ‘UserAssociationCriteria’ field in your HR feed).
If you need any help or support regarding the configuration of your Group structure, please raise a support ticket and we will be happy to help.
Examples of Group configurations
Salford:
https://salford.figshare.com/Acoustics
Grant page: http://gow.epsrc.ac.uk/NGBOViewGrant.aspx?GrantRef=EP/L000539/1
In this case, Salford chose to create a single institutional admin account, who manually created the Groups through the Figshare user interface, and who also uploads all data. This means they do not have Groups set up to auto-associate users to but have a public portal for their EPSRC funded S3A project.
Stockholm:
https://su.figshare.com/
Tarfala research centre: https://su.figshare.com/TRS
Stockholm also does not have Groups set up to auto-associate users. Stockholm also used an admin account to manually set up Groups via the user interface. However, as they wanted end users to be able to publish items too, they created projects within the Group that they then invited end user accounts to. This means that any items publicly published through those projects would also appear in the Group portal.
In addition, the main institutional Admin at Stockholm created additional Groups and made a regular end user the Group admin. As the Group Admin, this end user has access to our 'Group selector' tool. This tool allows Admins (only) to deposit within any Group they are admin of - despite not being associated to the group via user feed.
Monash:
https://monash.figshare.com/
MAMU: https://monash.figshare.com/mamu
MAMU is a nice example of non-scientific research output (an old music archive) being showcased through a public portal.
