Workflow Extension Enhancements for Advanced Dev Teams

Hi guys,

I really like the fact that in this early phase of Fibery, we already have a concept of “Workflow”, thanks to the extension, that has some nice handling that you don’t see in other Nocode, where generally you have to use a single-select Property in a Field to get Workflow. In Fibery we have an element of Conditional Formatting already built in if you think about it with “done” items both “graying out” on boards, and showing as “strikethrough” when referenced - terrific work with those both guys my team lives by those features of Workflow!

Since we already have Workflow started with this specialized Extension, I’m hoping we can see this evolve with some more additions in the extension that would help Advanced Dev Teams in particular, here are some from this list:

  • More complex transitions. This is a key feature of Jira, and I believe TargetProcess, which are dedicated apps for development. So you can design which State can be chosen from a given state, multiple paths, etc. It looks like this in Jira:

  • Workflow Buttons for quick transitions. Sometimes when working quickly it is very nice to have the ability to just “push a button” to move to the next State, or back into a previous State. Jira also has this , and it’s very useful:

There are also some good posts around the community with some suggestions here:

Finally, @mdubakov described some great capability for Kanban that I hope will come soon, it’s laid out here:

This type of sophisticated Workflow I suppose could be integrated into the Workflow Extension, or it would just be great to see that feature on matter where it resides.

Thanks!

1 Like

I think this proposal is quite important for users with more complex workflows so I thought it is worth a bump for others to consider (unfortunately I’ve ran out of votes).

I also wanted to add something this is related and hopefully a bit easier to implement. If we think it deserves its own separate thread, I’m happy to move it.

I like the current state extension and find the UI and icons to be quite intuitive. However, I think @Dimitri_S excellent suggestion on providing some additional state super-types other than “final” would really enhance things:

@Polina_Zenevich suggested using “Final” for cancelled/rejected/closed states which technically works. But from a semantic and UI perspective, it might be better if you could mark these state conditions more consistently (i.e. these situations would be shown with an :x: rather than a :heavy_check_mark:).

I don’t think the “final” state suggestion works for moving things into a backlog. Having backlog as the first state is a possible fix, but that messes with the progress “pie-chart” for rest of states which are truly the first steps in a workflow (e.g. Intake, Proposal, etc.). So it would be amazing to have a backlog as another state type with its own logo (e.g. :hourglass:)

To sum up, per @Dimitri_S proposal, I think three super-states should capture most situation:

  • :hourglass: Backlog: items that are backlogged or otherwise delayed and no immediate action is going to be taken
  • :x: Closed: items that are rejected, cancelled or no longer active/closed
  • :heavy_check_mark: Final: items that are complete

I know that you can chose your own icons and colours for each state. But I think that actually becomes confusing as the extension icons also appear. I also don’t want to do away with the progress icons because I prefer Fibery figuring out the steps in between rather than trying to find emoji’s for each step.

1 Like

I actually think it is sub-optimal to have the workflow states (or superstates) too strictly pre-defined, given that there could be just as many preferences as there are users :slight_smile:
As an example, my preference for workflow states is sometimes Draft - Under Review - Reviewed - Approved - Obsolete and at other times is Pending - In Progress - Done.
I would rather have the option to choose names/icons/colours and fallback values if no choices are made.
And in a perfect world, each user could define their own workflow templates that can be chosen from for each type.
There’s a related discussion here:

And here: