How to Add Custom Fields to a Linear Customer Request
You can't add custom fields to a Linear customer request. There's no admin screen for defining a "severity" dropdown or a "deal stage" property on the request object the way you'd add a custom field in Jira or Salesforce. What you get is a fixed shape: a quote, a link back to the source conversation, the requester's name, a timestamp, and an "important" flag you can toggle per customer. That's the whole schema, by Linear's own documentation.
The closest thing to structure lives one level up, on the Customer record rather than the request. A customer in Linear carries Tier, Size, and Revenue, which sync in automatically from Intercom or can be filled in by hand. Those are still fixed fields, not ones you define, and they describe the account in general rather than the specific request. If you need severity, deal stage, or contract value on a per-request basis, Linear's own object model has nowhere to put it.
“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 NotionWhat actually ships on a request
Reading Linear's customer requests documentation closely, a request holds:
- The original message, quoted from wherever it came from
- Images or video, if someone adds them while editing
- A link to the source conversation (an Intercom thread, a Zendesk ticket, an Ask)
- The name of the associated user
- A timestamp
- A per-customer "important" flag, shown as a triangle icon, meant to mark a critical need rather than a nice-to-have
There's no field for who owns the deal, what tier of urgency it is, or what it's worth if it ships. The feature was built to answer "who asked, and what did they say," not "how do we score this."
What the Customer object gives you instead
One level up, a Customer in Linear is the company behind the request, and it does carry a little more shape, in the form of Tier, Size, and Revenue. Per the docs, these "will be automatically populated if you use the Intercom integration, or can be filled when creating customers manually," and admins can customize the revenue units and tiers themselves. That's real structure, but it's account-level and fixed to those three fields. It won't hold a per-request severity rating, and it won't hold a deal stage, because Linear's own Customer object doesn't model pipeline at all.
Labels sit on the issue, not the request, but they're not fixed the way that might suggest. Linear's own docs describe them as user-defined: you "create labels at the workspace level or for a specific team, so they're available only where relevant," and label groups add "one level of nesting," with "only one label from a given label group... applied to an issue at a time." That last part is Linear's actual native answer to something like a single-select severity or stage field, built by hand rather than admin-configured, but real. What's actually narrow is automated assignment: ClearFeed's own integration notes say plainly that "custom labels can't be added during creation from ClearFeed — assign them in Linear after the fact if needed." So whatever creates the issue on your behalf, a bot or an integration, tends to land it with no label at all, and a person goes back in and applies one from whatever set the team already built.
Northscale hits the limit at renewal season
At Northscale, a payroll compliance platform for staffing agencies, renewal season each October means customer success lead Priya Osei fielding a spike of Linear requests from accounts about to make a decision. Requests come in through Intercom, and for months that pipeline was fine on its own. Then the requests needed to say more than "who asked."
Priya, in a comment on a request: This is our third-biggest account by ARR and their renewal is in three weeks. I want eng to know that before they scope next sprint, but there's nowhere on this request to put "renewal risk" that survives someone scrolling past.
Sanjay on eng, replying: I get why it matters, but I'm not going to open every request's linked conversation to find out which ones are renewal-adjacent. If it's not a field I can filter on, it doesn't factor into planning.
Priya's workaround was a naming convention: prefix the issue title with [RENEWAL] and hope people noticed. It held for a couple of weeks. Then a differently-phrased request from the same account landed on a separate issue with no prefix, and the renewal risk on that feature went invisible again, because a title prefix isn't data Linear can query. It's a string a person has to remember to type, on every issue, every time.
The ceiling on each fix
Four things people try, and why each one caps out:
- Build a label group for it. A label group can simulate a single-select severity or stage field, since Linear only allows one label from a given group per issue. But someone has to create and maintain that group by hand, it lives on the issue rather than the request, and it carries no account or revenue context of its own.
- Prefix or tag the title. Works until volume passes what one person can type consistently, and it's invisible to filters and views. Linear can't sort by a string pattern in a title the way it sorts by an actual field.
- Write it into the request's context. The docs note requests can be edited in Linear to add images, video, or extra context, so you can paste "renewal risk: high" into the free text. It's readable, but not filterable or reportable; you're back to reading every request by eye to find the ones that matter.
- Push it to the Customer's Tier or Revenue. These are real, structured fields, but they describe the account, not the request. Two different requests from the same account share one Tier value; if one is a blocking bug and the other is a nice-to-have, Linear has no way to tell them apart at that level.
None of these are wrong exactly. They're what's left when the object model has a handful of fixed slots and your process needs one more.
Where a layer in front of Linear earns its keep
This looks like a deliberate design choice on Linear's part rather than an oversight. The complete guide to Linear Customer Requests covers the model's other boundaries, capture is link-driven, dedupe is a human call, and integration coverage has gaps of its own; fixed fields are a different limit from those, but they add up to the same shape. Linear built Customer Requests to answer "who asked, and what did they say," not to become a second CRM. It holds up fine for teams whose only per-request question is that one. It stops holding up once someone downstream, whether that's eng planning, a renewal conversation, or a QBR, needs to filter or sort by something Linear's schema doesn't have a slot for, and the honest fix isn't a heavier Linear setup. The fixed-field design reads as intentional rather than half-built, so counting on arbitrary custom fields showing up here later would be a bet, not a roadmap fact.
That's the point where the structured context has to live somewhere that already tracks it, and travel into Linear rather than being re-typed there. Modem connects to Salesforce and Stripe alongside the conversations a request comes from, so "accounts, contacts, opportunities, and users sync into Modem, so a feedback topic shows which accounts and deals it touches," without anyone hand-copying a deal stage into a title prefix. When Modem files or links a Linear issue, the account and pipeline context rides along with it instead of stopping at the request's four fixed fields. We build Modem, so weigh that against the fact that most teams below Northscale's request volume are genuinely fine on Tier, Revenue, and a disciplined title convention.
If your gap is upstream of fields entirely, meaning feedback shows up somewhere Linear's own integrations don't watch in the first place, that's a separate problem covered in is Linear enough for managing customer feedback.
The one-sentence version
If a piece of information needs its own field on a Linear customer request, it isn't going to get one; put it on the Customer's Tier or Revenue if it's account-wide, write it into the request's context if it's one-off, or bring in a system that already tracks it and let that context travel with the request instead of being retyped every time.
