How to Send a Private Internal Note on a GitLab Service Desk Issue Without Emailing the Customer
Yes. GitLab issues have a comment type built for exactly this, called an internal note, and it works on a Service Desk ticket the same way it works on any other issue in the project. Below the comment box there's a checkbox: "Make this an internal note." Check it, write the comment, and submit, and the comment is added to the issue but restricted to project members with at least the Reporter role, per GitLab's documentation on discussions. The customer who opened the ticket by email never sees it and never gets an email about it.
The reason this catches people on Service Desk specifically is what actually triggers the email. A Service Desk ticket is a confidential issue by default, visible only to people in the project, and the person who filed it was never a project member and never had a link into GitLab to browse it in the first place. Their whole relationship to the ticket runs through email: an automatic "we are tracking your request as ticket #123" the moment they send it, and after that, per GitLab's Service Desk usage docs, external participants "receive Service Desk emails for any public comment on the ticket and can reply to these emails." Any new comment goes out, unless they've unsubscribed. The word doing the work in that sentence is public. Mark the comment internal instead, and it stops counting.
Two separate settings that look like one
The confusion usually comes from the fact that "confidential" is already sitting there, checked, on every Service Desk ticket. It's natural to assume there's a second version of that same toggle for individual comments, maybe a quick action like /confidential typed into a reply. There isn't one. Confidential is an issue-level property: it controls who in your GitLab instance can see the ticket exists at all, and Service Desk turns it on automatically so the ticket doesn't show up in a public issue list. It has nothing to do with whether a given comment goes out by email.
What decides that is a second, unrelated setting that lives per comment rather than per issue, and it's simply public or internal. A Service Desk ticket can be confidential at the issue level and still email the customer on every reply, because every one of those replies is a public comment. The two settings answer different questions, and mixing them up is how a private "let's ask engineering before we commit to a date" note ends up in someone's inbox.
The mechanism, step by step
- Open the Service Desk issue like any other GitLab issue.
- Type the note in the Comment box as usual.
- Below the text box, before submitting, select Make this an internal note.
- The submit button relabels to Add internal note. Click it.
You need the Reporter, Developer, Maintainer, or Owner role on the project to do this or to read a note someone else added; Guests and, obviously, the external Service Desk participant, don't see it exists. There's also a faster path than the checkbox: type /internal_note on its own line while writing the comment, and GitLab converts the whole thing to an internal note on submit, per GitLab's quick actions documentation. It only works while you're composing the comment, not when editing one already posted, so the habit to build is typing it before you hit submit the first time, not after. Once that's automatic, it's closer to /close than to a checkbox you have to remember is there.
Bettina Hollis needed a second opinion, not a customer update
Bettina Hollis leads support for a small team that builds inspection-scheduling software for industrial testing firms. Customer requests come in through a GitLab project called client-support, with a Service Desk address that routes straight into it. On a Tuesday, an email arrived from Terrence Yoon, a facilities manager whose compliance team runs a weekly export out of the product:
Terrence Yoon (Service Desk email): Our weekly compliance export has been missing the calibration timestamps for the last two runs. Is something broken on your end, or did we change a setting?
Bettina didn't know yet whether this was specific to Terrence's account or a bug that would hit every account running the export on a schedule, and she didn't want to promise a fix date until she knew which. So she posted a comment and checked the box:
Bettina Hollis (internal note): @dana can you check if this is the same regression as
client-support#118from last month? If it's the scheduler job dropping a field again, we need to say something broader than "looking into it" before Terrence escalates this to his account manager.Dana (internal note reply): Confirmed, same regression. Already fixed in !212, waiting on code review.
None of that exchange, the guess about the root cause, the reference to another customer's ticket number, the internal timeline pressure, went to Terrence. When Bettina had a real answer, she wrote a normal public comment, and that's the one that reached his inbox:
Bettina Hollis (public comment): Confirmed this is a bug in the scheduled export job, already fixed and waiting on review. Expect it deployed by Thursday, and I'll re-run this week's export for you once it ships so you're not missing the timestamps in your compliance record.
What an internal note can't do
Internal notes solve the one problem they're built for, which is keeping a specific comment off the customer's inbox. They don't solve the problems next to it.
- The note lives inside one issue. If Terrence's team files a second Service Desk ticket next month about the same export job, or mentions it in a Slack Connect channel your sales team monitors, nothing connects that mention back to Bettina's note on
client-support#118. Someone has to remember it happened. - It's binary, not scoped. A note is visible to Reporter role and above, full stop. There's no way to write a note that engineering can see but the account team can't, or vice versa, without moving the conversation somewhere else entirely.
- It doesn't dedupe across customers. If three different accounts hit the same export regression and three different support engineers each write their own internal note guessing at the cause, nobody notices they're the same bug until someone happens to read all three.
That third one is usually the one that actually costs time. Modem is what we build, and it's built for that layer specifically: Modem's GitLab integration watches the Service Desk projects you connect, and reads Slack, other support tools, and calls alongside them, so a request that showed up as Terrence's email, a mention in a renewal call, and a second customer's ticket next month all land in one topic instead of three unrelated threads. The internal discussion about root cause stays internal the same way an internal note does; the difference is it's attached to the customer and the pattern, not just to the one issue it happened to be typed into.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionBelow the volume where that pattern-matching pays for itself, the built-in split is enough on its own. A five-person team running Service Desk for a few dozen tickets a month doesn't need a context graph to remember that Terrence's account hit a scheduler bug once; someone remembers, or the note is still right there on the issue the next time it comes up. Modem is the thing we sell, which is worth keeping in mind while reading that; the line worth trusting anyway is the volume one, not the bias one, and it's the point where "someone remembers" quietly turns into "no one does."
Two related guides worth reading next cover whether Service Desk works as a real helpdesk or just an email-to-issue bridge, and how to tell which GitLab issues came from a real customer versus an internal idea once a ticket like Terrence's has been triaged and needs to carry that context forward.
One checkbox, and the habit that goes with it
Check the box. That's genuinely most of it. The next time a Service Desk reply needs a second opinion before it goes out, write it as an internal note instead of a public comment, and confirm with a teammate who has Reporter role or higher that they can see it while the customer's own follow-up email can't. Do that once, and the habit takes less time to build than explaining to a customer why they got looped into an internal debate about whose bug it was.
