Skip to content

HTS Bioinf - Process for the bioinformatic helpdesk


Description of implementation and use of bioinf-helpdesk.


Responsible person: Bioinformatics operations coordinator

General terms and definitions

The terms that are key to the helpdesk process are briefly introduced in this section. In general, we use the term "user ticket" or simply "ticket" for requests coming into and tracked in the helpdesk, whereas any derived repository/project tasks are termed "issues".

Helpdesk roles

  • Helpdesk 1st line support: all individuals trained in production
  • Helpdesk 2nd line support: entire bioinformatics group in GDx and NorSeq
  • Helpdesk reviewer: main production responsible bioinformatician

Helpdesk users

All end-users of our services are eligible. In general, they can be divided in a few distinct roles:

  • Lab doctors
  • Lab engineers
  • Others

Priorities and timeframes

To agree on acceptable timeframes for resolution of user tickets, we use priorities, corresponding to priority:: labels that should be applied to every helpdesk ticket in Gitlab:

  • Urgent (priority::urgent) - drop everything and focus on the ticket until resolved
  • High (priority::high) - evaluate within half a work day, then set a tentative deadline for resolution
  • Normal (priority::normal) - evaluate within 2-3 work days (max one week), then set a tentative deadline for resolution
  • Low (priority::low) - evaluate backlog regularly; tickets should not stay in the backlog for longer than 6 months, after which the ticket should be dropped (upon agreement with the user) or escalated, i.e. elevated in priority

Types of user tickets

We organize user tickets in four different types, corresponding to type:: labels that should be applied to every user ticket in Gitlab:

  • Delivery notifications (type::delivery): standing routine notifications of project deliveries
  • Development requests (type::development): features, improvements
  • General inquiries (type::general): can be answered by email/ad-hoc meetings/docs changes
  • Incidents (type::incident): bugs, things going down, missing files, etc.

The helpdesk process


In general, the helpdesk reviewer should:

  • Review new tickets as they come in and assign priority:: and type:: labels
  • Aim to resolve tickets themselves whenever possible
  • If immediate resolution is not possible, ensure tickets are assigned to relevant colleagues:
    • Urgent/high priority: discuss assignment during standup, or if necessary (time-critical) with the relevant coordinators as soon as possible
    • Normal priority: discuss assignment during the end-of-the-week review (Fridays)
  • If necessary, create proper issues in relevant repositories/projects, with a link back to the ticket
  • Ensure all tickets that are actively worked on have the in progress label (e.g. derived issue and MR has been created and is being worked on)

Special considerations for incoming sequencing projects (delivery):

  • Delivery tasks should be assigned priority::urgent within the project and downgraded to priority::normal whenever urgent samples have been delivered
  • Close when all samples are delivered

At the end-of-the-week review (Fridays), the helpdesk reviewer should discuss with the group:

  • All in progress tickets; if stalled, decide on further action
  • Priority upgrades / downgrades
  • Assignment of normal priority tickets / derived issues
  • Evaluate follow-up of tickets of type::general with improvement to our docs or helpdesk knowledge base (FAQ)

Closing/pruning tickets

In general, helpdesk tickets should be closed only on confirmation from the user that they are actually resolved, except for:

  • Tickets related to delivery of sequencing projects, which can be closed when all samples have been delivered (see above);
  • Tickets labeled priority::low, which may be closed after evaluation (see description of this priority).

Helpdesk implementation in Gitlab

General considerations

The helpdesk repository belongs to the DPIPE group.

Labels and boards

We use labels on the project level (these can be promoted to global if needed). The labels we use for helpdesk tickets are:

  • helpdesk for ease of filtering
  • in progress for tickets that are assigned and actively worked on
  • A priority:: label
  • A type:: label

Board for helpdesk: open - in progress - closed. The open and closed labels are applied automatically on creating / closing tickets.

Receiving notifications

  • Gitlab users with “Watch” notification level for a project will receive notifications about issues, merge requests, and epics
  • The notification level can be chosen by clicking on the bell sign to the right on the main project page

Creation of helpdesk tickets

Helpdesk tickets are created automatically upon email receival at the address

  • On ticket creation: template with short process description - we will figure it out once we've got some experience and statistics.
  • All relevant users must send their sequencing project announcements to the helpdesk's email following a specific template (to be provided).

Creation of derived project-level issues

Whenever appropriate, issues to resolve the helpdesk ticket should be created by the helpdesk reviewer in relevant repositories/projects. These issues should be linked back to the relevant helpdesk ticket (under "Linked issues").

Derived issues need not be created for tickets that are promptly resolved by the helpdesk reviewer and do not require further follow-up.

Automated Issue Triage

To automate labeling new issues with the helpdesk label, a webhook solution has been set up, i.e. triage-bot. The bot solution utilises a Gitlab API project token to edit issue labels, which is generated under the settings tab of the helpdesk DPIPE repository: Settings -> Access Tokens. These access tokens are set with an expiry date, which defaults one month (maximum 365 days). To do this, we need to (this will disrupt triage bot service, so it should be done outside of business hours):

  1. Delete old token on Gitlab
  2. Create new token on Gitlab, with role Reporter (to handle confidential issues), and scope Issue Event.
  3. Add the newly created token to the :gitlab -> :api-token key in the secrets file of the triage bot on live server.
  4. Restart triage bot service on our remote server.