Regardless of which Boyne site a customer is created on, the behavior of syncing customer to RTP|One is identical. Flows for how Identity handles create an account, log in, and claim account are detailed here.
Site | Authentication Method Turned On | Golf Enabled |
|---|---|---|
Boyne Golf | Identity + Guest | Yes |
Boyne HI | Identity | No but on Nop Instance with Golf |
Boyne MO | Identity | No but on Nop Instance with Golf |
Avalanche Bay | Identity + Guest | No but on Nop Instance with Golf |
Inn at Bay Harbor | Identity + Guest | No but on Nop Instance with Golf |
Gatlinburg | Standard Login + Guest | No |
Sugarloaf | Identity | Yes |
Sunday River | Identity | Yes |
Loon | Identity | No |
Big Sky | Identity | Yes |
NOTE: When guest checkout is turned on with Identity, Guest checkout has to be the prioritized flow. So the guest is first asked if they want to checkout as a guest, and if they opt to log in, they are routed to Identity. If guest checkout is turned on with standard login, either guest checkout or standard login can be prioritized with a setting.
For sites where golf is enabled…
Once an account is created, logged into, or claimed through Identity, or if a guest account is created through Aspenware Commerce (only turned on for Boyne Golf) and once the account is “settled” in RTP (see the documentation for RTP account flows), the following set of events happen to “settle” the account in EZLinks.
A message is sent to Topic in the Service Bus that a customer was created in RTP. We have an EZLinks function that is subscribed to that topic.
When a topic gets a message it tells the EZLinks Function that a customer has been created and the following events are followed to create a customer in EZLinks.
First we check to see if the customer already exists in EZLinks.We match on Internet User ID, which is a combo of some prefix (defined in settings) and ip code ("{_settings.InternetUserIdPrefix}{recId}")
If a customer does not exist, the customer is created in EZLinks with the following data:
IP Code (stored in InternetUserID), LastName, FirstName, StreetAddress, StreetAddress2, City, StateProvince, ZipPostalCode, CountryId, Phone, Email, sponsorId, ezLinksCountryId
If fields are not present then defaults are set. Address fields default to XX/XXX and phone defaults to 0000000000, country defaults to us
Frequently Asked Questions
Q: I understand that when an account is created, logged into, or claimed we check if the customer exists in EZLinks - what is this match done on? IP code, name, something else?
A: We match on Internet User ID, which is a combo of some prefix (defined in settings) and ip code ("{_settings.InternetUserIdPrefix}{recId}")
Q: When a guest uses guest checkout and buys a tee time, is the same process followed as above, or is a new account always created for guests?
A: Every time a guest enters checkout a new user is created in RTP w/ a new ip code. Since we match on ip code, I believe a new user would be create d in ezlinks each time
Q: What customer data do we send to EZLinks when an account is created? First, Last, (Do we send email, DOB, IP code anything else) what is our key identifier to link customers across systems.
A: IP Code (stored in InternetUserID), LastName, FirstName, StreetAddress, StreetAddress2, City, StateProvince, ZipPostalCode, CountryId, Phone, Email, sponsorId, ezLinksCountryId
If fields are not present then defaults are set. Address fields default to XX/XXX and phone defaults to 0000000000, country defaults to us