Today we’ve made a new template available which demonstrates how to achieve some cool advanced workflow functionality, including controlling what state transitions are possible, and who can make a change.
Why not give it a try, figure out how it works, and let us know what you think.
Is it useful? How could it be improved?
Maybe this kind of functionality should become native to Fibery?
When I read through the section about adapting this to an existing DB, my thought was, “wouldn’t it be cool if we could automate this process of customizing/adapting a Template?”
Perhaps we already can via the API, though ideally this would start with a Form that prompts the user to select the relevant options (like which DB to add it to, a set of State names, etc).
What’s missing is the ability for scripts to create and modify automations (including scripts), plus ideally a more sophisticated “Form” capability that would allow a script to interact with the user in more complex ways (i.e., keep the form open while the script runs, and let the script update/change the form).
I came this close to writing scripts that would automatically create all the necessary bits to apply the workflow to any database in the workspace, but the missing piece is the automations, as you correctly identified.
Just to check, do you need a workflow to contain states that require input from more than one (category of) person in order to progress (and where the order of these people’s input does not matter)?
Or, do you really need the workflow to fork into independent branches, which may later merge into one again?
So in the first type, imagine a situation where an item can go from state A to state B when any one person in group X (the people with permission) triggers the transition, but it can’t go from state B to state C unless one person from group Y and one person from group Z confirm the transition, and maybe the same requirements again for C-> D.
For the second type, the states are A, B, C1, D1, C2, D2, E such that 1 and 2 represent two independent ‘tracks’ and the item could potentially move more quickly through track 1 (A->B->C1->D1) than it does through track 2 (A->B->C2).
Without experimenting, my gut feeling is that the former will be easier to implement the former version, but perhaps you do need the possibility for progress on one track to race ahead of the other.
For the case that I originally had in mind, your first suggestion should be enough. Although it would be interesting to be able to easily see which groups have already given permission to advance and which haven’t, in order to clear out the appropriate views when items have been processed by those concerned.
Your second suggestion is very interesting though, and makes me think that for our use case, being able to determine which workflow a certain item has to go through based on certain conditions would be super helpful.
We already have a “work type” field, which is based on the user group of the person to which the task has been assigned to. For example, an artist’s task is tagged as and “Art” task. If, based on that information, the task could be set to go through a particular workflow, it would enable us to create more detailed workflows depending on the type of work.
I’ll try and see if I can generate a template to show how you could do multi-role approvals, but before I do, I have a hypothetical example, and am curious to know what behaviour you might expect:
An item can go through states A → B → C.
There are three groups: Developers, Quality and Management
Only Developers can move an item from A to B. Moving from B to C requires a Quality person and a Manager.
The team members are as follows:
So obviously, only Alice and Carol can move an item from A to B, but what happens if Bob tries to move an item from B to C?
Does his dual membership mean that he can do it, or does he require Dan or Erin’s help?
In other words, is it only the roles/responsibilities that matter, or does there need to be a minimum number of approvers (= 2)?
That’s a tough one. I would say that logically, Bob should absolutely be able to move the item from b to C on his own. For clarity’s sake though, it would be helpful if the process was made in two steps in that case.
My guess is that having buttons appear contextually instead of a generic “move” button would be the best way to solve this.
Another possible workaround could be simply having multiple buttons shown only in certain views so that Bob would have to look at 2 different views to click them both.
My thinking was to try and reduce the “waiting” time of an item as much as possible, especially for actions that aren’t simple approval steps. If 2 actions can be done simultaneously but achieving those actions takes a while, it would be rather inefficient not to perform them all at once.
I’ve done a little experimental space in which the Transitions between States have associated Conditions. Each Condition required approval by a member of a specific Group.
If a Transition requires more than one Condition, then it is possible that a User, who is a member of more than one Group may be able to make the Transition happen, but needs to consciously choose to approve all the Conditions.
Anyway, please have a look, try installing it, and let us know what you think.
The system with entity transitions and entity conditions is a bit convoluted, which makes it hard to display cleanly.
The only usable view is a list view, which is pretty limiting. We usually prefer working with Boards to better visualize the state of a project at a glance. I’ve tried creating boards without success. I’m not sure such a workflow could be viable for us at this point without reengineering all of our views, which would come at a significant cost in terms of employee training.
A possible solution for this would be to find out how to transfer the buttons to the Items and by making them appear contextually. This would simplify interaction by reducing clutter and unneeded clicks. Although I’m not sure that’s possible, I feel it’s the only way this system wouldn’t become overbearing to use on a day to day basis.
Side notes :
All buttons are named “Approved” even for rejection transitions, which is sure to be confusing for a lot of people I’ve renamed the button “Trigger” for now but having a different button for different transitions would be clearer for sure.
It’s not possible to easily cancel a button press in case of a misclick.
New Items don’t receive a default state at the moment, (Easily fixable with an automation.)
Wouldn’t that be possible with the upcoming block views? From my understanding, you can add view “blocks” to entitites and could display a table-view of another database/entity including buttons? Maybe I have misunderstood the incoming block functionality.
99% this won’t be possible (at least for the time being) but ideally you could resize and align blocks however you want (scrollable in case your preferred size is smaller than its content).
In that case you could put your board view inside a block, and add another vertical block right next to it, showing a board view of related entity containing just the buttons.
Sure, not the same as having the buttons on the card, but right next to them would work too I guess.
Just sharing ideas