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.
…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.
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.
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.
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)
?
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.
I have added https://fibery.io/templates/advanced-workflow to my Workspace, but can’t quite work out if what I would like to create is possible. These types of workflows are tricky to build without a graphical designer UI to help.
Building a general-purpose, open-ended flow system like this in Fibery is technically possible, but not really practical.
I have in fact done it, but it required so much complexity, abstraction, workarounds, compromises, etc. that I ended up with a system that was cumbersome, brittle and difficult to use.
While their interface and performance could be modernized , their process workflow implementation is excellent. We can visually see the entire process in a board like view, we can have conditional fields and conditional steps, required fields and automations to assign different owners depending on the task, as well as features to establish specific SLAs for each step.
I notice Fibery is making positive strides in this direction with recent feature releases like Custom Views, Required Fields, Groups, and Group Permissions. These additions create potential for:
Implementing step-specific views that adapt based on the process stage
Configuring different required fields for each workflow step
Automating team and individual assignments based on process stages
These capabilities would significantly enhance our workflow management, allowing for more structured and efficient processes while maintaining flexibility. It would be valuable to consider incorporating similar workflow capabilities into our community platform.
I haven’t read all replies but count me in as someone who thinks this needs immediate attention. I’ll be happy to provide feedback in any way needed. Just not too sure of what is wanted and where/with whom this should be done.
For those who are interested, it is possible to combine self-relations, required fields and dynamic relation filters to create workflows with constrained transitions.
To do so, you should create a database of states, and establish a many-to-many self relation, so that you can define for each state, the possible ‘next states’ (and by implication, the ‘previous states’).
Once this is set up, you can set up a relation filter on the state field so that the only suggested options are those states whose previous states includes the current state (i.e. show only the states which are the possible next states):
With this all done, whenever a user is selected a state, the options will be limited to the ‘next states’ as defined in your state database:
Feel free to set the icon for each entity in the state db to make things prettier
Point to note: relation filters only apply to changes made via the drop down, so if you have a board view with states as columns, there is no restriction on what states a user can drag and drop the items between.
, their process workflow implementation is excellent. We can visually see the entire process in a board like view, we can have conditional fields and conditional steps, required fields and automations to assign different owners depending on the task, as well as features to establish specific SLAs for each step.
