Hi,
Can someone please explain why this isn’t doable?
Here you can see that the current item that the list is running on is available in the drop down.
But when I try to filter a list, you can see that the same option isn’t available (the red circle is what I’ve clicked on to pull up the list filter page):
I know I can get this same thing done with a backend workflow but I’ve tried that and it is being really finicky as my capacity is getting hit and it just doesn’t want to seem to run the API workflow. So I’d like to accomplish this on my end.
Basically what I’m trying to do is populate a new field (Experience - OS where this field is of an option set type) with a value from another field called experience. When I initially created this datatype, the experience field was just a number then I wanted to update it to an option set so I added teh option set field (Experience - OS) and want to choose the correct option to populate by filtering the list of options based on the value in the Experience field.
Yah but that doesn’t work either as on one side of the “intersects with” i have the option set and on the other side I have a number so the datatypes aren’t the same
Seems like once you do the :filtered operator it loses context of what Team member new it is…
Are you sure you don’t want to move this to the backend? You can run a recursive workflow so it loops through making the change to each user. Maybe your previous setup cause hitting capacity too hard? With recursive there’s kind of a built-in delay between each loop (and you can add more seconds) so it’s easier on your capacity.
I really only use the “Make changes to a list of things” action to make the same change to multiple things, here it seems like each team member needs their own “conversion” from their current number to experience level?
Also is this just a one time thing because you’re changing database structure? You can make the backend workflow and run it from your Data tab (probably hits your capacity pretty hard)
Hi Tyler,
I had tried it on the backend and I was thinking it wasn’t working but I didn’t realize I wasn’t accounting for something combined with hitting capacity. I had found that when you hit capacity, it can be a little bit finicky trying to get it back up and running agin. Given I can get this to work on the backend now that I’m not being dumb anymore, I will be running it there.
Your assumption is correct. The correct thing is to run this from the backend.
Yes this is a one time thing. I’m not aware of being able to run a backend workflow from the data tab. I just took a look and didn’t see anything and did a quick google and nothing really popped up. Can you direct me to where this is? Also, is running it this way less hard on my capacity then scheduling the backend workflow? I would have assumed both have the same impact on capacity.
Hi there, @paul29… I might not have understood your post correctly, but if I did, would it work to run the workflow for one option at a time? So, search for team member’s who have a specific number and assign the corresponding option from the option set. Then, change the workflow to search for a different set of team members and assign the appropriate option to them, and so on.
If you go to the App data tab, pick your datatype , on the right there is a Bulk button, you can pick one of your backend workflows and it will run that workflow on each individual item.
So in your case you would make your workflow with one parameter being the same type as your data type you want to “convert” and inside the workflow have it do all the translating from number to option set.
I think it hit’s capacity pretty hard if it’s running for a long time… how many items would it need to run on?
Otherwise yea recursive would be good and won’t randomly give up if your capacity hits the max. If time isn’t an issue and you can let it process a huge list for a few minutes maybe that’s the way to go
Hi Mike,
Thanks for your help. Yes I think that would work except my dataset is 8,000 team members long so is a bit intensive. Given that I figured out what stupid mistake I was doing wrong before, I can handle this on the backend workflow.
Did you figure it out with @doug.burden 's method? I was referring to a recursive workflow where you send it a list and it loops through each item individually and makes the changes. I can make an example if it’s not solved yet
The first backend workflow would be scheduled from the client, that one schedules the 2nd workflow and send the list of users to be processed (a search for all users in this case)
So the next time it runs the NEW first item is the next item in the list and the list is getting shorter and short every time. The conditional is there so it only runs when there’s more things in the list to process. Otherwise it makes an infinite loop if that condition isn’t there.
It’s easy on your capacity if you’re fine with letting this run for a few minutes because on the scheduling of itself step, you can add a few seconds to "space out "the processing. (This can be sped up a lot to do a lot of changes at once but it uses more capacity of course)
In your case the “Make changes to User” the change you would be making is looking for the option set with the same # value as This User’s [number field]
Sorry for the delay in getting back to you. I’m super busy with a project I’m trying to finalize. I will take a look at this this weekend. Thanks so much for the help.
