I need a flow that sends emails to customers currently in open stage of order fulfillment. But not all such, only those that have purchased a certain product variant - of which there are a few.
I ran into trouble running queries on the Advanced edit query panel - while it looks like I can put in selectors on any of the fields like tags on the order or customer, the query fails to select and returns all orders in fulfillment. I can narrow it to just open ones, but that still more than I am targeting.
OK, so I did some digging, it seems that only a rare few fields can be utilized in that query - list is not published, it seems. But id: works, but orderId: doesn’t. Though the schema implies both are nodes at the same level.
So request #1 - where is documented what can be queried at the top level of this request? And the other types like this?
Alright - so now I have a collection of records that contains more than I need, and I can iterate over the set and do further matching on each record to select orders/customers to do more with. I can send an email. And I want to tag the order so next time the flow runs, I can avoid this customer, and find the new ones. But I can NOT sequence another action after the action customer email is sent - I have to do a selection iteration AGAIN to set tags.
So request #2 - what am I missing, as this severely obscures the logic, layout and efficiency of the flow. Is it just a feature not implemented to chain actions for matching items in a For Each… action?
Further observations -
During the extended experimenting to see what is going on with this query selection mystique, I find that while the record reports
“node”: {
“id”: “gid://shopify/FulfillmentOrder/7025209737409”,
“orderId”: “gid://shopify/Order/6099500269761”,
“orderName”: “#3926”
}
for one of the matching results, and if I specify a query
fulfillmentOrders( first: 20 query: “id:7025209737409 OR id:6967990485185” )
it finds those records, and returns only two.
But if I search for “gid://shopify/FulfillmentOrder/7025209737409” it doesn’t find it. (I suspect the record holds just the GID, and it is pretty printed for the GUI with context.)
Further, according to the Doc, if I do something like “id:70*” it should be doing a partial string match, which it doesn’t do - again, probably a feature of the DB itself that treat GID’s as pure objects for which partial matches is meaningless.
Also, the query syntax docs say that just giving a name or string will match for anything in the record. Nuh-ah. It won’t match a GID against such a string, it seems. So the string search for matches in queries, at least for this fulfillmentOrders request is inoperative.
And to drive this home - the result fragment shown above shows both the “id” “orderId” and “orderName” at the top level in the node returned, but only the id is searchable/selectable in the query. If I try to select on orderName ONLY I get a
“warnings”: [
{
“field”: “orderName”,
“message”: “Invalid search field for this query.”
}
but if I OR that with valid id: terms it finds the two (in my test case) but does not warn about the orderName term. Again, probably due to lazy eval - if an OR term fails it doesn’t need to impact the result, but if the failing term is the only term, it propagates back as a warning/error.
Oh, and also, if I try to use orderId:, which is a GID, it also fails like orderName. I thought just perhaps some interior fields are more special than other, but alas, no.
So I think I have a clunky, very spaghetti-like flow that repeats the same iteration over the returned set to filter out what I could specify and select for in the query in the first place.
But I would love for #1 to be resolved at the query level, and #2 for the chaining of actions after iterations so I don’t have to replicate such.
Thanks for reading this. I can show specific screen shots or code snaps if more info is needed.
|\/|ark
