Can a GitLab Issue Belong to More Than One Project or Group?
No. A GitLab issue is created inside one project and stays there. There's no setting, no permission level, and no tier that lets a single issue live in two projects at once, and there's no way to attach one issue to two different groups either. If a customer's request touches your API repo and your frontend repo, GitLab's model wants two issues, one per project, connected however you choose to connect them.
That's not a gap GitLab has overlooked. It's an open feature request. Issue 296668, "Share an Issue/Epic To Multiple Projects or Groups," has been sitting in GitLab's own tracker asking for exactly this, the ability to give one work item a home in more than one namespace so it can carry per-namespace milestones, iterations, and labels. It's still open. Until it ships, if it ever does, the honest answer is that you maintain two linked issues by hand, and the quality of that link is entirely up to you.
Why the project is the hard boundary
GitLab's permission and visibility model is built around the project. Every issue inherits its access rules, its labels, its milestones, and its board membership from the project it was filed in. Loosening that would mean deciding what happens when two projects have different members, different label sets, or different visibility levels, which is most of why issue 296668 is still open rather than shipped.
Groups sit one level up and don't change this. A group is a container for projects, not a container for issues directly, so "make the issue belong to the group instead" isn't an option either. The closest GitLab gets to a cross-project container is the epic, and epics are their own topic with their own tier requirement; we've covered that comparison separately in GitLab epic vs. issue for feature requests. What matters here is narrower: whatever container you use, the underlying issue is still one issue, in one project, full stop.
The three ways teams connect issues across that boundary
None of these merge two issues into one. Each just gives the two issues a way to point at each other, or a shared view to sit inside.
- Related issues. GitLab's related issues feature lets you link any two issues as "relates to," "blocks," or "is blocked by," and the docs are explicit that this works across projects: "You can link issues in different projects." The catch is that the link is purely a pointer. Each issue keeps its own status, assignee, and milestone, and the relationship "only shows up in the UI if the user can see both issues," so a viewer without access to the frontend repo won't see that the API issue has a sibling.
- Group milestones. A milestone scoped to the group, rather than to one project inside it, can be assigned to "any issue, epic, or merge request of any project in that group," per GitLab's milestone docs. That gets you one progress view listing both issues side by side, grouped by status, which is the closest built-in thing to "one item, two projects" GitLab currently offers. It requires the projects to share a group, and it's a shared view, not a shared issue.
- Epics. On Premium or Ultimate, an epic can gather issues from projects across a group hierarchy under one parent. It's the heaviest of the three options, and it's also the one people reach for by default because it looks like the "real" cross-project container. It's the same tier-gated tool the epic-vs-issue guide above walks through in more depth.
A fourth option looks like it solves this and doesn't. Moving an issue, per GitLab's issue-moving docs, closes the original and copies it into the target project, adding a system note on each pointing to the other. That's a relocation, not a duplication. You still end up with one issue living in one project; it's just a different project than the one it started in.
The two Cascadia Sensors issues that were one request
A utility customer, Meridian Power, wrote in asking Cascadia Sensors for per-device alert thresholds on its grid-monitoring hardware: configurable per sensor rather than fleet-wide, so a substation sensor and a residential one could trigger at different voltage deltas. Cascadia's GitLab instance splits along the same line most hardware-plus-dashboard shops use, a sensor-api project for the firmware-facing service and a dashboard project for the customer-facing web app, both under one group. Most requests only ever touch one of the two projects. This one needed both: the threshold had to be stored and enforced somewhere, and someone had to be able to set it.
Cascadia's on-call engineer, Bram Whitlock, filed two issues:
sensor-api#412: Add configurable per-device alert thresholds to the sensor config schema. Requested by Meridian Power, who need substation and residential sensors to trigger at different voltage deltas.
dashboard#188: Add a per-device threshold field to the sensor settings panel, reading/writing sensor-api#412's new config field.
He linked dashboard#188 to sensor-api#412 as "relates to," and both got the group milestone Q4 grid alerts so they'd show up together on the milestone's progress view. That's the right use of the tools GitLab gives you, and for a two-issue request it holds up fine. The link survives, the milestone view shows both moving, and anyone who opens either issue sees the pointer to the other.
Where manual linking stops working
The trouble starts at the third or fourth cross-project request, not the first. Three things degrade in a way that doesn't show up until volume:
- The link is only as good as whoever remembers to add it. Nothing in GitLab notices that
sensor-api#413anddashboard#190are actually the same customer's follow-up unless a person recognizes it and links them, and a filed-in-passing issue with no linking step just as easily ships as two unrelated items. - "Who asked" lives in whichever issue someone happened to write it into, usually just one of the two, and the other issue's assignee has no way to see it without opening the first.
- The group milestone view only helps if every related pair gets the same milestone assigned, which is one more manual step that has to happen consistently across everyone filing issues, not just the person who noticed the connection this time.
None of this is a GitLab shortcoming. It's what you'd expect from a system where the issue, not the customer's ask, is the unit of record. Two issues that both trace back to Meridian Power's alert-threshold request have no shared parent unless someone builds one by hand, every time.
That's the point where it's worth tracking the request itself as the thing that's real, and letting the GitLab issues be however many of them it takes to resolve it. That's what Modem does. It keeps the customer topic, not the tracker issue, as the source of truth, and Modem's GitLab integration links every GitLab issue across the projects you connect that resolves a piece of that topic, whether that's one issue or four. Ask Modem "what's the status of Meridian Power's alert-threshold request" and it answers from both sensor-api#412 and dashboard#188 at once, because the topic already knows both exist, instead of relying on someone having remembered to add the "relates to" link the day it was filed. Modem is what we build, and the fair caveat is that the Cascadia setup above, one related-issues link plus one shared milestone, costs nothing and holds up fine for as long as the request stays a single linked pair.
Two habits that hold up until the volume doesn't
A related-issues link and a shared group milestone don't require any new tool, and for most teams they're enough. Add the link the moment you file the second issue, not after the fact, so it never depends on someone remembering later. Put every request that spans your group's projects onto the same milestone so there's at least one view where both issues move together. And write the requester's name into both issues, not just the first one filed, since the second issue's assignee has no other way to see it. None of that scales past the point where cross-project requests outnumber what one person can track by hand, but that point arrives later than most teams expect, and it's worth reaching before reaching for anything heavier.
For the related question of what happens once a GitLab issue is properly triaged and needs a decision on scope, what's the actual difference between a GitLab epic and an issue covers the next fork in the road.
