This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Just a small point of correction, around the 02:50 mark you mentioned that it's required to set up both the incoming and custom service desk mailboxes on self-hosted instances. However, it's actually perfectly fine to just use the incoming email address and never set up the custom mailbox.
I think this is a common point of confusion for customers also and not exclusive to your presentation.
FWIW, I think we could make it required to set up the custom mailbox and ignore the incoming mailbox completely with Service Desk. This would be more work but somehow I think it would be clearer to the user. But I digress!
Just a small point of correction, around the 02:50 mark you mentioned that it's required to set up both the incoming and custom service desk mailboxes on self-hosted instances. However, it's actually perfectly fine to just use the incoming email address and never set up the custom mailbox.
@johnhope thank you for pointing that out. You are totally right.
FWIW, I think we could make it required to set up the custom mailbox and ignore the incoming mailbox completely with Service Desk. This would be more work but somehow I think it would be clearer to the user. But I digress!
I also like that idea. In my approach I would only use the service desk email. I think that ways we could better separate mails from/to users (GitLab instance) from mails to/from external users. I will also clarify that later in the issue together with the breakdown.
This is a new format where we should not assume prior knowledge of the work of a SEG, showcase what we worked on, walk through some metrics and present goals for the upcoming month. If you watched the previous update videos you might want to skip certain parts of the video.
We have a new team Monitor Respond working on Service Desk and I decided to support them onboarding to the new domain and added some documentation. I also started an architectural concept discussion on the future of email ingestion in GitLab and shared the progress I made on email verification for customizable email addresses. In the end I talk about the goals for the last and upcoming month.
Service Desk SEG March Mid-Month Update available:
Discover the latest updates and developments in GitLab's Service Desk SEG, including the addition of native attachments for external participants and results from customer interviews. We’ll dig deeper into challenges with multiple issue email participants and the progress on custom email verification, as well as issues with forwarding emails in Microsoft O365.
We released native attachments for Service Desk emails, which allows external participants to receive uploads to a comment as a native email attachment. We also decided to deprecate the sidekiq delivery method for mail_room email ingestion in favor of the webhook delivery method. I made progress on custom email verification, including a new verification model, a move to a dedicated model for email credentials and merge requests for three verification email.
In the May Showcase for GitLab Service Desk SEG, we explore the latest developments in the Service Desk domain, including custom email addresses. We delve into the world of GitLab's email ingestion and discuss a proposed architecture change. Discover the deprecation note for the mail_roomsidekiq delivery method and documentation updates for multi-node environments. Lastly, we touch upon our ongoing investment in AI, specifically, our efforts to identify similar work items.
In the June showcase we walk you through the Service Desk custom email settings page workflow, the current development and state of the feature, and the plan to release it in Beta in 16.3 or 16.4. We also talk about service_desk_email and why we renamed it in the documentation to "additional Service Desk alias email".
The August showcase announces the release of custom email for Service Desk in beta in 16.4. We also explore new focus areas and take a look at automation with gitlab-triage and multiple external participants on issues.
We added more documentation for the custom email feature and are preparing a blog post about automation on Service Desk issues using gitlab-triage. We also published the first version of a architecture evolution blueprint for email ingestion and some smaller fixes.
The October showcase covers the custom email iteration plan and the current work on multiple external participants. Now it's possible to put reply by email and Service Desk emails in the CC header. In the end, you'll see some smaller changes and the goals section.
Service Desk SEG 16.6 Showcase (November 2023) available:
In the 16.6 showcase (November 2023) I'll cover updates to the custom email address feature, bug fixes, and details about a vulnerability we fixed. Additionally, due to the latest restructuring the Service SEG now owns the feature categories of the former Respond group. See all the details in the video. Have a pleasant end of the year and see you in 2024!