New user has their rowID change after signing in and using a webhook for Zapier

First time reporting a bug? Refer to our Start Here post.


Team ID:

App ID:

Description

  • I’m running into a new issue where I have a new user who signs in and then goes through Stripe which runs through Zapier. What I’m doing is running a webhook to create an entry in a Zapier table with the Row ID of the user and then using that to link back once the Stripe Checkout is complete. What I’m noticing and is happening intermittenly is that when I check the Zapier run history, it completes everything but then the Row ID doesn’t match what’s in Glide. So its like the user in Glide now has a new Row ID that is different than what they started with to sign in and go through checkout. And there is only one record of the user. Just not sure why

image

Can you verify that the rowID is from the user table and not another one?

I just blurred out parts of your user’s email and your webhook since they’re sensitive data.

For your problem, not sure what the cause would be, but if you can reliably reproduce that, I would suggest chatting with the support team using the Intercom integration in the builder (bottom right).

2 Likes

So I can verify that the new RowID is in the users table but I’ll need to export the users table and check the original one since I can’t seem to use the Find function within glide for the RowID column

Thanks for that. I didn’t even think about blurring that haha

I’ve confirmed that the original rowID doesn’t exist at all within the Users table but the second rowID does and is tied to the user. So not sure what is causing the RowID to change since it hasn’t happened every time we have a user sign up

Can you tell me what triggers this? A button in an onboarding process, or a row added to your Users table?

So a user has to sign in to use the app at all which is when the row is created. Then they will go to a sign up page and from there, i have a CTA to run an action where it does a webhook to zapier, opens stripe and then stripe and zapier do all the processing for me.

The webhook just sends the email, rowID and timestamp to Zapier and The “Row Created in Zapier” just sets a boolean to true so I know a user has already sent their data to Zapier.

So you just need the rowID in Zapier to push data back later on when the user completes the Stripe Checkout? I’m thinking if you query all rows and filter the rowID after the transaction is done, that might cost some more operations, but it guarantees you are getting the correct ID.

You might double check the “Create Zapier row” action UserID value. Given your quote, it looks like you are using this action to send the UserID value. And given that your action is on your Subscriptions table, you’d want to make sure that you are grabbing the user’s ID via the “User Profile” option in your value instead of the Subscriptions one or a new one with the “Unique Identifier” option.

Yep, i’m using the Row ID from the Users table. The weird issue is this doesn’t happen for all users. It’s prob been like maybe 4 times out of a lot more but it’s just enough recently that I didn’t know if it was something on my end or not. Honestly just hoping it’s a glitch and just something I’ll have to fix when it occurs.

image

Yep. It was the way I found to get the RowID so that Stripe can update the user after payment without going through the invoice route. I’ve thought about this but I just don’t know how many operations that would be. I’m already averaging like 500 updates a day so that might kill me in the long run haha

1 Like

It’s just one further step to run a JavaScript.

1 Like

okay cool! I’ll have to keep this in my back pocket if I end up having this happen more often.

1 Like

I do have a question about this now, if I no longer wanted to send a webhook to Glide, I could potentially just use this instead to react when Stripe’s webhook runs on a checkout being completed? And this would reduce my need on Zapier tables?

I’m just curious as that would actually probably save me on updates now that I think about it. Just wanted to ask before attempting to maybe change my billing workflows

That sounds correct to me. So you have 2 scenarios now: one to write the user info to Zapier Tables, the other to write the payment info back to Glide when a Stripe purchase is completed?

Yep, i’m doing both so if this can reduce it down to one, this probably makes more sense to implement instead. So will definitely have to update my process :slight_smile:

2 Likes

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.