Skip to content

good practice and innovation
about us infoKits Tools & Techniques Publications Events
You are here: Home » infoKits » Repositories infoKit » Technical Framework » Submission Workflows

Find, share and discuss learning and teaching materials via Jorum, a JISC-funded service.



The Repositories Support Project (RSP) is a major JISC initiative to support the development and growth of the UK repositories network.


Feedback?


Submission Workflows

Submission (or 'deposit') workflows define the steps involved in adding content to the repository; gathering the necessary metadata, permissions and files associated with the content; and doing all the necessary checks on these elements before making the item available to the wider world.

There are several benefits to creating good submission workflows within the repository, namely they:

  • Streamline the deposit process - Comprehensive submission workflows minimise effort and simultaneously ensure capture of all required information without duplication of effort or heroic measures
  • Encourage user deposits - User-friendly submission workflows can encourage academics to deposit more items
  • Integrate quality assurance - Building checking stages into workflows allows items or metadata to be double-checked for accuracy and consistency early in the life of the item
  • Add value - Workflows can add value to a collection or process for example, by adding subject classification to an object, or by triggering other actions such as submission to publishers or other repositories
  • Facilitate administration - Once content starts flowing into the repository sound workflows enable the repository administrator to manage new deposits, track objects through each stage, and address any problems that may arise

Typical tasks within a submission workflow can include:

  • Acknowledging newly-submitted items (if this is not done automatically by your software)

  • Checking the eligibility of depositors and/or the types of item being deposited

  • Verifying, and if necessary querying copyright permissions. For instance, there may be a need to check which version of the item is being deposited i.e. preprint; author's peer-reviewed version; published version

  • Validating metadata

  • Approving the submissions i.e. making them publicly visible

  • Releasing embargoed full-texts when the relevant period has expired - if your software does not do this automatically

Planning a submission workflow

A simple submission workflow has three basic elements: metadata; permissions; and file management. The following questions must be addressed to define an effective and comprehensive workflow:

Metadata input

  • What metadata is going to be gathered from the authors?
  • What metadata (if any) will be generated automatically?
  • What metadata (if any) are administrators or other repository staff going to add to each record?
  • What are the options for minimising free text fields?

Permissions/copyright and licence handling

  • Who is responsible for checking the copyright of each submission?
  • At what stage in the process is this check completed and how are the decisions recorded in the metadata?
  • When will the depositor sign a deposit agreement or license?
  • How will embargoes be dealt with?

File management

  • What files will be requested from authors?

  • What formats will be requested?

  • How will associated files be identified and stored in the repository?

  • How will different versions of deposits be managed?

Spend some time thinking about and discussing submission workflows at an early stage in repository development, at the same time as considering repository policies. Workflows will impact on the configuration and customisation of your repository software in terms of the permissions set on certain stages of the submission workflow process, and included elements within item submission forms. Once draft workflows are in place it is recommended to test them with a group of your users and to remain flexible to allow your workflows to adapt over time. Several different workflows may be required for different categories of materials - for example if your institutional repository has research materials and learning and teaching materials, or if some materials are open and some closed access.


Bookmark and Share
If you can read this text, it means you are not experiencing the Plone design at its best. Plone makes heavy use of CSS, which means it is accessible to any internet browser, but the design needs a standards-compliant browser to look like we intended it. Just so you know ;)