Hi, in this video tutorial, we will only use the Excel file to explain exactly what OASIS does when the user performs a single sign-on. We in the Excel file simplified a use case where there are two users, user A and user B. Both of these users have the name Thomas Wong. The first user, user A's email is thomas.wong at 360factor.com, which is his work email. The second user, the user's email address is thomas.wong1482 at gmail.com, and that is his personal email. And your single sign-on process will provide a member ID or some sort of a unique identifier for the user. In my stylized example, I'm going to say that user A's member ID is 12345678, and user B is 87654321. So obviously, what I'm trying to highlight is that even though these two users technically are the same user, they have different email, and they have different member ID. And if your system is configured to perform purchase within your own AMS, then the user's single sign-on will also bring over what the user have purchased, which is, in my example, product A and B for user A and product A and C for user B. Now that we have this stylized example, I want to explain exactly what the user, what OASIS does when the user log in. When the user performs a single sign-on, what OASIS first does, the first thing OASIS does is take the single sign-on payload and look for these two fields. I'm going to highlight them in green. And the way that OASIS does it is OASIS is going to look for any existing user with a matching member ID. If it finds it, it will then grab the user and update that user with everything else, including the name, email, and purchase history. If the user, if OASIS was unable to find the existing user with the same member ID, it will then and only then go look for all the existing users in OASIS that have the same email address. And if it finds someone with the same email address, it's going to update that account by everything else in the single sign-on payload, such as the name, member ID, and purchase history, along with many other fields that we update. What I want to stress in this tutorial is that when OASIS refers to pivoting on a user attribute, what we mean is we're pivoting on fields that should be unique. In this case, we're pivoting on member ID first, and then we're going to pivot on user email second. And in this case, as long as the user's ID or email did not change, OASIS is automatically updating user's information. For example, imagine in this example, user A, Thomas Wong at 360firecare.com, email address have changed. Pretend that this email has changed to oasislms.com, but the user's member ID did not change. What happens is OASIS will find the user by this ID and update OASIS account for Thomas Wong to the new email address. Now, suppose the user's email address did not change, but the member ID have changed to 123456789. When that's the case, when this user log in, OASIS is unable to find anyone with this member ID, but OASIS will find some account with this email, and then OASIS is going to update the user with the new member ID. So as long as one of the pivot fields, email or member ID, exist in OASIS, we will be able to log the user in and reflect any update across other fields. So that is very important on how OASIS land the user during single sign-out. Now, it is important that when you have two accounts, such as in my example here, you should merge these two user in your AMS or whatever CRM you have, so that the user have one account to log in. And keep in mind, if you merge user A into user B in your environment, you want to make sure that whatever is the surviving account, I'm just going to say user B survived. Okay? You want to make sure that this account have the right purchase history. In this case, I probably want to make sure that the survived account, I'm going to call it user B survived instead of user C. We want to make sure that this account that you merged has all the purchase history. Because if you do a merge, and then if you only, the merge account only have product A and product C, when this user log in, all the purchase that this user made while he under his account, user A, will not come over. In this case, product B is not going to come over if you do not merge the purchases. This is how Oasis lend a user and any caveat that you need to consider when you are merging user in your CRM or your AMS. Thank you.

OASIS

single sign-on

Excel file

user accounts

CRM

SSO

Single Sign On

Jakarta