If a customer goes through the form steps, and clicks submit, then returns to the beginning of the form and enters a new order, the new order overwrites the previous order both on the Feathery Results Tab and in Stripe, instead of adding a new order. The only time this does not happen is if the browser history is cleared between entries. The reasons someone might go back to the beginning of the order form are:
- to place an additional order for more sizes
- to place an order for someone else
In this case the Submit is for a pre-order, so the action is “Checkout Cart” to save the credit card information for later.
Here is a screen recording: https://photos.app.goo.gl/NDKyjuYhxUY4Xy6r7
You can turn off user tracking in your form settings if you don’t want each new session in the same browser to track the same user
Hi Peter, even with user tracking turned off, it still overwrites. This is the case testing the form directly or as an embedded form. It only creates a new entry if both these conditions are satisfied:
- user tracking turned off
- form entry page is manually reloaded in the browser by user
Also, with user tracking turned off, a lot of extra partial duplicate entries end up in the Results. I tried de-selecting “Validate & Save Fields on Step” on pages with single buttons that progress to the next step (vs group buttons), thinking it would collect and save everything across the steps on the last step, instead it doesn’t collect any of the input fields on pages that have single buttons with actions, where you can de-select “validate and save”, it does save input from pages with group buttons (where you can’t de-select “validate & save”)
Here is a screen recording of the embedded form with user tracking turned off and it still overwriting:
Here is the form directly with user tracking turned off and it still overwriting:
Update: When I added “Start New Submission” Action to the last button on the confirmation page, I get different behaviors depending on the settings and whether the form is embedded or not:
Not embedded, user tracking OFF: when I click the button with the “start new submission” action on the confirmation page, it clears the form and returns to the first step.
Not embedded, user tracking ON: when I click the button with the “start new submission” action on the confirmation page, nothing happens, it reloads the confirmation page. If I add the “go to step” action after it, then it returns to the first step of the form with the fields cleared - this is ideal, except that it doesn’t work as an embedded form…
Embedded, “track users” turned off, and the “Start New Submission” Action set on the button on the confirmation page, doesn’t clear the earlier entries, so unless the user manually reloads the page, same issue that the earlier entry gets overwritten in Results and in Stripe.
So, while I can get it to clear and add a new entry as a form on its own by adding the “Start New Submission” action, I can’t get it to work when it’s embedded even with User Tracking turned off.
You’ll need to upgrade to our latest embed library version (2.0.173) to use the “Start New Submission” action. Cc’ing @eric for the Stripe overwrite issue
How do I do this? I have been reading through the Feathery docs, and staring at the JS embed code to see if there is a way to specify the latest embed library version, so far, I have not figured it out. I also looked through all the settings. Sorry if I’m missing something obvious.
I think what you are asking for is that when your users go back to the beginning, you want a new stripe customer created for that new start. Feathery’s integration with Stripe is designed so that there is a one-to-one between a feathery form user submission and a stripe customer. So the only way to end up with a new Stripe customer record is to also create a new feathery form submission. Using the “Start New Submission” action will do that for you and cause the restart to create the new Stripe customer.
I sounds like you are using JS embedding described here. If so, then you are either using react@latest in which case you should be picking up the version that supports the new action. If instead you have a specific version, change it to firstname.lastname@example.org.
Note @latest has a delay, so it will automatically pick up the new version after several hours (and often a redeploy of webflow is required)
Tested this morning (redeployed webflow) with user tracking on and off and either way it’s working, no-longer overwriting the customer in Results or Stripe.