Skip to content

Educator Signup Flow

Bryan Eli edited this page Sep 29, 2020 · 19 revisions

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 be updated 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 potentially result in data loss; we would never get that user's information.

The most important piece of information that users have the opportunity to enter in this screen is their school’s name. The school name must correspond to the school that provided 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 ID in a web request to Accounts
  • Using the user's SheerID Verification ID, we make an API request to gather the user's verification status and their school's official name according to SheerID. If the user updated their 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 mainly because we do not yet know the books (aka. “subjects”) that they have adopted or are interested in adopting.

Step 4

The final step is to get the last pieces of information from the user, mainly the books they have adopted or are interested in adopting.

The user has the opportunity to give us this information:

  • Which of the following best describes your role?
  • How are textbooks chosen at your institution?
  • How are you using OpenStax?
  • How are you using OpenStax?
  • Total number of students you teach per semester
  • Books you've used in your courses

However, not all of those fields will show up for the user every time, it depends on what the user selects for the previous field. For example, if the user selects "Other" as their role for the first question, then the only field they will see is "Role name" which they can type in.

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

From the SheerID 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