Not-matrix products in Shopify have variant metafields, even though there are no 'variants' because it technically works off a default variant id.
In the matrix saved search from Netsuite to Shopify we can easily use the format shown here.
When trying to do that same thing in our non-matrix flow it does not work. We also know that we can specify our metafield components in the settings for the product flow and this would map data to a variant metafield, but this only works if you are using a normal Netsuite field not a custom field.
We have a custom field for inventory status and it looks at a list for the value. When mapping to Celigo using the specify metafield components setting we end up just getting the internal id of the field value, so 1, 2, 3 etc, not the actual value.
Is there a way to either get the non-matrix flow/saved search to recognize the variant metafield based on the link above (like it does in the matrix flow) OR get the actual value from the custom netsuite field and not just the internal id of the item on the list?
can you share the format you have your variant setup as in the saved search? And also can you share how you have it configured in the settings section, including the check box drop down like this:
Yeah we have set it to the one in your image. Variant metafields for simple item. But because the custom field is what we are pulling in, and that custom field is an option from a list, it is just pulling in the list id, which is just the index position. Here is how it is in the saved search, which I don't think even matters if we are adding it in the way that you are showing in the screenshot?
In the screenshot you posted we had it set
namespace: details
key: ns_inventory_status
Value: this was blank for one try, and for another try we set it to the field id in netsuite. first try nothing happened. Second try it just mapped the list id like I mentioned above.
Currently this is still what happens when pulling from a Netsuite field like a list, the internal id will still return. We were told that it is not supposed to operate that way and that a fix for it would be implemented. I think I remember them saying in July but I don't remember specifically.
So no, but it will work soon. Here is my solution for now.
Continue mapping the value via saved search. Celigo won't grab it but then the true value (not id) exists in your data and can be accessed.
in my mapping instead of just mapping the metafield values directly I put a {{#compare}} helper in it to check and see if it was one of the metafields I know has this issue. If it is, then I tell it to get the value from the field in step 1. If not just map the metafield (this way it doesn't break other fields that do work).
Yellow: The field with value 'Available' is the value I want and
comes from the saved search, but obviously doesn't work like normal. The field with '1' as the value is how it is actually coming through via the method above we have all tried that just returns the internal id.
Red: Red is the compare statement I have in the mapping. In this example it checks if the key is 'ns_inventory_status' and if so it returns the value from 'details:ns_inventory_status:value (Variant Meta)', else it returns the metafield value.
