During the recent migration of Shopify-NetSuite product flows, I was unable to find an option to map the "Track Inventory" setting in Shopify. Upon reviewing Shopify's GraphQL productSet mutation, I noticed the fields "tracksInventory" at the product level and "tracked" at the product variant level (products > variants > inventoryItem).
I attempted to include these fields in the product flow, but encountered an error stating that the productSet mutation contains invalid fields.
Could you please assist me in mapping Shopify's "Track Inventory" correctly in the integration flow ?
Are you referring to the old "inventory_policy" value from the REST API? The one correlated to the "Shopify Do Not Track Inventory" value from the NetSuite item? If so, no mapping is required, the IA makes a separate API call to handle this. However, your NetSuite saved search results needs to have that value with the correct formula and custom label:
Field: Formula (Text)
Formula: CASE {custitem_celigo_shopify_dont_track_inv} WHEN 'T' THEN null ELSE 'shopify' END
Custom Label: Shopify Do Not Track Inventory (Variant)
If this is set up correctly, the flow will still update the "Track inventory" box in Shopify according to what's selected in NetSuite.
Our current Saved Search has this formula set in this method for the REST API, however, it does not recognize it with the new GraphQL format we will be switching to. I notice that the "required" fields in the KB article for migration show "no mapping required," so how do we ensure this feature functions as expected when serving variants in Shopify?
Hey Gabe, you don't need a mapping in the flow for this at all. As long as the items in NS have the corresponding value selected for the "Do not track inventory" checkbox, and the saved search returns either "null" or "shopify," the IA will update this in a script that runs when the flow runs.
It took us two weeks of troubleshooting with their support before they could get the tracked inventory setting to work at all for us. It seems they have chosen to run scripts in the background to handle graphql changes in mapping instead of allowing the user to just update the mapping to what graphql now needs. It is frustrating that they took so long to get us an answer and that they won't just use the updated language and mapping for graphql, instead choosing to require the saved search to return values for REST and then Celigo modifying them in the background for us. Completely removes certain testing ability and control over the setup.
By the way, this problem is still not resolved for our instance within the product/matrix flows, and it causes secondary issues when trying to sync inventory since "track inventory" is not automatically enabled on issuance or secondary sync after update.
A frustrating decision on their part to implement it this way and build the new integrator in a way that tried to duct tape together the old saved search implementation to work instead of simply redoing the setup to match current shopify documentation and capabilities.
@craigscott We always would like to provide a solution which would require minimum changes for the customer to make. When the design/built was made for the new Product flow supporting GraphQL, the particular field in discussion was not part of the productset Mutation. However, we were aware that this is commonly used by customer, hence we added this in the back end to make sure the functionality does not break. Only after the implementation, Shopify started supporting it by adding this attribute in the productset mutation (New `inventoryItem` field on ProductSetVariantInput — Shopify developer changelog).
I understand that they updated it later on to make it available. But I was hoping to see more ability to update as time goes on and as Shopify makes changes to their API. It makes me worry that the next time Shopify updates something that we would like to use, that Celigo will be unable or unwilling to update their mapping to let us use it.
Also unfortunately this did not require minimal changes for us the customer. We had to work with two support people over about two weeks, continuously edit the saved search and mapping, and even get on a call, just to get the tracked inventory setting to work with your implementation.
To me the simple solution would be that if the tracked field is NOT mapped by the customer, run the script you guys run, but if the tracked field IS mapped then Celigo ignores running their script and mutation to handle it.
Trying to work through this brought up another frustration we discovered.
The request and response data shown in the debug console is just blatantly not accurate. On more than once occasion the request data (and not just the tracked field) will show something set one way, then the return data shows it was set, but in Shopify it was not. Or the request data shows it was not added the way mapping shows (even when hardcoded), but the response data would indicate it was.
i have completelost trust that the request data sent to Shopify and the response data shown are actually the final data sent or real data recieved.
@craigscott, @divyanshuchhapia can provide more insight into how we plan to address this now that it is natively supported in the mutation. However, with any new feature or functionality introduced by Shopify—or any other application—it takes time for us to evaluate, plan, and implement changes. Like most development teams, we work in sprints that are planned weeks in advance, and we release updates every six weeks. Given that this update was released just 8–9 weeks ago, even in an ideal scenario, it would take at least 12–13 weeks to develop a change, as the initial portion of that timeline is already allocated to pre-planned sprint activities.
Additionally, since there was already a workaround in place for Shopify’s limitation, modifying it again could require additional customer adjustments or migration efforts. We always aim to balance agility with minimizing disruption for our users.
I understand the frustration, and I appreciate you sharing this feedback. Regarding the debug console issue, I’ll reach out to you directly to set up a call for review. We don’t have any known bugs in this area, and I haven’t seen this behavior before, so I’d like to better understand what you’re experiencing.
I understand all your points, that makes sense. And I get that it wouldn't make sense to just update stuff in the middle of sprints and without your standard deployment testing and process.
Admittedly I might be more frustrated than is deserved regarding this partially because of how excited I was to finally get to take advantage of some GraphQl capabilities, but mostly because the support process during all of this was not pleasant. Because it was so difficult to get the solution to work I was frustrated we could not just remove the behavior/script not working and allow us to map it directly.
Thank you for reaching out about the debug issue. I will get back to you on that.
Finally got our squared away this morning I think... One problem was their "preference" to use Item Name/Number for SKU. That field is not immutable, so we have modified that parameter to use Internal ID as it is immutable.
