Can I have more than one Workflow field in a Database?

Hi: I’m refining my project management app: I have a Task that already has a Workflow field “State”. I wanted to add another Workflow field: “Blocked” (which be auto-assigned via an automation). However I’ve just discovered that when I got add a Workflow field: it’s only available if the Database hasn’t already got a Workflow field: so I guess each Database can only have one Workflow field? Is that right? Is there a design constraint enforcing this behaviour?

I see a workaround could be to create a Single Select (“Blocked” and “Not Blocked”). However, I want to set the value of this field using a formula, and for the life of me I can’t figure out how to create a formula whose output is Single Select. (I can create a formula with Checkbox as output, but not Single Select.). Is this possible?

It’s true that there can only be one workflow, but the single-select workround suffices in most cases.
It might be possible to use filters in one or more automations to achieve the dynamic setting of a single-select value. It depends what you need to achieve.
Alternatively, you can dynamically set the single-select programmatically with a script.

Thanks: so is using a formula to set a single-select field a non-starter? ie. formulae can only create numbers, text, checkboxes, etc. but not single-selects?

I’ve got the formula working for a checkbox, but unfortunately I can’t use a checkbox as a column in a Board View: hence wanting to use a single-select instead. I guess I should back up a bit and say that my ultimate aim is to create a formula that I can use as a column in a Board View (of a Dataset that already has its Workflow slot filled up).

Hey Masp what are you trying to achieve that would require 2 workflows in a database? Maybe there is a different way to reach your objective?

I’ve got a Task Database: I’ve created a self-relation many:many Task<->Task which represents dependency (“Blocks” and reciprocal “Blocked By”): that works fine. Then I created a formula “Blocked” defined as:

If(([Blocked By].Count() = 0) or (State.Name = "Done"),false,[Blocked By].Filter((Blocked = true) or (State.Name != "Done")).Count() > 0)

which also works fine (any given non-Done Task shows as “Blocked” if it has a non-Done Task anywhere in its recursive list of dependents). (State is the existing Workflow field.) Now I’m just trying to figure out how to surface blocked Tasks: one way I thought about would be to make Blocked a different type (say a single-select) so that I could select Blocked as the column of a Board view. (But now that I come to describe this I realise this probably doesn’t make sense, because since Blocked is a formula, the Board view is inappropriate (you can’t manually change Blocked’s value)). So I guess maybe a checkbox is the best I can do!

BTW this brings up an issue I noticed a few days ago when I created another self-referential relation (in my Tag Database): if a Database has a self-referential relation which is 1:1 or 1:many then the List view and Smart Folder both provide a wonderfully useful feature: a small circular arrow icon will appear next to the Database, and if it’s selected then the list will recursively extend its hierarchy to follow the links defined by the relation, and the user can drag any entity to any new location in the (dynamic) hierarchy: it’s almost magically useful! Unfortunately, however: if the self-relation is many:1 or many:many (ie. each linked entity can have more than one ‘parent’) then the icon does not appear, and so you can’t create that fantastic recursive hierarchy in your view. (I assume the reason is that each entity could appear in multiple branches of the hierarchical tree, and that’s a use case that hasn’t been implemented.). It would be marvelous if that recursive hierarchy could also support many:1 and many:many self-relations: that would be the perfect UI for my current use case: it would allow a user to create dependencies (“Blocks” <-> “Blocked By”) simply by dragging an entity: but in in this case (due to the many:X nature of the relation) the drag would create a “copy” of the entity in the new location, rather than a “move”.

For example, the current (1:X) support might render like this:

  A
     B [ie. relation A->B]
        C [ie. relation B->C]
  D
     E [ie. relation D->E]
     F [ie. relation D->F]

and the user can use drag+drop to change F’s parent from D to B, ie:

  A
     B [ie. relation A->B]
        C [ie. relation B->C]
        F [ie. relation B->F]
  D
     E [ie. relation D->E]

If many:X support was added, then the user could use drag+drop to change give F a second parent: (B as well as D), ie:

  A
     B [ie. relation A->B]
        C [ie. relation B->C]
        F [ie. relation B->F]
  D
     E [ie. relation D->E]
     F [ie. relation D->F]

Ideally the user would also be able to modify this behaviour (perhaps option+drag?) to enforce a move (replace D with B as F’s parent).

Couldn’t you just create a table view with a filter for Blocked = true (and with the workflow column showing so that you can update any tasks as necessary)?

FWIW, I think you could probably simplify the formula to

(State.Name != "Done") or ([Blocked by].Filter(Blocked = true).Count() > 0)

1 Like

Perfect! (I think you actually referred me to this before, so apologies for not comprehending the relevance at the time!!). Any idea how long that feature is likely to take? I see development just started, so I would guess it’s a few months away?

You’re right: thanks!