Hey @tpacun 

That post you have linked is indeed the best way to search by field A OR field B, allowing the user to pick one or the other, and then show the applicable dynamic dropdown. 

I am not quite sure if that is what you’re asking though - could you explain a little further what “allowing a user to match on the label” means?

In your screenshot, the user is going to be able to see the user-friendly label for that `id` and select the one that applies to them (eg. T-shirt) - then your API request on the back end uses the `id` to make the request. 

Hi @MarinaH,

Thanks for the reply!

By label, I mean the friendly name/label of the ID. For example, using the first item in that screenshot “T Shirt”, our API needs that ID - this all works fine if the user only ever needs to send information on that single item as it can be selected and essentially “hardcoded” into the Zap.

However, the other circumstance is if they were getting multiple names in that Zap and wanted to match on the name “T Shirt” or “Bar Spend” or “Example Merchandise” (as in the screenshot) but still of course then send the respective ID. That’s the case I’m asking about - is just setting it up with searching via different options or a separate action going to be required?

No problem if that’s really the only way - was just wondering if there is something I’m missing? Perhaps an easer option that already exists in the UI? I did try with the Custom option as in the screenshot but that just sent through the user-friendly name.

Hi @tpacun,

Ah, I see, so the trigger or prior action could provide the value  “T Shirt” or “Bar Spend” or “Example Merchandise” for example, and you want to be able to send the applicable ID in the action. 

A few ideas here, for the Zap itself - I’m not thinking of an easy way for you to handle this on the back end in the code of the action since every user presumably has unique merchandise item names

1. Use a Lookup Table step in the Zap where the value T-shirt is converted into the id - this is challenging for the user unless they can easily access those IDs in your app’s UI c=to create their Lookup Table
    
2. Use Paths in the Zap to branch the Zap depending on whether the label is “T Shirt” or “Bar Spend” or “Example Merchandise”, with the applicable selection in each Path’s dynamic dropdown. 

Using the `Custom` option from the screenshot would require you to input the `id`; typing the name would not do anything other than what you’ve noticed - sending the name through to your API. So only if the triggering app or prior action had access to those ids, would mapping a value into the Custom section work.

I’ve only seen this in particular use cases and I’m not sure if those apply to your app. An example is if the prior action is a `Find Record` that searches your API for the `id` that matches the name T-shirt (which requires your app to have an endpoint that allows for searching by name); then the following action `Update Record` can have that `id` mapped into the Custom tab. That concept is explained for users here: https://help.zapier.com/hc/en-us/articles/8496241696141-Add-custom-values-to-dropdown-menu-fields-in-Zaps

If you’d like to take a closer look at the outputs and particulars of your API for further suggestions, please open a ticket with us from https://developer.zapier.com/contact so we can look the details of your setup together. 

Thanks @MarinaH! It does all work with the Action essentially hitting the API for a list of the items every time it gets run but that’s obviously a lot of redundancy. That all said, our integration is still private and being developed...and I think we’ve decided that this level of item specificity isn’t required at this time.

In terms of the other information (just for anybody else who ever reads this thread later on) I did give the Lookup table a shot - if it could accept a set of line items for both the key and value and create a pair for each - but as you noted it would need to be more of a manual process there.

I did think that you could also set this up with Tables as well if necessary and use that as a cache of information, either by getting a list of the items at the beginning of the Zap via a general search action, or by having a separate Zap that is triggered by a webhook fired by the API when changes to the list of items occurs...which then adds that info to the table.

Anyhow, thanks for the information and confirmation - all well thought out and makes sense!

@MarinaH also whoops - meant to mark yours as best answer and accidentally clicked my own 

Those are great options to suggest as well @tpacun - nice work