• Service Desk workflow
• Related topics
• Troubleshooting Service Desk
  • Emails to Service Desk do not create issues
  • Email ingestion doesn’t work in 16.6.0 self-managed

Service Desk

With Service Desk, your customers can email you bug reports, feature requests, or general feedback. Service Desk provides a unique email address, so they don’t need their own GitLab accounts.

Service Desk emails are created in your GitLab project as new issues. Your team can respond directly from the project, while customers interact with the thread only through email.

For a video overview, see Introducing GitLab Service Desk (GitLab 16.7).

Service Desk workflow

For example, let’s assume you develop a game for iOS or Android. The codebase is hosted in your GitLab instance, built and deployed with GitLab CI/CD.

Here’s how Service Desk works for you:

1. You provide a project-specific email address to your paying customers, who can email you directly from the application.
2. Each email they send creates an issue in the appropriate project.
3. Your team members go to the Service Desk issue tracker, where they can see new support requests and respond inside associated issues.
4. Your team communicates with the customer to understand the request.
5. Your team starts working on implementing code to solve your customer’s problem.
6. When your team finishes the implementation, the merge request is merged and the issue is closed automatically.

Meanwhile:

• The customer interacts with your team entirely through email, without needing access to your GitLab instance.
• Your team saves time by not having to leave GitLab (or set up integrations) to follow up with your customer.

Related topics

• Configure Service Desk
  • Improve your project’s security
  • Customize emails sent to external participants
  • Use a custom template for Service Desk tickets
  • Support Bot user
  • Default ticket visibility
  • Reopen issues when an external participant comments
  • Custom email address
  • Use an additional Service Desk alias email
  • Configure email ingestion in multi-node environments
• Use Service Desk
  • As an end user (issue creator)
  • As a responder to the issue
  • Email contents and formatting
  • Convert a regular issue to a Service Desk ticket
  • Privacy considerations
• External Participants
  • Service Desk tickets
  • As an external participant
  • As a GitLab user

Troubleshooting Service Desk

Emails to Service Desk do not create issues

• Your emails might be ignored because they contain one of the email headers that GitLab ignores.

• Emails might get dropped if the sender email domain is using strict DKIM rules and there is a verification failure due to forwarding emails to the project-specific Service Desk address. A typical DKIM failure message, which can be found in email headers, might look like:

  dkim=fail (signature did not verify) ... arc=fail
  

  The exact wording of the failure message may vary depending on the specific email system or tools in use. Also see this article on DKIM failures for more information and potential solutions.

Email ingestion doesn’t work in 16.6.0 self-managed

GitLab self-managed 16.6.0 introduced a regression that prevents mail_room (email ingestion) from starting. Service Desk and other reply-by-email features don’t work. Issue 432257 tracks fixing this problem.

The workaround is to run the following commands in your GitLab installation to patch the affected files:

curl --output /tmp/mailroom.patch --url "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/137279.diff"
patch -p1 -d /opt/gitlab/embedded/service/gitlab-rails < /tmp/mailroom.patch
gitlab-ctl restart mailroom

curl --output /tmp/mailroom.patch --url "https://gitlab.com/gitlab-org/gitlab/-/merge_requests/137279.diff"
cd /opt/gitlab/embedded/service/gitlab-rails
patch -p1 < /tmp/mailroom.patch
gitlab-ctl restart mailroom