If you subscribe a customer to SMS via graphQL, and then come back to update that customer to unsubscribed, the state shown in the admin is “SMS not subscribed” as opposed to “SMS unsubscribed” as one would expect per the documentation. you can see the discrepancy by comparing the state displayed for email vs SMS - in the case below, i created customer with NOT_SUBSCRIBED for email & SMS, then updated the customer with SUBSCRIBED for both, and finally update customer with UNSUBSCRIBED for both… the admin shows “Email unsubscribed” but “SMS not subscribed.”
state shown in customer view of admin when customer not subscribed (initial state)
customer subscribed to both email and SMS marketing, via graphQL mutation:
customer unsubscribed from both email and SMS via graphQL mutation:
mutation:
“mutation customerUpdate($input: CustomerInput!) { customerUpdate(input: $input) { customer { id email firstName lastName phone emailMarketingConsent { marketingState } } userErrors { field message } } }”
input:
{“firstName":“test”,“lastName”:“test”,“email”:"test@test.com”,“phone”:“9145551212”,
“emailMarketingConsent”:{“marketingOptInLevel”:“SINGLE_OPT_IN”,“marketingState”:“UNSUBSCRIBED”},
“smsMarketingConsent”:{“marketingOptInLevel”:“SINGLE_OPT_IN”,“marketingState”:“UNSUBSCRIBED”},
“addresses”:[…],
“metafields”:[ … ]
}
Hey Aidrian, good catch - I just replicated this on my end and can confirm it’s a UI issue in the admin.
I walked through the exact same flow you described:
- Created customer with
NOT_SUBSCRIBED for both email and SMS → Admin showed “Email not subscribed” and “SMS not subscribed”
- Updated to
SUBSCRIBED for both → Admin showed “Email subscribed” and “SMS subscribed”
- Updated to
UNSUBSCRIBED for both → Admin shows “Email unsubscribed” but “SMS not subscribed”
The API is storing the data correctly - when I query the customer, both return marketingState: "UNSUBSCRIBED". So the underlying data is fine, but the admin UI isn’t displaying the SMS unsubscribed state properly.
One thing I noticed: When I tried using customerUpdate to set SMS consent (like in your example), I got this error:
"To update smsMarketingConsent, please use the customerSmsMarketingConsentUpdate Mutation instead"
So we should be using the dedicated customerSmsMarketingConsentUpdate mutation for SMS and customerEmailMarketingConsentUpdate for email, instead of customerUpdate. That said, even with the correct mutations, the UI still shows the wrong text.
I’m raising this this with our Customers team internally. In the meantime, the actual consent state is being tracked correctly in the system, so your SMS unsubscribe functionality should work as expected - it’s just the admin display that’s wrong.
Does this UI issue cause any problems for your merchants, or is it purely cosmetic?
1 Like
Thanks Donal… and it was definitely my mistake on pasting in the customerUpdate mutation - i forgot that my code actually breaks out the email and SMS marketing updates to their own mutation calls for exactly the reason you cite.
Good to know that the data is correct - i believe that for my client that is what’s actually essential. naturally having the admin UI reflect it correctly would be nice, but i think the data being accurate probably counts most.
thanks again!