Confirmation emails, registration flow

Software improvement (Archived)
1

@Kirsten @serenity @sstead Not sure if this deserves it’s own topic, but I couldn’t really see anywhere else to squeeze it in. Feel free to move if there is somewhere more appropriate.

Related to Updated Registration and Enterprise Accounts

I think that some of the confusion around emails in the registration process could be solved by implementing the following:

  • Any user that wants to use the backend needs to confirm their email address before being given access. That is a much more standard pattern and is much easier to understand our current model of confirming the contact email on the enterprise. It’s also good because then we can have confidence that any “owner” or “manager” of an enterprise will be contactable by us at the email address provided.

  • The ‘email’ attribute on enterprise should be removed, and replaced with a ‘contact’ field, which is a reference to a user. This is set to the owner of the enterprise during registration (for simplicity), but can be changed later, (ie. contact email for an enterprise cannot be set during registration, all correspondence is with the owner until such time as the contact email is explicitly changed later, from the backend)

  • Those two changes mean that the registration process can finish off by sending the user to the admin section directly, where we can bring up a full page that tells them that we have sent them a confirmation email, and that they need to go and confirm the email address for their user account (if they have not already done so).

  • Once they confirm their email, they will be redirected to the full page package selection screen, and then on through to the admin.

I feel like this is a much more linear and logical flow than what we currently have. The additional benefits will be:

  • Users creating multiple enterprises at once and then confirming their email address will only need to confirm their email address once, because responsibility for confirmation is switched from the enterprise model to the user model, so once the owner confirms their email, all of the enterprises they just created are happy.

  • The process and implications of changing the contact user for an enterprise can be explained in more detail in the enterprise form than can really be afforded in the registration screens. These are:

  • That a new user account will be created for the given email address if it does not already exist, and a confirmation email sent to that address

  • That it will need to be confirmed before emails are sent to that address, rather than the owner’s email. This is awesome (!) because we can guarantee that any enterprise has a valid email address to send correspondence to all the time. In light of this, I suggest that we only allow transfer of ownership to a user whose email address has already been confirmed.

3

From my understanding, this is the current process which is in place, but we have an issue connected to the fact that only users who need to access the backend today have their email verified, whereas we need ALL users creating an account (also shoppers) to have their email verified if we want to be able to “match” their email to an existing list of customer for example in the case of the private shop feature.
The all process when we think about the different cases is a bit complex I think…

SO I have started a first attempt to sum up all the discussions / bugs on community / github (was a bit messy :-o), here is the document I came up with : https://docs.google.com/document/d/1TVA37GUfFxvBzqecL2919oAW18oOiesnutcZ-5Ixw9E/edit?usp=sharing

Ping @danielle @maikel @Kirsten and I guess we’ll need a bit of a broader approval then as it impacts pretty deeply all the instances and the hubs, I think it’s great if we get approval on how we are going to set this up by the functional people before getting into the technical implementation…
Every instance will need also to “consult” and communicate with the hubs about the changes… the customer list can be a pretty “touchy” topic.

4

Hey there, you’re amazing @MyriamBoure for taking this on. Thank you :smile:

I tried to read through the google doc over my coffee before work but it’s needs more attention. So I’ll dedicate some time over the course of the next couple of days to read and respond properly (I’ve started).

In the meantime thought, I wonder if it’s another way to ‘skin the cat’ (so to speak), is to think about it from the perspective of each actor in the system. Correct me if I’m wrong about this breakdown, but it could be said that there is a matrix of actors within the system. I thought we could maybe structure it something along these lines:

email-verification.jpg1956×1408 775 KB

Will add more thoughts soon!

1 Like
5

@danielle I don’t understand the as is / existing difference ? From my understanding “as is” is “what it is now” and “to be” is “how it will be after” ? So lines and colums are saying the same, but I’m sure I just don’t understand :-o

Alo I would suggest really a “user centric approach”, so I would break down entreprises in “managers” and “owners” which can have different processes of registration as illustrated in my (long) document describing all that.
So it would be “entreprise managers” / “entreprise owners” / “customers” / “guest customers (unregistered)”

6

@danielle There might be a need to split the “customers” line in two as the processes might slightly differ if the user creates himself his account or if he does it on the invitation of a hub who has added him on a private shop list… you’ll understand when reading through the document.

7

As I understand it “Existing” here means something like “Already registered users”, because we need to break down how we will manage email confirmation of already registered users in the “To be” implemented solution.

So Existing user vs. Existing implementation (As is). Am I right @danielle?

And I do agree with you @MyriamBoure with the user centric approach. Enterprises are really just a group of users doing something together :slight_smile:

8

That’s correct @sigmundpetersen, already registered users makes better sense than existing :smiley:

We have to decide what to do about the existing set of users that are in the system, if we introduce a new process to sign up then we have to decide what to do with all the users that didn’t have to go through the verification process.

@MyriamBoure breaking it down to look at the flows per user type is a user-centric approach. It’s still possible to write user stories based on this, but it allows us to drill into each user type to make sure we understand all the flows and how the proposed changes would impact on this. I love flow/process diagrams :slight_smile:

I’ve swapped my day off to be tomorrow (Wednesday) rather than Friday so that I can put some time into this. I’ll work with @sstead to understand the ‘As Is’ flows for all the different user types, and then we can work through your document and other website examples to come up with the ‘To Be’ flows.

Cheers!

9

Sure @danielle! I have addressed the case of “already registered users” in the document as well so you’ll find some suggestion there :slight_smile:
But when you talk about user type, do we agree that enterprise owners are different than enterprise managers ? For me they areas they don’t have exactly the same permissions… and not the same registration process.
Looking forward to your feedback !

10

Hey, just spoke to @sstead about this and we don’t agree that they have two different registration processes. Here’s how we understand it (side note: we both think this is a terrible user experience and very confusing):

If the manager to be assigned is already an OFN user

The enterprise owner types the email address of the manager (who exists as an OFN user) into the manager field. That user then becomes a manager of the enterprise and they receive a email to say this has happened.

If the manager to be assigned is NOT already an OFN user

The enterprise needs to get that manager to sign up as a user of the OFN. Once they have done that, they follow the step laid out above.

So, in either case the manager needs to follow the user registration process, which is the same as what a customer or an enterprise had to do.

THERE IS A HACK: Using the notifications field to trigger the registration up process for non-OFN users

The enterprise owner types the email address of the manager (who does not exist as an OFN user) into the notifications field. That then triggers a process to get the manager to sign up as an OFN user, within which they have to verify their email address.

So, what we have to do is to change the way enterprise owners can add a manager so that they can use the manager field in the way that it works for the hack.

But regardless, this is out of scope for the email confirmation process because they are not dependent upon each other. You can set up email confirmation without fixing the enterprise manager process.

11

@danielle @sstead from my understanding, I don’t agree with you on an important detail that makes all the difference :
As an entreprise owner, today I can only add as a manager an email address that has been confirmed, so an “owner or manager type” email address, not a “user type”.
I tried what you said, I wanted to add Pierre as a manager for an entreprise, but he had only a shopper account. I couldn’t find his email when I type in the “manager” field… I had to ask him to create an entreprise so that his email is validated, and then I could add him as a manager.
SO the only workaround is as @sstead in that discussion Managing Users (including Enterprise Users) is to add him in the “notification field” which triggers the email verification process…

So it’s not about the manager to be assigned to be an OFN user or not, he needs his email to be verified… so he needs today to be an OFN manager OR OFN owner… I really see two different user types here.

BUT I agree with you that we can set up email confirmation without fixing the entreprise manager process. Once the users are verified, they will appear in the potential managers list, so it will be a bit more intuitive than it is now… and we can fix the UX on a second stage.

12

OK, I’m still going through the document but you’ve put a load of effort into this @MyriamBoure and you’ve done a great job! :smiley:

There’s a lot of detail, it’s taking me a while to go through it and discuss it with @oeoeaio and @sstead as I do and we’ve been brainstorming and doodling on whiteboards as we go. The functionality isn’t straightforward it seems, and understanding how it all works takes pulling the flows and backend technical set up from their heads!

My first thought: there is some scope creep happening with what has been included in your document. There are a number of focus points being covered in your document (and on this topic thread) that we could shave off to make it far more lean:

  1. The bits that cover email confirmation as part of sign up process - it should be possible to streamline this more and reuse existing functionality and keep it to a minimum.

    • e.g. use the same welcome email that is sent now, once they’ve clicked the link in the confirm email)

  2. The bits that seem to be additional things you cover that are outside of the email confirmation process:

    • Improvements to the sign up form (e.g. adding fields)
    • Enterprise marketing/campaign needs (e.g. first name, last name, pseudo, clean database)
    • Changing the way guest users / customers work for enterprises
    • Enterprise manager sign up process

My second thought: this work is going to be fairly complex, which makes me think it’s going to cost more than what is budgeted. Is there a cobudget for this feature, somewhere that other instances could contribute?

Finally for this post, here’s the scribbles we did:

FullSizeRender.jpg1406×1684 722 KB

Bottom right of the image: the places where new people can sign up / be signed up.

Top left of the image: the current flow and proposed future flow for the sign up process from the login modal.

Top right of the image: the exceptions to this basic flow, and how to deal with them.

Bottom left of the image: the outstanding questions we have for this flow.

We did something similar for the Register Enterprise sign up, which is on a few pieces of paper and need to be collated.

My biggest wish right now was that there existed a big ‘bible’ of these current flows through the system, so that we could just pull them up and see how we would change them. How nice would that be??! But instead, maybe we can make a deliverable of this piece of work the documentation of the flows for registration through the system and all the other processes that link in to it. Then we would be starting that bible of how OFN works :slight_smile:

From here:

I’m going to continue to read through the document Myriam, and @sstead is going to go through it thoroughly on Friday. I wonder though whether it’s possible for you to go back through it and strip out the ‘out of scope’ items to make it just about email verification. I think it’s better for you to do it than for me to cut and remove things you’ve added, I would feel bad :slight_smile:

And I wonder whether we can break up the pieces of functionality to be developed based on each sign up entry point? It means we can then add it to GitHub this way, with the epics being each sign up entry point and the issues under that the bits of that process to be changed or added to.

We could also could work through each and draw the current and desired flows? I don’t know about others, but I find it easier to understand complex functionality when it’s depicted visually rather than text-based.

OK, I’m going cross-eyed and my brain is imploding so I have to leave it there for now :blush:

I’ll be able to respond to messages over the next couple of days but won’t have a chance to dedicate any decent time till Sunday. I’ve set aside the afternoon to work on it.

13

I wish I have your talent @danielle to sum up everything visually :wink: It’s much clearer !!! I’ll make an effort to work more like that next time !

So I have reviewed the whole document and made quite a lot of modification thanks to your new inputs also that clarified my understanding. It was a bit hard to read so I accepted them all, if you want to see them you can “see revision history”. I am off for till Monday and won’t be able to do the drawings before Sunday night / Monday either…

I did a first attempt at the end of the document to break and list the pieces of functionality before we put that into GitHub, please feel free to modify if it’s not adapted, that’s the first time I do that, I need to learn :slight_smile: Feel free to modify anything in the document, even in edit mode, I’m fine with it :slight_smile:

I have opened a cobudget here : http://cobudget.co/#/buckets/1380 but didn’t launch as I have no idea what amount to put in…

About the exception 2 in your drawing “previous guest checkout”, can’t “link to customer record” be kept out of scope as well ? I think it’s ok for now, if user has no account, he doesn’t expect that his info are tracked, that’s why we doesn’t want an account sometimes…
Unknowns:

  • unconfirmed users : for me they just stay as such until they do something else that triggers again the confirmation email… so they are treated as “guests” basically.
  • about the second point, I think depending on “from where the confirmation email were sent” (the trigger action), so from which process they sign up, the landing page after sign up should vary… I don’t know the tech side of it :wink: but I pointed that in the GitHub breakdown attempt.
14

Hey there, my understanding is that this is the key reason we need verification (according to @oeoeaio, and I understand why). Perhaps Rob can explain the why more eloquently than I can though :slight_smile:

15

Hey @MyriamBoure I’ve created a number of GitHub issues all under the User Email Verification epic.

You’ll see each of the sign up places (as laid out in your google doc), and I’ve added current and future flows for the first two (user sign up from modal; enterprise sign up), along with the outstanding questions that need to be answered before the full scope of the change is defined.

I don’t know the flows for the other ways to sign up, if you have an understanding of these then it would be great if you could add them! And add the relevant bits of your google doc to the associated issue so that it’s all together (and create new issues if I’ve missed anything).

Note: I added an enterprise manager sign up issue under this epic, but feel that it’s a ‘nice to have’ rather than a ‘must have’ and therefore doesn’t need any detail in it just yet. :slight_smile:

Cheers!

16

Awesome @danielle I filled in stuff from my document and tried to make a drawing for the customer-only shop process… can @pierredelacroix start working on it ? Do you want to review some last questions / clarification with the Aus team first ? Do we want to (can we ?) first raise a bigger co-budget bucket ? For which amount then ? As I said for the moment it’s only 500€ from OFFrance and Pierre is ok not to count all his hours… @lin_d_hop @Sara can OFN UK contribute as well to financing this work ? I know UK is contributing to lots of fundamental issues already…

17

So sorry @MyriamBoure but I can’t dedicate any time to this till Friday. I’ll spend a bit of time with Sally and try to get a tiny bit of Rob’s time (he’s the only AU dev at present) to figure out what next and whether we can start. There are definitely outstanding questions that need answering before we actually hit ‘go’, so we’ll focus on these blockers first.

18

Feature implemented [FEAT] Email confirmation