Page tree
Skip to end of metadata
Go to start of metadata

Last updated 

Disclaimer: This procedure is based on the current EOSC-hub onboarding activities, which are regularly evolving and improving based on feedback. The procedures are also converging with other EOSC stakeholders to support and enhance the service offering on the EOSC portal. If you have questions about this process or wish to begin onboarding, please contact join@mailman.eosc-hub.eu.  

1. Introduction

Service onboarding within EOSC-hub is the process whereby a service joins the EOSC-hub service portfolio, and subsequently the list of services in the Marketplace on the EOSC Portal website. Services may also be listed on the EOSC-hub website. 

This provides services with all the benefits offered by the Portal and Marketplace - promotion of the service to users outside their local community domain, a single gateway for users to discover and use services, regardless of their nature and the scientific discipline of the user, and potential integration with other services in the catalogue.  It also allows (qualified) services to be directly ordered through the EOSC Portal, subject to sufficient maturity, and to service ordering integration. 

2. Service Portfolios

Within EOSC-hub, we deal with two portfolios:

1) the Hub Portfolio containing enabling services necessary for the operation of the EOSC-hub (e.g. helpdesk and AAI) and for integration with external services.  These services may not be directly ordered by end-users.

2) the EOSC Service Portfolio containing services which are offered to the research community. These include thematic services supporting a specific community or research areas, as well as common services which are more generic, supporting many different communities. Common services might include more technology-driven offerings such as data management platforms, visualisation platforms, cloud or container computing services, or services providing persistent identifiers among many others

The onboarding service here is intended to include services from the wider community into the EOSC Service Portfolio, and then be published on EOSC-Portal

3. Onboarding Process for new services joining the EOSC Service Portfolio

The following diagram provides an overview of the on-boarding process.

3.1 Initial contact with EOSC-hub and request for onboarding

The prospective Service Provider contacts us via email or completes the Join as a provider form on the EOSC Portal website.  The information submitted becomes an internal ticket which is used for tracking the request, and a service descriptipn template to be filled is sent to the provider. An example of the template can be found here but this file should not be filled in, as an up to date template will be sent as part of the onboarding process. 

3.2 Information gathering

The prospective provider fills the template to the best of their ability. The EOSC-hub team are on hand to provide support when needed, typically by email. Providers must fill all required sections of the template, though many sections are optional. Once all required information is provided, the service moves into validation. 

3.3 Validation

EOSC-hub staff go through the submitted information and validate it, ensuring it meets the Rules of Participation (criteria) defined by EOSC-hub, which are related to the EOC-wide Rules of Participation defined by the EOSC Working group on Rules of Participation (WG-RoP). The current state of these rules can be found at Criteria for possible inclusion in the EOSC Service Portfolio. These rules are largely provided within the template, which requires certain information from all providers. Once the data is validated, the data is entered into the EOSC Service Portfolio. 

3.4 Publication

The data from the completed service description template is added into the Marketplace on the EOSC Portal. The provider is asked to make an account on the Marketplace, and receives access to a draft entry for the service. They are able to check the entry and make or request changes. Once they are happy, they indicate this to EOSC-hub, who publish the service. 

4. Additional steps

4.1 Ordering and service options

If you wish to make your service orderable through EOSC portal (currently this requires a minimum TRL of 8) then you can configure the ordering  system on the Marketplace platform. Members of the ordering team will assist if necessary. You will also be able to list and configure the different options for your service on the Marketplace platform. 

4.2 Integration with Hub Portfolio services

The services in the Hub portfolio empower the Hub of EOSC, but are also available for integration with external services under certain conditions. Current services that may be integrated include: 

  • EOSC hub AAI
  • EOSC hub accounting
  • 
EOSC hub CMDB
 (Configuration Management Database)
  • EOSC hub helpdesk
  • EOSC hub monitoring
  • EOSC hub service portfolio management tool

More information will be provided about these services as the integration options become available. Please contact us if you are interested in using them before then. 

5. Maintenance and future developments

5.1 Maintenance of the portfolio and Marketplace

By choosing to provide your data for listing on EOSC portal, you must also agree to periodically update this information to keep it current and correct. We may also at times update the required information for the service descriptions, on the basis of community changes or new requirements from EOSC Governance and WG-RoP. We will request providers then update their information in a reasonable period of time. We will endeavour to give providers as much time as possible for such changes, and minimise the frequency that updates are requested. Typically, updates would be annual. 

5.2 Future of EOSC portal

The EOSC portal is a collaboration between EOSC-hub and other groups in the EOSC ecosystem. It is under active development, and it is possible that the nature in which the data is presented may change in the future. This may also drive some changes to the data requested mentioned in the previous section. Out goal in the evolution of the portal will be to maximise expose of services, and require the minimum changes and disruption for providers. 


  • No labels