Does anyone else think this would be a really useful feature to have in Fibery?
I’d suggested this feature quite some time ago. I’m trying to get feedback to see if others would find this as useful as I believe it would be.
It’s basically allowing collaboration on a single entity with each user being able to have that entity at a different stage in the workflow.
It sounds potentially useful to me.
It sounds a lot like storing a collection that contains a entity id and the state id.
However, would you want to flatten that or enforce any rules?
e.g.
What is the overall state?
How do you visualise this when viewing the state on the entity.
My other thoughts are also around workflow? But this is something, I’ve been mulling over for a while, and whilst I’ve got opinions, I don’t think I’m quite ready to share those, as need to try some more things out first.
Thanks for your response and sharing your thoughts there @uniquelau.
Perhaps there could be an Entity Workflow and an Assignee Specific Workflow at the same time. So the entity could be In Progress, while one user has set it to Done and the other is Not Yet Started. A simple rule to create would be, when all user’s Assignee Specific Workflows are at Final, set Entity Workflow to Final also.
The fundamental problem is that there is currently no simple way (that I’m aware of) to collaborate on a single entity where each user’s relationship with that entity can be managed by each user, without it adversely affecting all of the other users.
If we’re dealing with a software development team, then I guess it’s less of an issue, as the team can handle a more complex solution easily. But with teams of non-tech users, who perhaps struggle to even conceptualize what a one to many relationship even is, I believe there is real value in having a simple in built solution for this.
It’s such a common requirement. In any organic work environment, people will collaborate on a single entity. And users will always end up having different relationships to that entity at different times. Why not make it easy to manage, rather than hard?
What would the downside of such an elegant solution be?
If we had Relationship properties then having multiple relations to users (each with their own workflow state) would be possible.
The overall entity’s workflow state could then be defined using an aggregation formula.
That would be the solution I’m looking for, on steroids.
I hope I haven’t got your hopes up - I have no idea if/when relationship properties would be implemented unfortunately 
This is an interesting idea, and I imagine it may be more common than I would think. But multiple workarounds do come to mind, and I wonder how bad they would be in use once you set them up. Some of them might also require or at least benefit from some dev work, but perhaps it would be lesser than what you or Chris are proposing.
For example if Lookups allowed referencing Comment fields, you could have the comments for multiple separate entities in a single one (separate comment fields, but reflecting the discussion in multiple related/“children” entities). You could use formulas to calculate done status of a parent task from the state of its children, and automations to do anything you need to do when status of sub-entities change, etc. Or you could use the new/upcoming Feed view to see separate Entities relating to the same Project all together. These are just a few off-the-cuff thoughts, and I know all are imperfect. I just wonder… how much consideration and testing time have you put towards what a solution would look like given current functionality? Is it a major limitation, or more of an inconvenience?
Perhaps put more clearly: what are the specific work actions and information display you want to be able to take on a single entity that you currently cannot achieve satisfactorily in a parent-child (e.g. task/subtask) workflow? Overall done status display seems like it could be achieved fairly easily based on related entities. Collected comments doesn’t seem possible, but maybe Feed View could help with that? For splitting work, you could have an Automation generate a new child entity whenever an Assignee is added, so auto-work splitting. You could move between overall statuses (e.g. Kanban) based on collected status of children (when all are in state “completed”, the parent task gets moved to “completed”). Etc. Note that I haven’t tested all these, so it’s possible I’m forgetting some limitation that makes one of these not actually possible, in which case the question then is whether solving that issue would be easier or more broadly useful than an assignee-specific workflow feature.
As for accessibility and intuitiveness to non-tech users, I’ll grant my perspective is limited here (I’m more techie than average). But it seems to me if the idea of “collections” of related entities in Fibery doesn’t make sense to anyone using it, then… their use is going to be pretty limited anyway, regardless of this specific use case. Collections as a way to understand connected items, and to for example access your specific piece of work, would seem to me to be… reasonably intuitive? Basically no different than a list of tasks, where someone would look for the one assigned to them (you could display the assignee in the collection of related sub-tasks).
All that said, I don’t want to give the impression that you shouldn’t ask for such a feature! I’m more just not quite seeing how important it is, and wondering if more detail and specifics on the problems with the existing solutions might help me better understand and perhaps even upvote it myself. 
Interesting comments @Oshyan. Thanks for sharing them.
The question in my mind is, is it desirable to reduce complexity for a user? What value do we place on that? For me, the value of that is high.
One the the biggest challenges I’ve found in rolling out Fibery is having things that seem to be quite simple to me, be understood and followed by our non-tech users. This is not only initially, in the learning phase, but also when trying to find things in Fibery and manage work in general.
So I start with the premise that one of the main goals of software development is to hide complexity from the user. This may not always be the ultimate goal, but it forms a nice premise in the context of this discussion.
So if we can agree that reducing complexity for a user, without hampering functionality, is a high value goal, as is anything that supports ease of clarity, conservation of human energy and respect for the limited amount of awareness people have with which to focus, then the only question left is whether this feature can achieve that outcome.
Work is often organic. Many times, work is not planned out first and then executed. It can start small and then grow. Prior to requiring multiple entities, many times a single entity will suffice and it’s surprising how far that can go and how much work a single entity can effectively hold. In instances where a single entity would suffice, if 6 people are collaborating and wish for their own workflows, using the task/sub-task solution would require 7 entities.
So the question then is a question of 1 entity versus 7. It’s simple to see and acknowledge that it is more complex to navigate 7 entities than 1.
Mouse clicks consume human energy. Navigating 1 entity requires far fewer mouse clicks than to navigate 7.
Multiply this across 100 such units of work and you have 700 entities to search through and deal with, rather than 100.
I think it’s fair to say that where structural requirements are met and all other elements remain equal, 1 entity is preferable to 7. Dealing with unnecessary complexity leaches human energy and creates focus-friction.
The chronological order of comments and other events matter. That is lost with the 7 entity task/sub-task solution.
A meaningful question might also be, from a user’s standpoint, what is the downside to implementing this solution? I have trouble conceptualizing one.
Oh I’m not arguing that it wouldn’t be beneficial. But of course, as I’m sure you know, dev time and other resources are limited. So I was just trying to better understand the details of your need and use case, as well as whether other existing approaches or less single-focus development work could meet enough of your needs to make a decent impact for your users. Understanding your need allows me to also decide whether it’s something I to need and therefore should support directly! 
Got it, thanks for your clarification @Oshyan.
I’m not sure how to add detail to the use case. It’s simply that any time an entity has more than one user assigned to it, the user isn’t able to have a workflow to organize and manage their own work.
If I am collaborating on a particular entity and I reach out to a graphic designer for a quote and I’m waiting to hear back from them, I want to be able to add a comment saying, “Requested quote” and then put that entity in a “Waiting On” column on my “Assigned to Me” board. I’m currently unable to do that without changing the state to Waiting On for all users, so I’m left with no Workflow available to me to manage my own work.
Quite often the entity workflow doesn’t get used much at all, as all it can do is sit in an In Progress state.
I simply want to be able to organize my work on my Assigned to Me board without affecting other users.
Hope that helps to clarify and I appreciate your input. 
Gotcha, yeah I think I understand. It just appears to be a difference of opinion/preference then, I think. Because reading your description of how you want it to work, I actually feel very differently from you and would prefer for my own parts of the work to be in separate tasks/dedicated entities, and related back to a parent. 
What you’re describing sounds kind of unconventional to me, but it may well be a feature of other tools I’m not aware of. But in any case it appears to just not be a way of working that “clicks” for me. I hope you find an approach that feels comfortable for you and your team, whether with existing functionality, or changes the Fibery team makes.
After reading this discussion (with interest) I find myself able to see pros and cons for the various approaches/mental models being articulated.
Putting aside any tool being used, I do think that it actually seems reasonable to assume that if a task needs to be at different stages for different people, then it must implicitly consist of separate subtasks (be they parallel or sequential).
However, the separation of these subtasks as different ‘things’ (I’m avoiding using the word ‘entity’ to keep my thinking tool-agnostic) will lead to fragmentation, resulting in a loss of insight/coherence between them, as well as introducing extra work (mental and physical).
I don’t think there is a simple solution, but given how strong Fibery is/can be in terms of connectivity, it feels like it might be wise to choose to reap the value that comes from sub-dividing a task (separate workflows, and maybe more) so long as there is some clever, behind-the-scenes magic that maintains coherence, and minimises friction.
I haven’t yet worked out how best to do this, and different solutions are probably needed for different use cases, but off the top of my head, I could think of a few things to consider:
A ‘Split into subtasks’ button, that creates set of sub-tasks (one per assignee) or maybe a ‘Spawn subtask’ that creates a single, new subtask for the button presser.
Alternatively, a ‘Divide task’ that converts one task into many (resulting in peer tasks without parents).
Note: on a tangent, it might be worth thinking about whether there needs to be consideration of dependencies (i e. Does subtask A block subtask b?)
The key of course is to maintain some kind of relationship between the original and all the new (sub-)tasks. As long as relations exist, (sub-)tasks could have an automatic synchronisation mechanism, so that edits to relevant fields (e.g. rich text, status, comments, etc.) are reflected/aggregated where necessary in the parent/peer tasks.
Maybe the related tasks also need to have a rich-text field (+ others?) that is not to be synchronised?
Also, potentially there need to be buttons/automations to re-combine tasks if/when the division is no longer necessary.
Anyway, this is just mental spitballing, and some bits of this are harder to implement in Fibery right now than others, but I’m very happy to gather more feedback and even experiment with trying out ideas.
FWIW, the final implementation of ‘blocks’ will probably support ‘transclusion’ type behaviours, so I am quietly optimistic that the maintenance of coherence between objects will get easier and easier over time 
This. 100% this. I was basically trying to articulate a similar view, but perhaps not doing it as succinctly or clearly. My hope is that the seemingly-logical (to me) splitting of tasks into separately tracked things can be done but avoid most of the downsides: keep it intuitive, reflect changes into a parent entity, and perhaps at the end roll it all up into the parent entity (destroy children but preserve work notes back into parent somehow). A fuller articulation of the downsides of the splitting approach would help inform possible solutions.
As one example of a know problem here, getting comments together in one place seems interesting to think about. I don’t know that the contents of Comment Fields can be operated on in formulae at present, likewise Rich Text. But I can imagine something like concatenating all Comments from Child Entities into a single Rich Text, with e.g. labeling and dates for each, so you’d have a single Comments stream but still have it delineated what is what. I previously proposed a “Conversation Field/View” and some interesting discussion resulted. If such a view existed, it would be ideal to be able to pass it “messages” via scripting, so that you could end up with a nicely formatted and consistent result for a situation like this. Likewise just spitballing here. 
Twist is a direct messaging app that competes with Slack in the marketplace.
They’ve managed to carve out a nice niche and provide a solid product that solves one of the main issues many people have with Slack and other direct messaging platforms; that being getting caught up in the midst of immediate chat communications and not keeping things clean, organized and structured.
I believe that Twist’s main competitive advantage, setting them apart from all other direct messaging platforms, is the implementation of the feature I’m requesting in this thread.
Each user in Twist is able to have their own independent state on the same chat thread in their Inbox.
One user can have the thread as “Active” while another has it as “Done.” So simple, yet so powerful.
This isn’t possible in Slack. In Slack, each user can’t have a state on a threaded discussion. This makes it far more difficult for users to organize and manage chat threads effectively.
I thought to share this here, as I really do believe this feature has many advantages.
Another product that offers assignee specific workflows.
Each task has its own workflow state and each user has their own workflow state for each task also.
So great for fast and easy collaboration on a single item.
Thanks for the heads up. Out of curiosity, is your personal use case covered by non-forking state transitions? i.e. an item can move forwards (or backwards) through a list of states - there are no choices to be made for the next state.
I just discovered this thread and you are actually talking about a few things I’ve mentioned before.
First, re: your original request:
I’m not sure if you exactly mean what it sounds like, but “each user getting an entity in a stage of a workflow” where the entity passes along to a specific user upon one completing a previous stage is typical for process management apps like Pipefy, and I think that would be great to have more built out in Fibery as well, per some earlier requests I’ve had:
Here though it sounds like you are simple requesting that each assignee can have their own state of an entity. I wanted to point this out as you mention the app Twist, and I have talked a lot about how some stuff in Twist - although not this feature - would be very useful around improving chats and comments, so I’m glad you mentioned it.
Here I talk about how Twist handles well some of @mdubakov 's vision for conversations in Fibery:
And a great feature of Twist I’ve requested is the ability to comment when you resolve or “close” an entity, it really gives context to what was actually done in an entity to finish it, instead of just clicking “done” and then leaving teammates guessing as to the final step to get something done:
Hope you might find some of that useful, thanks!
No. That doesn’t relate to our use case @Chr1sG.
When it comes to workflows, currently in Fibery, there is no way for assignees to manage their own relationship with an entity. Instead, they are forced into the same relationship as all other assignees.
If an entity has John, Stacey and Steve assigned to it, John, Stacey and Steve are all forced into matching workflow states. This is disconnected from the reality of work.
In reality, John might be “Waiting on” feedback from an outside source, while Steve has “Completed” his part and Stacey has hers “In progress”.
It’s easy to say, just create separate entities for each assignee and link them this way or that. This eliminates the ability to truly collaborate. It also doesn’t acknowledge the unnecessary complexity and disconnection that can cause to the work.
It means there is no longer a central entity with an easy to scan, chronological order of activity. It means there is no real collaboration on an entity, but rather, isolated silos of work. The work becomes more disconnected, rather than more centralized, easily visible and more connected.
The ability to have an assignee specific workflow means that everyone can be more connected, they can work together in the same place, rather than separately. Everything becomes simpler and more centralized. There’s only one place to look, rather than 3.
I hope that helps to clarify.