The Review Workflow feature is designed to give institutions full control over their publishing workflows, ensuring that the content released on your Portal is vetted for quality, accuracy, and compliance. Through the Review Workflow, reviewers can refine Item metadata prior to publication, and authors can receive constructive feedback and suggestions, enabling them to refine their submissions and present the best possible version of their outputs.

This article provides instructions for System Administrators on enabling, configuring, and using the Review Workflow effectively.

Summary of the Review Workflow

The Review Workflow allows Reviewers to oversee the submission process, ensuring content is thoroughly checked and refined before publication on your Figshare Portal. Communication is a core element of the workflow, with Reviewers able to leave comments to provide guidance to authors. Based on their assessments, Reviewers can either approve or decline submissions, ensuring that only high-quality content is made public.

When enabled, the Review Workflow provides a set of features that allows Reviewers to: 

  • Vet submissions for accuracy and compliance with institutional requirements.
  • Improve metadata quality by editing metadata directly on the review page. 
  • Communicate with authors and other Reviewers by adding comments to review requests.
  • ‘Approve’ or ‘Decline’ review requests based on your institutional criteria.

When an Item is submitted for a review a ‘review request’ is created. 

All review requests will have a one of four statuses: 

  • Under review - Items that are currently being reviewed are marked as Under review. 
  • Declined - If the submission is declined, the review request status changes to Declined, and the author must resubmit the item to create a new review request. 
  • Approved - If approved, the review request is marked as Approved, and the item is published or updated on the portal. 
  • Archived - If an item is deleted or moved to another Group, the status of its review request changes to Archived. For items moved to a new Group, a new review request is automatically generated.

A single Item can be associated with multiple review requests. This collection of review requests and any associated comments provide an audit trail that documents every review and action taken. Published Items will always have at least one associated review request marked as Approved.

Enabling the Review Workflow 

The Review Workflow can be configured at the Portal and Group levels. This can be enabled at the portal level through the Global settings tab on the Administration area (Menu > Administration > Global settings > Review process). If the Review Workflow is enabled at the Portal level, any Item published to any Group in the repository will have to go through review before publication. If not enabled at the Portal level, the Review Workflow can be enabled for specific Groups. In this case, only Items submitted to these Groups or their child Groups will require review. The Review Workflow can be turned on through the Group configuration section located at (Menu > Administrations > Groups > Configure group > review process).

It is important to note that once enabled, the Review Workflow cannot be disabled without raising a support ticket. This measure ensures the integrity of repository data and prevents interruptions to user workflows.

Review Workflow roles

The Review Workflow is supported by three key roles, each tailored to specific responsibilities within the review process.

Institutional Reviewer

The Institutional Reviewer role is assigned to users responsible for overseeing the review processes within an institution. Users with this role have comprehensive permissions, allowing them to manage, assign, and approve requests across all Groups:

  • Approve and manage review requests for all Groups within the institution.
  • Assign and un-assign review requests to any Reviewers with permission over the Group the Item is in (including themselves). 
  • Edit metadata for any Item submitted for review, ensuring consistency and compliance with institutional standards.
  • Add comments and send direct emails to submitting authors, facilitating communication and feedback on any pending requests.

To assign the Institutional Reviewer role, go to the ‘Roles’ tab in the Admin area. In the ‘Role’ dropdown, select 'Reviewer' to assign this role to a user.

Group Reviewer

Users with the Group Reviewer role can manage review requests from users belonging to the Group and subgroups below the Group for which they have this role assigned. Group Reviewers can only assign requests to themselves. They can also edit all the metadata for the Items sent to the review workflow that they have permission to view. Group Reviewers can add comments and send emails to submitting authors for any of the pending/open requests visible to them.

To assign the Group Reviewer, to the ‘Roles’ tab on the ‘Configure group’ page. In the ‘Role’ dropdown, select 'Reviewer' to assign this role to a user.

Fellow

The Fellow role is intended to support triage processes by allowing users to review and assign submissions without having the authority to approve or decline them. Users with the Fellow role are able to see all submitted review requests and can assign them to any users with relevant Reviewer permissions. They have permission to view file and metadata records associated with a review request but do not have permissions to edit Items or to be able to complete the review themselves. Fellows can post internal comments on review requests. Fellows do not receive an email notification when requests are submitted. To enable the Fellow role, contact the Figshare Support Team. 

Review requests page

The Review Requests page provides a central hub where reviewers can access all submissions they have permission to view. This can be found by accessing (Menu > Review requests). Reviewers can now toggle between list and grid views, selecting the layout that best suits your workflow and preferences. The list view is ideal for reviewing detailed information quickly, providing extensive information about each review request at a glance, while the grid view offers a streamlined, visual summary with thumbnail previews, perfect for a quick overview of review requests.

Reviewers can search the set of review requests and have a number of options to sort the result set. 

By default, the review request page is filtered to display review requests that are ‘Under review’. Reviewers can filter the set of review requests based on the following criteria: 

Assigned To

  • Unassigned - Displays all review requests that have not been assigned to any Reviewer.
  • Assigned to me - Displays review requests assigned specifically to the viewing user.
  • Assigned to… - Allows review requests to be filtered by the assigned Reviewer.

Status

  • Approved - Displays review requests that have been reviewed and approved for publication.
  • Archived - Displays review requests that have been archived due to actions such as deletion or Group changes.
  • Declined: Displays review requests that were reviewed and rejected.
  • Under review: Displays review requests that are currently undergoing the review process and have not been approved, declined, or archived.

Item Type - Displays the type of the Item associated with the review request

Depositor - Allows filtering of review requests by the depositor's name. A search field is provided for entering the name of the depositor, which will display requests created by the specified user.

Deposited In - Filter by the Groups where the Items have been deposited. 

Submission Date - Filter based on the submission date of the review requests. Note: The submission date of a review request is the date that the review request was created. The submission date associated with an Item (a configurable date field) represents the date that the Item was first submitted to the review workflow i.e. the submission date of the first review request.  

Has Files - Filter based on whether the Item has files. Items that contain a link to external files are considered to have files. 

Has Comments - Filter based on whether or not the review request has one or more Reviewer comments.

Previously Reviewed - Filter based on whether or not the Item has previously undergone review (e.g. the Item has more than one review request associated with it. 

The status of the all review request is displayed. If the review request is assigned to the viewing user, they will have the option to edit the review request. This will open the ‘review’ page. To assign a request to a Reviewer, you can click on the title of the review request to open the ‘Request details’ page.

Request details page

The Request Details page provides an overview of the Item and detailed information about the review request itself. The side panel contains two tabs: the General tab and the Comments and history tab.

General tab

Assign to… - In order for the status of a review request to be changed the review request needs to be assigned to a Reviewer who will be responsible for reviewing the Item and deciding the outcome. An Institutional Reviewer has permission to assign the review request to any Reviewer that has permission to review the Item. A Group Reviewer only has permission to assign the request to themselves. 

Once assigned, the assigned Reviewer has a number of options available to them: 

Approve - This action will open a modal summarising the Item license and repository terms and providing a text box for an optional message to the submitting author. Clicking ‘Approve and publish’ will publish the Item on your Figshare portal (or update an already published Item with any changes). 

Decline - This action will open a modal that allows the Reviewer to send a message to the submitting author. Clicking ‘Decline and return’ will set the status of the review request to ‘Declined’ and the Item will be visible in the submitting author’s account as a draft Item. The submitting author can then make required changes and re-submit the Item. 

Edit - Reviewers have permission to edit the Item’s metadata. The Edit button will open the ‘review’ page in a new tab. 

Note: Reviewers do not have permission to edit embargo settings or modify files. In order to do this you would need to be a Reviewer with the Institutional Administrator role. If you have this role you will see the ‘Edit as administrator’ button. This will provide a shortcut to the Edit Item page in ‘impersonation’ mode. If you make changes while impersonating, you will need to save and re-submit the Item from the author account and then review the Item for publication.

The ‘Cover sheet’ section is displayed if enabled for your portal. If coversheet functionality is enabled all PDF files associated with the Item are displayed and Reviewers can opt to generate a cover sheet for PDF files upon publication.

The ‘Submission details’ section provides information about this particular review request: 

  • Authors - Details of the authors associated with the submitted Item.
  • Submission date - The date that this review request was submitted. 
  • Depositor - The submitting user. 
  • Deposited in - The Group that the Item belongs to. 
  • Review count - A count of all review requests and this review requests position in that set. 
  • Project - If the Item is associated with a project the project’s name is displayed. 
  • Virus scan - Provides details of virus scan results. 
  • iThenticate Score (if enabled) - Provides details of the iThenticate results.

Comments and history tab 

Reviewers can leave comments on review requests. Comments can be optionally sent to the submitting author. Comments stay with the review request and can be viewed by other Reviewers. Comments can be used to document the changes made, or add notes that are private to Reviewers. It is also possible for comments to be optionally sent to the submitting author. 

The history section provides summary details of all review requests associated with an Item and allows comments associated with a review request to be viewed. It is also possible to navigate to any previous review request.