New template - Advanced workflow

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?

3 Likes

Nice! :+1:

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?” :smiley:

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).

1 Like

Indeed.
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.

2 Likes

Hi Chris, nice work! I’m eager to test it out.

Do you know if it’s theoretically possible to track multiple worlflow states at once?
For example if a task has to be validated by multiple people in order to progress, the workflow could be :

To do → In Progress → Dept 1 validation → Validated → Approved
_____________________ :arrow_lower_right: Dept 2 validation → Validated :arrow_upper_right:

Hi @Dominic,

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:

Developers Quality Management
Alice Bob Bob
Carol Dan Erin

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)?

1 Like

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.

In that case, why not just have A → B1 → B2 → C

where Developers can move from A to B1, Quality can moved from B1 to B2, and Management can move from B2 to C?

Or is it important that you have the flexibility for Quality and Management to approve in any order?

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 would love to see this functionality native!

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.

https://workflow.fibery.io/@public/Multi_approval

4 Likes

Amazing! I’ll test it out asap.

After testing, here are our comments :

  • It works :smiley:!

  • 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 :slightly_smiling_face: 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.)
1 Like

You could create a board view that shows the Items as well as the Conditions, so that it would look like this:

It requires that you add a formula field (called State) to the Entity Condition:
image

Indeed, there are situations where I would love to be able to show the buttons of related entities on any given entity’s card. I don’t think this is likely to happen very soon unfortunately though.

Yeah, the name (label) for a button would ideally be determined by a formula, but for the time being, only hard-coded values are possible.

It is an option for admins to update the State value (not the read-only field) of an Item if necessary, and/or remove a User from an Entity Condition if that needs to be undone.

Yep, I forgot that. I’ll add to the template.

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.

Possibly, yes, but this wouldn’t help on a board view where you want to show Items as cards, but want the buttons from related entities to be shown on these cards

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 :sweat_smile:

1 Like

Creating a good, flexible page/interface designer is a big challenge. But I’m hopeful that we do one day get Notion-like, easy to setup sort of column-based side-by-side content, at least.

3 Likes

Thanks for taking the time to look into this Chris, I also hope our feedback was useful to you.

I’ll perform the changes you suggested and see if we can get some use out of this template. I’ll be sure to let you know if we have additional notes or suggestions then :slight_smile: