Pin as Thread button

Ideas & Features
1

(Apologies if this has already been suggested, I couldn’t find a similar one).

I’d like to propose a small (hopefully) change that could significantly improve the Threads UX for us and, maybe, for everyone.

  • Current workflow:

Go to a space → Click "New" → Select "View/Thread" → Search for the right entity among thousands → Name the thread

Result: A new redundant view is created in the space, along with a thread in the Threads section.

That’s five steps just to start a conversation. It’s a lot of friction.

  • Proposed Workflow:

Right-click any entity with comments → Click "Pin as Thread" or "Create Thread"

Result: A thread is created with the entity’s name as the default title (editable).

That’s just two steps. Or even one, if the entity is already selected, which is the most common use case. Someone is reviewing an entity and decides to start a discussion. That moment should be seamless.

In our experience, this friction is a major reason why Threads aren’t used more often. It takes too much effort to initiate one.

This change would make it easy to spin up a lightweight, contextual discussion and close it once it’s no longer relevant.

Bonus idea: let the thread be visible only to participants - anyone who commented or was mentioned (to keep things focused and clean).

1 Like
2

Where would the thread be pinned to? Where would the thread view be found?

And how would the discussion be closed once it’s no longer relevant?

3

It is same way it works now but with Pin thread it would create thread named same as Entity and then if would appear inside Threads and as Thread itself and then you could move it anywhere you want. This just makes sense to me.

4

This would have to be solved by fixing thread permissions. Now when you invite observer they can see all the threads ever created and it goes same for members I think. Also you can mention anyone inside whole workspace as observer without any entity or space permission.

5

It could stay the same as now - under the Threads top section. No need to show the thread view specifically, just a thread channel is enough. Threads are for easy to access discussions.

Also it could be closed same way as now - right-click on a thread and click Delete.

6

Not necessarily.
Potentially, the visibility of a Thread could be determined by whether or not the person is watching the entity that the thread belongs to.

This is entirely separate to the issue that thread views in the sidebar are currently visible to everyone (except guests) irrespective of permissions for the entity they are based on.

1 Like
7

This solution could stay outside of permissions. Just the “default visibility”. Anyone could still join the thread, but it’s visible to comments participants only by default.

8

I think this is what I’m unclear on. The ways to view discussions (comments on an entity) right now are in a thread view, or in the comments field of the entity. How would a “thread channel” be different, as it sounds like you are still talking about threads consisting of the comments from an entity? (or by “thread channel” are you referring to the “Threads” top level section in the sidebar?)

9

Sorry for the confusion. Yes, I’m talking about “Threads” top level section in sidebar. IMO threads are for easy-access communication and no explicit thread view in a space is needed. Nevertheless I understand that it might be useful to have thread views, but in most cases IMO “Threads” top level section is the way to go.

10

Currently, most of our used threads are thread views in spaces. They are used as general conversation for each department. Perhaps this might change if threads ever move on from being experimental. But in this way they have replaced our need for Slack. I actually don’t know of anyone in our org, other than myself, who uses the Threads section (almost everyone has left the threads feature off but can still see and use any thread views that have been made in their spaces).

11

One more attempt! :slightly_smiling_face:

I’m not the one to judge, but in my opinion, the current use cases are not quite the Fibery way.

The current approach works for general conversations in Threads by creating artificial entities via the Comments field - but it feels disconnected from the core idea of contextual collaboration.

What I’d love to see is better use of context, which Fibery already excels at. There are plenty of entities with Comments, but no smooth way to use Threads directly within them.

One idea: make Thread an explicit type - just like databases, entities, views, and documents.

For example, add a Pin button in any Comments section that creates a Thread and surfaces it in the top section of the Threads panel (with auto-naming). This would allow anyone to spin off a comment into a contextual conversation - one click away. As proposed before, the thread would be visible only to watchers.

Additionally, it could be possible to create a View in a Space around a Thread. So instead of Threads being wrappers for Views, sometimes a View could act as a wrapper for a Thread.

I know it’s a bit mixed, as Thread here still acts here as a view around another entity, but it solves the initial goal. Of course, we could make Threads as First-Class Entities with Relations (for example, to start several conversations around a project or a task entity, be included in views etc), but this would probably require much more effort.

Why this might be a win:

  • Enables direct, contextual discussions around any entity - which feels like the Fibery way (versus out-of-context channels).
  • Threads stay relevant and visible only to the right people - reducing noise.

Screenshot_20250627_095054
Screenshot_20250627_0950541920×895 45.3 KB

12

What do you mean by ‘artificial entities’?
A thread is merely a view of the entire comment field of an existing entity. It is true that if you want a thread view for ‘daily updates’ (like we do internally) then you might need to create an entity for this purpose. But if you have a project already, you can create a thread view for it.

What does this mean? If an entity has a Comments field, that field is basically the ‘thread’. If you wanted, you could create an entity view so that the Comments field is the only visible field showing.

This is definitely a good suggestion.

I don’t understand what you mean here. Thread is a view, which is contextually filtered to a single entity, and is exposing information from a single field (Comments). It isn’t a ‘wrapper’.

Maybe I’m too stupid to get your point, sorry.

13

I am personally against this idea. It adds another thing where there’s no need for there to be. You can think of a thread as a list of related messages, just viewed in a certain way.

I would perfer just a “Thread view (to see all related messages in a thread vire)”, than a “Single Entity View (to choose which entity to show pinned in the sidebar)” view.

It wouldn’t be as simple as “Pin as thread” in comments, but maybe in the three dots in the ENTITY itself there could be a “Pin to Sidebar” which will create a “Single entity” view in the sidebar of the current entity. Maybe?

But i do fully agree with this ^^^, i feel like not enough thought has gone into it quite yet.

14

:+1:

This is exactly thread view, no?

How is this related to the thread topic? It sounds like a separate feature request (“Allow to pin individual entities to sidebar”)

15

Kind of, but thread view on works with comments, I’m referring to having a thread view work with any to-many relation/top level thread view.

Maybe, but its related to this as its a different proposed solution to the same problem.

16

Ah, sorry, I wasn’t clear enough in my original message. I didn’t explain my thoughts properly.

What I meant is that there’s currently no easy way to create a Thread while you’re already in the Comments section. To do it, you have to jump through a few hoops: go to a space, right-click, select Thread view, search for the entity, name the thread… It’s a bunch of steps that are disconnected from where the conversation is actually happening.

That kind of workflow is fine when you’re setting up more stable, long-term threads. But it doesn’t work well for quick, contextual conversations you want to spin off in the moment.

A simple Pin button would really help with this.

Yeah, totally get that. I just wasn’t clear with the terms I used.

What I meant is: to get a Thread Channel (if that’s the right term?) to show up in the Threads panel at the top, you first have to create a Thread View somewhere in a space.

But often, we don’t want to have a Thread View sitting in a space - it feels a bit too formal or structured for the kind of quick, reactive conversations we’re having. Space items are usually things you go looking for. Thread Channels, on the other hand, are things you often just want to stumble upon or jump into when you see unread messages counter.

So, the idea is: clicking a Pin button creates a Thread Channel directly in the top Threads panel. And then, if you later want to organize it more formally, you could create a Thread View from it and drop it into a space.

Hope that makes more sense now. And sorry again for the earlier confusion.

1 Like
17

I think the idea is nice but there are bigger problems with thread now :slight_smile: All the threads are visible regarding entity permission.

18

By the way, JetBrains attempted something similar with their Spaces product.

Every time an item was created in their issue-tracking system, a corresponding thread was also generated (at least for tasks). Spaces has since been discontinued, and I suspect one of the reasons might be that the linear list of threads became overwhelming.

So Fibery isn’t alone in trying to adapt threads to contextual, hierarchical data. Personally, I think custom pinning would be a much better approach than automatically spamming threads - if such a feature is ever implemented.