The Service Desk SEG is a Single-Engineer Group within our Incubation Engineering Department.
Our goal is to provide a complete, yet lightweight and customizable customer support solution that seamlessly integrates with the GitLab ecosystem and brings customers, support staff and developers closer together.
Please feel free to subscribe to this GitLab issue to receive notifications when new updates are available.
Watch the latest video
We publish short mid month update videos and longer end of month showcase videos to demonstrate our progress.
| Date | Summary / written version | Video |
|---|---|---|
| August Showcase (2023-09-19) | August 2023 Showcase | Showcase Video |
| July Showcase | - | - |
| June Showcase (2023-07-07) | June 2023 Showcase | Showcase Video |
| May Showcase (2023-06-13) | May 2023 Showcase | Showcase Video |
| April Showcase | - | - |
| March Showcase (2023-04-06) | March 2023 Showcase | Showcase Video |
| March Mid Month Update (2023-03-22) | 15.10 release, customer feedback, verification | Update Video |
| February Showcase (2023-03-02) | February 2023 Showcase | Showcase Video |
| Update 4 (2023-02-21) | 15.9 release, GDK docs, verification | Update Video |
| January Showcase (2023-01-30) | January 2023 Showcase | Showcase Video |
| Update 3 (2023-01-20) | Foundation & verification | Update Video |
| Update 2 (2023-01-06) | First MR & upcoming tasks breakdown | Update Video |
| Update 1 (2022-12-09) | Product Vision & customizable E-Mail Addresses | Update Video |
We are also exploring ideas, existing issues and user feedback. Please feel free to contribute.
Custom email address for Service Desk is planned to be released in Beta in GitLab 16.4 and is already available on GitLab SaaS.
Right now GitLab does not support a fully customized and professional e-mail experience throughout the communication with the customer. You can add e-mail forwarding from your own e-mail address to the Service Desk intake e-mail address, but the sender of the inquiry will always receive answers from the default GitLab instance address. That is especially a show-stopper for gitlab.com customers as they do not want to have GitLab e-mail addresses in their customer communication.
We are actively working on bringing configurable e-mail addresses on a per-project basis to GitLab Service Desk. The proposed solution will involve little changes to existing functionality and we will iterate on that to make it even easier to use in the future.
Customers will need to configure e-mail forwarding from their desired Service Desk e-mail address to the
provided Service Desk intake e-mail address by the GitLab instance. They will then add SMTP credentials for that address so
the GitLab instance will be able to send e-mails on behalf of that configured e-mail address.
We will also allow Reply-To e-mail headers to use the configured e-mail address to deliver a complete package.
If you have questions or would like to share feedback, see this issue.
Native attachments for Service Desk emails allow external participants like the issue author to receive uploads to a comment as a native email attachment (up to 10MBs). This is great because previously based on your project settings or instance configuration external participants could not access media assets via the provided links in certain scenarios.
Shipped in gitLab 15.10. See the release post item and the feature issue. This SEG did not implement the feature, but mentored the team, designed the solution and published the feature.
Making sure private data is protected no matter where a Service Desk issue ends up. If you do not have at least the reporter role in a GitLab project or group, you won’t be able to view the email address of the author of a Service Desk issue and issue email participants in general. No matter whether it’s a public or private project or the issue is confidential or not.
Shipped in GitLab 15.9. See the release post item
If you want to get more into the details, check out the merge request which also links to all related issues.
We have a Service Desk offering in GitLab that we'd like to make an integral part of the GitLab support workflow. We have early usage, a community of prolific contributors and a new team (Respond group in Monitor stage) onboarding to the new domain.
