Button formula: How to update a single-select field

Hi Fibery Team and Power Users,

How can I update a single-select field from within a button formula?

Example: App “User Research” (from the app templates) has a type “Insight” with a single-select field “Kind”. This field has four pick values: Observation, Opportunity, Pain, and Praise.

I want to add a button that updates the single-select field with a value calculated by a formula.

However, I cannot seem to find a valid formula that can pick one of the available values and update the field accordingly.

This thread suggests to add a value field to the single-select field type but I don’t see how this can help in my case.

Do I just fail to see the solution or is this not possible at all?


The following code seems like it should work, but it does not; it just sets the Single Select to empty.
(note: I am trying to select the option named “Notify” on my single-select field named “Action Type”):

1 Like

Thank you @Matt_Blais, I did not even get beyond formula errors before.

Maybe the Fibery team can advise whether the formula is still incomplete or whether the behavior is a bug.

I don’t think there is an easy way of doing it using formulas, currently.

In the code that @Matt_Blais provided, the [Step 1 Action].[Action Type].Entities part of the formula will return all entities that have the same value for the Action Type single-select as Step 1 Action.
i.e. if the Action Type for Step 1 Action is “Foobar” then this will return all Entities that are set to “Foobar”.
Using a filter with Name = "Notify" will always return an empty collection (unless Step 1 Action is already set to “Notify”!) so there is no First in the collection, and so nothing is returned.

I believe the only way to do it currently is by using a script, sorry :frowning:


Just letting you know that we are on our way to add support for this types of things in Formulas in Automations. Release of this new functionality will be in several weeks, I’m more or less sure. As Chris mentioned – only script until then, sorry.


So [Step 1 Action].[Action Type].Entities does not return Action Type entities as the syntax would suggest, but rather a list of Action entities?

Doesn’t sound logical to me but I guess I only misunderstand something here.

When I have some spare time I may dig into Fibery scripting but until then I guess I can live without the button I planned to build.

Thanks to all of you for your help!

A single-select field behaves like a relation (many-to-one) to a ‘special’ type.
So one or more entities of a ‘main’ type can be linked to a given single-select value (each of which is itself an entity of the ‘special’ type).

From the point of view of the main type, this relation field is called whatever the name of the single-select field is. From the point of view of the single-select ‘special’ type, this relation field (looking back to the main type) has the name ‘Entities’.

So [Step 1 Action].[Action Type].Entities is saying “Take the Action from Step 1, find the single Action Type it is linked to (i.e. the specific entity of the ‘special’ type), and then lookup all the Entities (of the ‘main’ type) that are linked to this Action Type.

In the diagram above, if the automation is run on Entity A, [Step 1 Action].[Action Type] will get you the ‘Open’ entity of the ‘special’ type, and [Step 1 Action].[Action Type].Entities will get you Entity A and Entity B of the main type.

If the automation is run on Entity C, [Step 1 Action].[Action Type] will get you the ‘In progress’ entity of the ‘special’ type, and [Step 1 Action].[Action Type].Entities will get you Entity C of the main type.


Thank you @Chr1sG for the detailed explanation.

TIL: “.Entities”, when applied to a single-select field, refers to the type containing the single-select field, and filters the collection based on the current value from Step 1.

That’s quite some semantics within a concise syntax but once knowing the basics it’s easier to decipher.

Thanks again for the help.

Not quite how I would summarise it :thinking:

Just to be clear, .Entities can be used in any formula (not just in an automation action step)
It will always return all Entities (of the containing type) which are associated with that specific single-select value.

And in the case of this automation example, the specific single-select value is whatever the value of the single-select is for the entity that triggered the automation.

I hope I’m not confusing things further(!)

1 Like

Understood, and no, this does not add confusion. Clearly, there is a context in a button action that does not exist in other formulas. The different behavior thus makes sense.

1 Like

A good way to visualise it (literally) is to actually open a single-select value (alt-click on its name) and you will see all its properties (colour, icon and linked entities).
Try it :slight_smile:


OP wants to use an automation to set the single-select field Insight of entity User Research to one of four values based on some number field X. This is precisely the issue i was wrestling with, as well.

In formula terms, i would like to do if( X>5, expr, [Step 1 Insight].Kind) where expr is Kind value “Observation”. So, if X > 5, set Kind to “Observation” else keep its current value. The conclusion is that this is not currently possible.

I can express this behaviour if i make Kind into an entity of its own, because then i can use Kinds.Filter(Name="Observation).Sort().First() for expr.

Why i am pressing this issue is because i want to be able to automate the changing of flags or statuses of entities. And i am able to, with the above expression. But i would prefer if i could just index into the related entity, e.g. Kinds, with Kinds.getPublicId(1) or Kinds[1] or Kinds[“Obeservation”] (the last one would require uniqueness constraints on Name strings).

Or, instead of enabling retrieval of entities by index, single-select fields should be just an array or a list, rather than a DB of its own, because then Kinds[n] would be a simple way to reference a value, and i would not have to clutter up my Spaces with dummy Entities to work around this issue.

Anyway, since there is a workaround, this feature is a just a nice-to-have, not a must-have.


It is possible, but only with scripting, at the moment.

1 Like

:wink: It is nice that scripting is an option, but it kind of goes against the grain of the no-code principle