Or is it possible for me to store an array of the `campaign_id`’s that my `dynamic` dropdown provided to the end-user to cross-reference in the `perform` function?  That might be the easiest thing to do, just not sure how I would be able to store values found from a `trigger` perform to be later referenced in a separate `create` perform?

Hey Chris, to the best of my knowledge, there’s no such origination source property that will explicitly say whether an input field was mapped using a dropdown choice or if it was mapped as a custom value (the output of a previous step). 

However, there are two options that might be worth exploring. 

First, you can check the field’s value in bundle.inputDataRaw:

• If the input field was mapped using a dropdown choice, the dropdown value should be stored in bundle.inputDataRaw literally.
• If the field was mapped as a custom value (passed from a previous step), the value will be formatted as a “curly” reference to the previous step, like `{{stepID__previous_key}}`.

In this way, you may be able to only make the pre-flight call if the field’s value in bundle.inputDataRaw is formatted as a curly.

• One important caveat: there’s no distinction between values that have been chosen from the dropdown and those typed statically into the field. Both are stored in bundle.inputDataRaw in the same format.

Second, perhaps more of a supplementary option: If one doesn’t already exist, it can sometimes be helpful to add a similar search action. For example, if your API allows for finding a campaign by name, something like a “Find Campaign” action might let users pass campaign names into the search step, which would presumably return the corresponding id. That can sometimes allow for a bit more flexibility and increase the likelihood that a mapped custom value will be a valid one. That said, this may not make sense in certain cases and depends on what your API supports. 

Hi @chris_skipio !

It sounds like you’re trying to write your app to only make the action call if they’ve entered a valid ID into that step. Is that right?

First, I want to mention that the case where the user selected it from a dynamic drop-down itself wouldn’t prevent a bad ID from being in the step. Consider the case where the campaign was valid, the user selected it from a drop-down, but two months later the campaign is deleted or for some other reason the user doesn’t have access to it. In that case you would detect that they had selected it from a drop-down but the ID would still be invalid.

Instead of trying to manage every way an incorrect ID would go wrong, my suggestion would be for the API to reply with the appropriate 4xx code on an error and to handle raising that error message to the user using the error handling aspects of the platform.

If you want any clarification or have any other response, feel free to let me know. You can also get world-class help from our platform support team by contacting us while logged in at the developer contact form.

Yes your insight is correct @shalgrim, the 2nd API call will respond with the correct `4XX` codes if the Campaign no longer exists (or the user no longer has access to it); so I am successfully capturing this case regardless. The 1st pre-flight API call will also check for `4XX` codes, but is primarily used for when the Campaign is found but where it has the incorrect “type”. (Unfortunately the 2nd API call is asynchronous and isn’t able to tell the difference between a valid/invalid campaign type in-time to respond appropriately; I need to capture that error manually with the pre-flight request.)

Thank you @Zip Zorpler, your suggestions sound very promising; I’ll be checking out your first option to see how the `bundle.inputDataRaw` data differs from when the value is from a custom-input type vs select from the dropdown list. Your highlighted caveat might be a problem though as this won’t be fully reliable when the user types in the value  (though I imagine that would be a lower % of users doing that). I might just need to make the 2 API requests regardless until the API creates a synchronous endpoint that will check the type for me.

Your second option is also a good idea; I have attempted to add searching as a sort of filter to the dropdown results (so the user doesn’t need to keep clicking on “Load More” until they find what they’re looking for) but found that the dropdown is very basic and doesn’t allow for any `inputFields` for my API requests to use; however adding this search ability as a separate step didn’t occur to me and is something I’ll consider.

Based off of the research I’ve already done, I think your 2 options are the best available options to me. Thank you for taking time to share them with them.

Wait, haha I didn’t realize there was a place I could get support. Thank you for pointing this out @shalgrim ! I spent awhile trying to find out where I could ask this question and ended up posting here in this forum instead of on the deprecated Slack server.