Setting an Option on Backend using Text on Front End

Tips
1

Hi there,

I encountered this today, and once I figured it out felt compelled to share how I got this to work. Admittedly backend workflows are my current weakness in Bubble, so I usually have to do a bit of tire kicking to get them to work like I hoped.

The context: I have a backend custom event, with fields for Ingredient (data-type), Qty (number), Unit (option set), and name (text). On the API workflow to trigger it, I have these fields mapped to each item on a list of text. On the front end, when I was trying to trigger the backend workflow on a repeating group of type text, I could not get the filtering to work on my Unit option to find/convert text to Option (even though this works in other front-end event based workflows, and even works for datatypes, as evidenced by the ‘Search for Ingredients’. Filtered is where I would choose 'This Option Set’s Display is This Text: split by(III):item #3. As you can see in my screenshot in the List filter window, ‘This Text’ would not show up:

image
image724×625 53.3 KB

I ended up solving this by going to the Backend Custom state, where I changed the parameter of Unit to type Text (instead of type Unit):
image

and then in the step on that custom workflow to create a new thing, is where I applied the filter ‘This Unit’s Display is Unit’:

image
image946×678 51.9 KB

This is where that conversion now happens from Text to Option. Now on the front end, I have no problem just referencing ‘This Text:Split by(III):Item #3’ as it is now type text, and then converted in the backend workflow.

Final result on the front end workflow (look at ‘Unit’)

image
image339×677 34.9 KB

I hope this tip helps someone else!

2 Likes
2

Was it not possible on the front end to setup the original schedule api call action where an option was possible to say in the constraint This units' display is this text split by

sometimes when I encounter issues with setting a constraint for filtering an option set I just need to reverse the way the constraint is setup when comparing the two data points (ie: instead of starting with ‘this text’ start with ‘this unit’ and instead of comparing against ‘this unit’ compare against ‘this text’)

After writing this I went to check against the concept in an app and see that in fact the ‘this text’ is not available no matter which way the constraint is constructed, which to me is a BUG. They recently revamped the schedule backend workflows on a list and likely was an oversight on ensuring the appropriate data sources are available.

It seems to affect only constraints for filtering option sets as it doesn’t affect data types constraints…likely there might have been a slight technical challenge when an option set filter needs to reference ‘this option’ and the backend workflows on a list needs to use ‘this thing’ as well, as the similar syntax might have thrown engineers off?

I submitted a bug report…thanks for sharing the work around.

1 Like
3

Oh I tried many many different ways :rofl: that’s why ultimately I wrote this post because I couldnt get it to work otherwise.