Invitation to users wanting improved workflows

[Chr1sG]

We know that the current workflow implementation is simplistic, and given that there are quite a few topics here that relate to workflows, e.g.

Proper workflow: States, Transitions, etc

Workflow should consist of States and Transitions. States have Transitions. Transitions have Guards (conditions and permissions) and target States. Transitions can be triggered via a user action (e.g. button) if they have the required permission, or automatically if the condition formula is true. A Role has Permissions on an entity based on the State of the entity. Groups can have roles. Users can have roles, and they can belong to groups (inheriting the roles of the group).

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…

Conditional Buttons to transition entities through states

I wasn’t sure if this is should be a question to the community about use of buttons, or a feature request, but what I wanted to talk about was using buttons as a means to easily transition through States. This is a great feature of Jira, and some other tools. What I’d really like to see is to be able to set up workflows so that you are only allowed to move to a certain state if conditions of the current state are met, such as a field that requires a result of a software test, is filled. Also,…

…it seems like there are plenty users who would like more sophistication.

Without making any promises, I would like to invite users to get in touch if they have specific use cases in mind that cannot currently be achieved in Fibery.
This may allow us to develop templates that might be useful, as well as helping us understand what functions/features deserve the highest priority for any ‘native’ implementation.

If you’re interested, and have time, please DM me and we can arrange to chat through your needs.

[Yuri_BC]

Thank you! Just wondering of the coming upgrade of the permissions system will include to assign permissions to change workflow states?

[Chr1sG]

The current ‘contributor’ level of permission allows users to have different access depending on whether they are assigned or not, so it is already possible to create workflow setups that allow you to dynamically control who can manipulate an entity based on it’s state.
For example, you can write an automation that updates the assignee field based on a state change, and then users who are ‘contributors’ will be enabled/disabled accordingly.

The new permissions model will be at least as powerful as the current one.

[njyo]

+1 on the conditional buttons to support more workflows

[CDPK]

For us a concrete workflow would be one where we cover both logistics and troubleshooting/returns on a device. I.e. a device can only be in one state, but both are separate flows. (e.g.: logistics: setup → prep → registered → shipped; troubleshooting: return request → incoming → in review → repaired.)

Abstractly its the modelling of multiple exclusive statemachines/flows in a single field.

[Chr1sG]

@CDPK

multiple exclusive statemachines/flows in a single field.

In your example, is it not satisfied with a single state machine that looks like this:
setup → prep → registered → shipped → return request → incoming → in review → repaired → shipped
(where the second ‘shipped’ indicates re-entering the flow at the point of the first one, meaning that the troubleshooting states are just basically an optional loop)
?

[CDPK]

Well it depends, in our use case any issue on setup / prior to delivery for client could bump the device to the service inbox. So it’s not just a single transition, and the more complex the flow, the more this can happen.

A lot can be covered if we could specify transitions in the workflow.