I wanted to suggest two additions to Workflow that would really help me out. Again would love to get feedback from the “regulars” of @Jean, @helloitse, @chris.burchartz, @ChrisSparkT, and anybody I forgot (no offense intended!)
Require comment on “close” status. Many of us are familiar with issue tracking tools like Jira, and this is a very useful feature. With this, you can make sure that closed entities that are being used for process management like Bug Tracking, Feature completion, etc. get a comment so the team can see what was done upon close. Simply you’d designate which state is one that requires a comment, and once that state is chosen, a modal would pop up requiring a comment before it can be closed.
Multiple “done” types of status. My main point here is that I’d like to distinguish in Fibery between things that get “done,” but perpetuate in the system. Like a software Feature. It is done, but it could later need an update, and it doesn’t go away. Or a client you first pursue, then close. The client is part of your userbase now and needs to be in the system.
However, tasks and other types of entities would well “disappear” from active items into an archive. So this is sort of a “2nd” done, or “closed” status, that has different use than the first type.
You might add this request as well as a 3rd addition to Workflow for the backlog!
Ok could you provide more detail Chris? What I was referring to was the ability to have multiple kinds of “done” entities that have different treatment. For example, if I have a set of vendors I work with, say CRM providers. I move to a new one from a previous provider. I’d like to have this one in a “done” status representing that it’s in use, and the old one would still be in Fibery as a “former” provider, but also “done” because it’s inactive. In the meantime I’m tracking projects and tasks in Fibery and they also get “done,” but I want to see them in different search results and reports vs my vendors you are inactive.
Let me know if that is indeed possible. For now all I thought you could do was mark multiple states as “done” but every “done” state has the same treatment in Fibery.
What I meant was that there can be more than one state which is ‘Finished’
and you can choose whether or not finished items show up in search.
So potentially, you can use the finished states for things that you are not typically wanting to work with so much in the future.
If something is in use, but in a ‘done’ state, you could have a Done state in the ‘started’ category:
And to make things better looking, you can always choose your own icons instead of the default ones.
Thanks for the response. Yes I was looking for multiple “done” states that would have different handling. I’ve seen this in other apps, notably Clickup. You are explaining what I already know - and unless I’m missing something, Fibery treats everything that is “done” the same. Granted there can be multiple done states within a workflow. With different names, icons, etc. But they will all be treated the same.
I’m guessing this is not something you guys are thinking about as there is not a lot of activity in this request, but technically since it doesn’t exist I feel like you can just leave this open and see if anybody ever shows up to support it. Our conversation right now will at least serve to make the request even clearer to any interested readers!
No I would like to have different types of “done/closed/finished” items. As I mentioned in my use case, we are tracking all kinds of things in Fibery and some of them would be useful to mark in a non-active state. To continue with my vendor example, this might be “no longer using.” I’d like to track other types of entities, like work, with a different type of “closed” status that is treated differently.
Here is the example of clickup I mentioned:
You see they have two groups in the workflow at the bottom, “done” and “closed”
Haha, yes that’s right! I realize this is going to be low priority for you guys, but I’m a huge fan of a workflow that can do a lot of various things within an app. The one in a version of TargetProcess I analyzed some years back, that I think @mdubakov may have actually been around to author, was fantastic. Glad we have a pretty good one already in Fibery. I just figured that I’d make sure this request was properly understood with the back and forth in here with you today :). Good chance I figure that this post might not get much further action, but I guess there could be others down the road interested in this!
What is the functional implication of the additional status category, e.g. of “Closed” vs. “Finished”? What do you do with it that you can’t do by just adding more options to the Finished category:
I’m not saying there isn’t a distinction, I’m just not clear on how you’re actually using/acting on these different statuses that doesn’t work with existing functionality in Fibery. Maybe I’m the dumb one now.
Yes, I think in general some of the more sophisticated handling of status and linking that I thought might be more on the roadmap when I created this post has become less of a priority in Fibery in favor of perhaps a more open design relying on automations or formula, and recently the interesting add of the Quick Filters. Here is more from that Clickup description explaining where “done” and not “closed” is used, that include some, but not all, of what would be useful to me:
With some build-out of those features I think multiple closed states would be logical and I could use them. Again to repeat my use case, I have a ton of stuff tracked in Fibery - vendors, equipment, company pillars, various work (tasks etc.) and some of these are going to have different behavior when “closed.” Finished work might need to be archived or otherwise not show up in search, whereas physical things I’m tracking like a law firm I’m currently using I’d like to have in a “final” state but one that keeps that entity more visible in my workspace.
Again this is surely a small item but something I’d find useful and is something I’ve seen in other apps that I’d live to have here.
Thanks for the detail @B_Sp ! I think some further clarification might be necessary though. I can understand the benefits of a distinction in types of Done statuses, but the extent to which you want that to affect things throughout the system, and the potential customization of that are where I run into concerns around implementability, etc. vs. the sort of existing approach of “If you want to do something special with a particular done status then handle it with automations, etc.”. For example if you want one type of Done to be handled differently in Search than another, that either has to be hard-coded (in a way that is useful to a good number of people, ideally the majority, which seems very difficult given Fibery’s flexibility), or you need to implement a doubtless very complex setup/configuration ability for different Done statuses where you individually define their relationship to Search, and other implications/effects.
So I remain a bit unclear on exactly what you would like here and how feasible it really is. If you were to put yourself in Fibery’s shoes and try to think of a version of your request that both meets the core/spirit of the request and is also implementable in a reasonable time and likely useful to a large number of the kinds of customers we know Fibery has and is marketing to… how would you describe that request in the most simple, bullet-point terms possible?
Sorry to repeat myself but my best answer is what you see in the Clickup explanation of their various “closed” statuses that I listed above. Yes, I realize some of this would involve hard-coding by Fibery which I’m not sure is viable right now depending on how much work the team wanted to put into the workflow extension. I made this request back when Fibery was new and it appeared at the time that extensions might become a core set of Fibery that got build outs, but that hasn’t happened. Not sure even if the notion of the “extension” is well known right now in the community…same with “collections” which once upon a time was how you referred to the area in an entity where relations showed up.
The main reason I jumped back in here is because of @ChrisG reviving this post with the comment 18 days ago. Since I’d still enjoy seeing this feature, I responded not quite understanding what Chris meant. I would like to add in the spirit of the original post, that right now with discussion of required fields over here:
than having the ability to require a comment on close seems like something that would also be closer to reality than when I originally posted the request. Again, at the time, my thinking as you could add on an “extension” that would force a comment when closing an entity - which in turn would need to integrate with some recognition of workflow moving to the one of the “closed” statuses.
