Resident Portal Email Registration Process

Resident Portal Email Registration Process

Intent: This document should only be used for defining the process and programatic approach used to implent an email registration process for known users.  This article aims to outline the business logic decisions that were made, why, and how they were implemented.

Background: The Registration Process only applies to Communities with a Centrally Hosted Resident Portal.  This is due to how backups are ran for remote communities.  The intention of registering email address is to enable account recovery options for Resident Portal users. If the user has a registered email address we are able to send reset links or other user details.

Usage: Upon logging into the Resident Portal, if a user has an email(4) address populated they will be directed to the Account Summary page.  Otherwise, they will be sent to the My  Info page.  This is done to indicate to the user their account information may not be complete (ie: missing email). The next step is dependent on their reistration state.  There are several Resident values we need to be aware of at this point.

  1. email_registration_value  -  Current state of registration  ("R", "D", "I", {EMAIL ADDRESS})
  2. email_registration_expiry  -  DateTime in which the token is expired.
  3. email_registration_token  -  Unique token uuid for identifying the user
  4. email  -  users actual email address

We check the email_registration_value for the current state to decide how to handle the interaction. 

email_registration_value:

  • null - if email is also null we will disply a registration dialog. See Process section below.
  • "I" (ignore) - This means that the user has selected the 'Do not ask me again' checkbox before. We will not display any dialogs.
  • "D" (deleted) - This means that the user has previously had an email address populated/registered, and has since deleted it. We will not display any dialogs.
  • {EMAIL ADDRESS} - this means they are somewhere within the registration process, but it is incomplete. No dialog is displayed. See Process section below.
  • "R" (registered) - This means they have a valid email address that was populated by the registration process. These users would not have been sent here from login.

 

Options Adding/Updating:  From the My Info page the user has the ability to register a new email address or update an existing email address. The process when submitting an email is the same, however depending on their current state they have different other options. 

Adding:

  1. Close Dialog - this just hides the dialog and doesn't update any values. Same result for subsequent logins as above.
  2. Don't ask me again - This updates the email_registration_value to "I". Subsequent logins will still direct to My Info, however no registration dialog appears.
  3. Submit a valid email address -  See Process below.

Updating:  If an email is populated / registered for a user, no default dialog will be displayed, however a button will allow them to update/delete their email.

  1. Cancel - close dialog.
  2. Delete Email - This will clear the residents email from the account and mark the email_registration_value to "D" deleted. Subsequent logins will be directed to My Info, without a prompt dialog.
  3. Update - See Process below

Process: This process is triggered whenever a resident has chosen to enter an email address and submit it.

  1. After validation is complete (email/confirm email match) we want to populate the above mentioned columns.
    1. email_registration_value  -  This is set to the email/confirm email address. This is what will be used during the registration completion step.
    2. email_registration_expiry  -  Set the dateTime to current time + 1 day. After which the token is no longer valid and they must make an additional registration request.
    3. email_registration_token  -  We generate a uuid, which will be used during the registration complet process
    4. email  -  we won't update this yet.
  2. We then send an email to the email address they used in the request step. This email will contain general information about what is being requested, and provide a clickable link to complete the registration process.
    • The link should look something like ./ResidentSelfServicePortal/completeRegistration?token={uuid}
  1. Upon clicking on that link they will navigate to that page where we will do the following:
    • Attempt to identify the resident that is linked the uuid in the query string, taking into account the expiry
    • If found, we populate the email column with the current value of email_registration_value, and update email_registration_value with "R" for registered, we also delete the email_registration_token, so it cannot be used again. We leave the expiry, as proof the process was completed, and when.
    • If not found, we display a token not found error.
  1. Upon subsequent user logins, they will be directed to Account Summary

 



    • Related Articles

    • Back Office and Engage SSO

      Back Office SSO Engage SSO Back Office SSO FullCount utilizes the OpenId Connect (ODIC) protocol to authenticate users from external identity providers (IDP) into the Back Office. Documentation we can provide to the customer about the process can be ...
    • New Resident Portal Setup & Communication

      The creation of our new Resident Portal is to be completed by the Implementer/Support representative assigned to the task. This process no longer requres an additional task or scheduled deliverables from our development team. Below are the steps ...
    • API Connect - Resident Portal Employee FAQ

      What is API Connect - Resident Portal? API Connect - Resident Portal is a gateway for 3rd party vendor partners to access FullCount's resident information displayed on Resident Portal Our partners will be able to pull resident account balances and ...
    • Resident Portal Username Recovery/ Password Reset

      Intent: This document should only be used for defining the process and programatic approach used to implent the password reset process for known users. This article aims to outline the business logic decisions that were made, why, and how they were ...
    • API Connect - Resident Portal Implementation

      Assumptions: 3rd party vendor has been validated. Implementation steps: Signed contract/agreement from the mutual customer(s). Contract/agreement provides license and permission to share customer data with the 3rd party. Identify and populate 3rd ...