Educator Signup Flow

Introduction

The educator sign up flow is generally divided into four steps (Sign up, Verify your email, Request faculty verification, Complete your profile), but it interacts with a couple external 3rd party APIs in the background (SheerID and Salesforce). Exactly how and at which point we interact with those APIs is the trickiest part of Accounts for the educator signup flow.

In order to develop a clear understanding of all the parts, I find it better to explain the flow from the different perspectives and then briefly explain in summary.

From the frontend perspective

Step 1

User types in this information:

• First name
• Last name
• Phone number
• Email
• Password
• User checks these checkboxes:
• Receive newsletter? (optional)
• Agree to the Terms of Use and Privacy Policy

What happens in the backend:

• A user account gets created. The user's state is set to "unverified" because the user has not yet verified their email address. (Note that until the user verifies/claims that email address as theirs, anyone can subsequently come in and complete the signup form with the same email address, including themselves at a later time).
• An email gets sent. The email includes a pin that the user can enter in step 2 of the signup flow. And it also includes a link that the user can click on, which has the same effect as entering the PIN in step 2.

What happens in Salesforce:

• Nothing. Nothing gets sent to Salesforce yet because the user has not yet verified their email address. It could have been a bot that submitted the signup form or a fake or malicious user which we don't care about storing in Salesforce.

Step 2

User types in this information:

• PIN

OR, the user can click in the link sent in the email as part of step 1.

What happens in the backend:

• The user's email gets verified. This means that no one else can sign up with that same email address and no else can add it to their account.
• The user's account gets activated. The user's state changes to activated and a new salesforce lead with the user's information gets created.

What happens in Salesforce:

• A new lead shows up. The lead is not yet "finalized" though (FV_Final__c is false), which means that we are still waiting for Accounts to gather the rest of the user's information as the user completes the rest of the steps (3 and 4). Since we don’t know the user’s school yet, Accounts sends “unknown to Accounts” as the school name (because a school name is required by Salesforce, otherwise a Lead cannot be created), the verification status is set to pending_faculty, and the role is “instructor”.

Step 3

The user is presented with a screen that comes from SheerID. We call this the SheerID iframe.

The user has the opportunity to type in this information:

• Country
• School name
• First name
• Last name

But do note that the first name, last name, and email address are pre-populated using what information the user previously provided us with in step 1. However, the email address is not editable, and if they edit their first or last name, it will happen in the background until SheerID posts a web request with that information which typically is immediate and happens successfully, but if there is an error, then it could result in a data loss; we would never get that user's information.

The most important piece of information that users have the opportunity to provide us with in this screen is their school’s name from which they got their email address.

What happens in the backend:

• In the ideal scenario, the user gets instantly verified by SheerID. SheerID sends us the user’s verification in a web request to Accounts
• Using the user's SheerID verification id, the user’s approval and their school name. And if the user changed their country or first name or last name, then we also update those fields in Accounts because we trust SheerID. Then we update the user’s Salesforce Lead with the new and the updated information. The user’s account is not yet “finalized” though, even if they are verified by SheerID because we do not yet know the books (aka. “subjects”) that they have adopted or are interested in adopting.

Step 4

The last and final step is to get the last pieces of information from the user, mainly the books they have adopted or are interested in adopting and their specific educator role (Instructor, Administrator, Other educational staff).

The information that the user has the opportunity to give us at this point is: Which of the following best describes your role? How are textbooks chosen at your institution? How are you using OpenStax? Total number of students you teach per semester Books you've used in your courses However, not all of this information comes in every time. For example, if the user selects “Other” as their role, then the only field that they have the opportunity to provide us with is their role name.

Then, when the user submits this form Accounts makes another update to the salesforce lead for the user, and the user is then “finalized”, at which point salesforce automation should create a Contact for the Lead.

From the salesforce perspective

Step 1

Step 2

Step 3

Step 4

---

This is the information that gets posted to salesforce in Step 2

• FirstName
• LastName
• Phone
• Email
• LeadSource
• Application_Source__c
• Role__c
• OS_Accounts_ID__c
• accounts_uuid_c__c
• Company
• FV_Status__c
• FV_Final__c
• Needs_CS_Review__c
• Newsletter__c
• Newsletter_Opt_In__c