I have to admit, I’m feeling quite frustrated with a particular limitation in Softr and I’m hoping to find some guidance and potential solutions from fellow app builders.
As we all know, Softr has been consistently providing new advanced tools, taking our apps to the next level. However, I’ve hit a roadblock with a basic user account function: allowing users to change their email addresses. I understand that this may not be a common requirement for some apps, but it’s essential for my use case, and I’m disappointed to find that it’s not even on the roadmap.
For those who have faced a similar issue, how do you manage user expectations when it comes to changing their email addresses when they have a subscription? Have you found any workarounds or solutions to overcome this limitation, without making your app seem unprofessional?
Currently, I have created an overridable User ID in Airtable that enables users to create a new account and override their new user ID with the old one. I can automate that process and this way all their old records are tied to the new account. However, I’m concerned about the Stripe account not being attached and the inconvenience for users having to resubscribe and the timing of when to do it for someone on an active subscription; the very reason for the limitation.
Softr team, is there any plan to address this limitation and provide users with the option to change their email addresses? I’m sure you understand that having a unique, app-specific ID for users would solve this issue. Your input would be highly appreciated, as this issue affects my ability to release my app.
In summary, I’m looking for suggestions on managing user expectations and finding workarounds for the email change limitation in Softr. Any input from the community and the Softr team would be greatly appreciated, as I’m genuinely concerned about having to scrap my work in Softr and move on to another platform.
Additional context - this issue impacts two apps that I am building, but the one that is hit harder is tied to the user’s work email address. As they change jobs, they need to change their email.
@andy can you please walk us through the use case ? and also when changing the email we would go and update in connected/airtable/googlesheet/stripe etc ?
Hi @artur , I think the broad use case is that anytime a user wants to change the email associated with their account, they can do it without having to create a new account.
For me specifically, I have members that will have an auto-renewing subscription paid via Stripe. In some cases, my users will be required to use an employer-based email account, but if they leave the company, they should be able to maintain their subscription and be associated with my application.
But this is just one case, people need to change their email address for several reasons, and it is awkward to make them create a new account for something like an email address change. Plus, I am not even sure how I handle transferring their active subscription … do I have to cancel it and make them sign up again? Do I find a way to let them wait until their subscription would have expired? I have a few other ideas, but they all seem clunky.
For your question, “would go and update in connected/airtable/googlesheet/stripe etc” - Yes, that would be ideal, but I don’t know if that is allowed/required for Stripe specifically. However, in my opinion, the idea of email acting as the primary key for a user is troublesome to begin with. It would seem to me that each user should have a key or token that performed that role e.g. each user gets a code such as ABCDE-97E64Z21 generated by Softr where the first segment is specific to the app and the second segment is specific to the user. Then changing the email was just another variable. If Stripe won’t accept this code as the customer ID, do they not allow the user to change their email address in some way that can be synced to Softr?
I get my users primarily and firstly through Online Travel Agencies like Airbnb and Booking.com. At the time of booking there is no email provided by the OTA other than an alias (like guestAresX@airbnb.com). However, we still want to give them access to the app right away so they can update their data (Name, ID, Passport Number, etc). For purposes of customer retention we would like them to be able to update the email to their real email so they could start using our app, instead of the magik link.
@artur I second the need for this. My entire account creation workflow I built was for the purpose of idiot-proofing and ensuring that email address is being copied directly from our microsoft teams to ensure no typos.
If an account is generated from a misspelled email, the staff record in airtable now has an undeliverable email address on file. All subsequent set-up notifications fail to send.
Even with this in place, we still have some instances of email CHANGES that normally occur in a business. This happens when IT updates an email for a name change, etc.
It’s super awkward to fix.
Fix in airtable staff record email
wait for softr to generate a new record with old “bad” email in airtable (it’s just a blank record with softr’s synced old/bad email) new record triggers like 5 notifications across the company ← I know, this is something I just need to add as a condition not to run but it’s still frustrating.
Re-generate new softr account creation with new correct email.
Re-direct staff to set up a password for second time.
I really wish there was simply a way to fix without having to go through this whole rigamaroll. Like @andy said, it feels like a pretty important and basic functionlity most account apps have
I agree that Emails should be changeable. Softr Users must have some kind of unique key other than their email address so that Softr can identify and change values for that user in AT. What if Softr simply mapped to the users record id in AT instead of the email address as the primary key to identify the user? Then the email address would be variable/changeable.
I wonder how many new data sources will be added before Softr deploys this? Not to mention email verification, conditional forms, … and improve existing functionality that’s needed like block update notifications at the app level, back buttons on modals to see previous modals, …
Until Softr directs more resources to improvements, rather than targeting new builders and Softr adoption with new data sources (ex. Hubspot beta just now), I’m afraid you’re right about use cases being limited to prototypes .
.