How to Tell Which GitLab Issues Came From a Real Customer vs. an Internal Idea
You can't tell, not from the issue itself. GitLab's issue model has a title, a description, an assignee, labels, a milestone, and on paid tiers a weight and custom fields, but nothing called "source" or "customer." An issue filed because a customer emailed in looks identical, structurally, to one an engineer opened after a Friday afternoon idea. Whatever tells them apart has to be something your team writes into the issue by convention, because GitLab isn't going to write it for you.
The answer to "how do I tell" is: check whichever of three places your team has agreed to put that information, if your team has agreed on one. A label, a custom field, or a line in the description. Most teams that get this working use one of the three consistently; most teams that don't get it working never picked one at all.
“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 NotionWhy GitLab leaves this to you
GitLab has looked at this gap before and not closed it. Issue 8571, "Gathering user feedback in GitLab: Discovery," is GitLab's own product team scoping out how user feedback should flow into the tracker, and it's been open for years without becoming a shipped field. The closest thing to precedent from inside GitLab's own trackers is issues like gitlab-ui#2229, "Accessibility feedback from customer," where a reporter distinguishing a large customer's audit findings from GitLab's internal review just puts "from customer" in the title. That's the ad hoc pattern: whoever files the issue types the provenance into free text, if they remember to.
The reason this stays free text is that GitLab's issue is deliberately a generic unit of work. It's the same shape whether it comes from a support escalation, a sales call, a competitor's changelog, or someone's shower thought. Adding a first-class "customer" field would mean deciding what a customer even is across every kind of GitLab project, from an internal platform team's issues to a public open-source repo's, and GitLab has consistently left that decision to each team instead of making it for everyone.
Three ways to mark it, since GitLab won't
A label convention. The plain-tier version is a label like customer-reported, applied by hand at filing time, available on every GitLab plan including free. If you're on Premium or Ultimate, scoped labels let you go further with a source::customer / source::internal pair using the key::value syntax. Scoped labels are mutually exclusive by key, so an issue can't accidentally carry both source::customer and source::internal at once. Either version lives or dies on people remembering to apply it.
A custom field. Work item custom fields are a newer, Premium/Ultimate-only mechanism, configured at the group level, that give you a proper single-select field, "Source," with options like "Customer," "Internal," and "Support escalation." It's more structured than a label because it shows up as its own row on the issue rather than buried in a label list, and a group can carry up to fifty custom fields with up to ten assigned per work item type. Still filled in by a human at filing time, same as the label.
A line in the description. GitLab's description templates let you commit a .gitlab/issue_templates/Default.md file, or set a default template in project settings on Premium and Ultimate, that pre-fills every new issue with a "Reported by" line. This is the lowest-friction option on the free tier: the field is already there when someone opens a new issue, they just have to fill it in rather than remember to create it.
None of the three is better than the others in the abstract. The label is fastest to set up, the custom field is the most structured, and the template is the hardest to forget because it's already sitting in the box. What all three share is the same failure mode: they only work if the person filing the issue actually does the extra step.
Where the convention runs out
Even applied perfectly, hand-written source labels have a ceiling:
- They only capture who typed the issue, not who asked. When a support engineer files the issue, the requester's name lives in a description line written from memory or copied out of a ticket open in another tab, not in a field GitLab understands as a person or an account.
- They don't survive the request being asked twice. If a second customer hits the same bug next month, nothing connects their report to the existing issue unless someone happens to remember it and links the two by hand.
- They don't scale past whoever's disciplined. A label convention that one meticulous engineer maintains looks like a real system until that engineer goes on vacation, and then it's a label nobody's applying consistently anymore.
That third point is where hand conventions stop being enough, usually somewhere past a couple dozen customer-sourced issues a month spread across more than one project. At that point the fix isn't a better label scheme, it's a system that already knows where a request came from before anyone opens GitLab.
That's what Modem does. Modem's GitLab integration watches the projects you connect, and ties the topic behind an issue to the person and company who raised it, sourced from wherever the request actually came in, a support ticket, a Slack thread, a sales call transcript, whether or not anyone remembered to type it into a label. When the same customer contact emails in again about a different problem, Modem already knows they've asked before, so the second report lands connected to the first instead of starting a fresh, unlabeled source::internal-looking issue that nobody links back. We sell Modem, so weigh that against the alternatives compared in the best tools for turning customer feedback into GitLab issues. For a team still under that couple-dozen-a-month threshold, the label convention above costs nothing and is worth setting up properly before reaching for anything more.
Pick one marking mechanism and write the rule down
Pick one mechanism, not all three. If you're on GitLab Free, commit a Default.md template with a "Reported by" line; it's already in the box the next time anyone opens a new issue. If you're on Premium or Ultimate, a source::customer / source::internal scoped label pair takes ten minutes to create and gets checked automatically by the mutual-exclusivity rule. Either way, write the one-sentence rule down somewhere the whole team will see it, and apply it to the very next issue you file. A convention nobody wrote down is a convention that dies with whoever remembers it.