Teams where engineering runs on Linear and everybody else — support, customer success, ops — has no way to see whether a customer's issue has moved without asking someone.
Pull Linear into RowFold tables you own — filter them, report on them, link them to everything else in the workspace.
And it stays current: importing again updates the same tables, adding new records and updating changed ones, so links from your other tables hold. Keep in sync does that for you hourly or daily.
Automation steps that act on Linear when something happens in RowFold:
What it doesn't do: It has no say in what a booking page offers. An import only reads: nothing is written back to Linear, a record deleted there stays here, and a sync runs hourly at most rather than the moment something changes. Anything else you have read about Linear and RowFold, this page is the authority: it is generated from the connector's own code.
The aim is not to mirror Linear. It is to put enough of it beside the tickets that the people answering customers can answer without interrupting an engineer, which takes an import and one relation.
You'll know it worked: Open a ticket you know is waiting on a fix and confirm the linked issue and its status are on it. If support still has to open Linear to answer, the relation is the piece that is missing.
The useful version of this is not a one-way dump. File the issue, then put the link back on the ticket, so the person who reported it can be told when it moves without anybody searching for which issue it became.
You'll know it worked: Tag a test ticket and check three things: the issue exists on the right team, its title is readable on its own, and the link came back onto the ticket. The third is the one that is usually forgotten.
Linear is built for the people who fix things, and most of the people who need to know are not them. Support cannot answer “is this fixed yet” without asking in a channel, which costs an engineer's attention every time.
Imported issues are rows anybody can be given access to, in the same workspace as the tickets and the customers. The question is answered by looking rather than by interrupting.
An issue knows nothing about who is waiting for it. Three customers reported the same bug and that fact lives in three support threads, so nobody can say what fixing it is worth.
Link issues to the tickets and accounts that raised them. Then the list of who to tell on release is a query rather than an archaeology exercise.
Anything worth filing that is noticed outside Linear gets retyped into it later, or does not get filed at all because the person who noticed does not have a seat.
An automation files the issue at the moment the thing happens, with the detail already attached, from a table the whole team can reach.
No, and the import says so. Descriptions arrive as Markdown text and the discussion underneath each issue stays in Linear. That is deliberate rather than a gap: the conversation is where engineers work, and copying it into another tool produces two half-threads. What comes across is the state everybody else needs, which is the status, the assignee and the dates.
No. The connection reads issues and can create new ones, and nothing else. An imported row is a copy for visibility, so editing it changes nothing in Linear. That is the right way round for the problem this solves: the point is to stop support interrupting engineering, not to let support reprioritise the backlog from a different tool.
As current as its last run. Importing a team again updates its table, matched on each issue's Linear ID, so status, assignee, priority and estimate follow Linear and new issues are added; Keep in sync does that hourly or daily. Nothing flows the other way. If somebody genuinely needs the status to the minute, the honest answer is that they need Linear, and per-table permissions here cost nothing to combine with that.
No, and that is most of the value. Imported issues are ordinary rows governed by RowFold's own permissions, so account managers and support can be given read access to the issue table without a seat and without the ability to change anything. One person connects Linear; everybody else reads the table.
To read, and to create issues. It deliberately does not ask for the blanket write scope that would let it change or delete anything in your Linear account, because the only thing it writes is a new issue. That narrower request is also what a team reviewing the consent screen will see, which matters when the people approving it are the people whose backlog it touches.
There is no template to wait for. Type a sentence about what you run and RowFold assembles the tables, links, views and dashboard around it — then you change whatever does not fit.