Student Signup Flow

Introduction

The student signup flow using an email consists of two steps while the student signup flow using a social network consists of one step.

Student signup flow using an email

Step 1

User types in this information:

• First name
• Last name
• Email
• Password

User checks these checkboxes:

• Receive newsletter? (optional)
• I agree to the Terms of Use and Privacy Policy

What happens in the backend:

• A User record gets created is created. The User's role is set to "Student" and their state is "unverified" because they have not yet verified their email address.
• An email is sent. The email includes a PIN that the user can enter in step 2, and a link that the user can click on instead of entering the PIN in step 2.

What happens in Salesforce:

• Nothing yet.

Step 2

User types in this information:

• PIN

Or, instead of entering the PIN in step 2, the user has the option to click on the link sent in the email as part of step 2; it has the same effect.

What happens in the backend:

• The email address becomes "verified". This means that no one else will be able to sign up with that email address or add it to their existing account. This user is now the owner of that email address.
• The User account becomes "activated". The user's state changes to "activated".
• We send the Lead to Salesforce. We send all the information we have about the user (student) to Salesforce.

What happens in Salesforce: Salesforce receives a new Lead with the following information:

• FirstName (the user's first name, required in step 1)
• LastName (the user's last name, required in step 1)
• Phone (the user's phone number, required in step 1)
• Email (the user's email address, required in step 1)
• LeadSource (always set to Student)
• Application_Source__c (most often set to Accounts unless the user is a Tutor user, in which case it would be Tutor Signup)
• Role__c (most often set to Instructor, or it could be Administrator, or Other)
• OS_Accounts_ID__c (the user's autogenerated ID in Accounts — user.id)
• accounts_uuid_c__c (the user's autogenerated UUID in Accounts — user.uuid)
• Newsletter__c (false unless the user checked the checkbox in step 1 to receive the newsletter)
• Newsletter_Opt_In__c (false unless the user checked the checkbox in step 1 to receive the newsletter)

Student signup flow using a social network

The student signup flow using a social network is pretty straightforward in the ideal scenario, but it gets tricky if we don't recognize the social network application's UID but we do recognize the email address that's coming from the social network or if the user already had an Account in the legacy flow (but not in the new flow) and is just trying to log in. To steer clear of any confusion, I'll explain what happens under the different scenarios.

Also, while the technical depth of how OAuth works is so far and wide, from a practical perspective—as far as we're concerned in Accounts—there are only two pieces that matter most:

• The uid ("unique ID")
• The provider name (ie. "Facebook" or "Google")

The email address and the user's name are secondary pieces of information. Social networks don't even always provide us with the user's email address (if the user does not give us access to read it) and the name is editable by the user in Accounts.

When we have never seen this user's social network (ID) nor their email address

This is the ideal scenario. In this case, we will create a new database record (Authentication) with the given uid which is unique to every user per application and the provider name like "Facebook" or "Google", at the same time that we create a new user record and attach the user record to the new Authentication. We set the new user's state to "unverified", and if we got an email address from the social network, we store it as "verified" because we trust that social networks have already verified users' email address.

In the backend, in the simplest case, this is what the code would look like:

user = User.new(state: 'unverified', role: 'student', first_name: 'Elon', last_name: 'Musk')
authentication = Authentication.new(uid: '123abc', provider: 'Google')
user.save

When we already this user's social network (ID) on file

In this case, we will actually just log in the user found the Authentication's uid and provider name.

In the backend, this is what the code would look like:

user = Authentication.find_or_initialize_by(provider: 'Google', uid: '123abc').user

When we don't have this user's social network (ID) on file, but we recognize the email address

If we cannot find a user by their Authentication's uid, then we can search for a user by the email address that we got from the social network (if we got one). In this case, this is what the code could look like:

EmailAddress.where(value: oauth_data.email).verified.with_users.map(&:user).first

And then we just log in that user.