Cacher is the code snippet organizer for pro developers

CALENDAR SYNCING STEPS 

https://secure.helpscout.net/conversation/638284396/363815/

Information that we have from the user:
Ryann Hodge - Friday, August 10, 2018 11:00am EDT
Charles Ra - Tuesday, August 7, 2018 12:00pm EDT

1. Find these appointments, so we know whose calendar these were booked on
  Ryann Hodge: Ron Saharyan’s calendar
  Charles Ra: Debra Angilletta’s calendar
  
2. Check to see if there are sub-users for each of them, and if so, are they syncing?
  Ron: yes, no
  Debra: yes, yes
  
3. Since Ron doesn’t have syncing, check admin account’s syncing (sometimes, they’ll share their calendars with admin instead of connecting their own account and admin will sync on their end)
  Ron: yep, that seems to be the case!
  
4. Knowing which calendars they were syncing to, head to calendar debug on backend
  Since Ron’s calendar is being synced from the admin account, you’ll find Ron’s calendar under the admin’s Google account on the backend. If you do a quick search (CMD+F) for “Ryann”, you’ll see it’s still there.
  
  With Debra’s calendar, she’s syncing to her own account on the debra@debraangilletta.com calendar. Doing a search for Charles, that doesn’t seem to be there anymore so she’s good to go.
  
5. Look into why one is still there, and the other isn’t
  So a couple days ago, there was an issue on the Google side of things where calendar syncing functions were affected (Tuesday, August 7) - in #announcements
  
  Looking at Charles’ appointment (on Debra’s calendar), it looks like they cancelled on August 6, 2018 12:20pm EDT. So syncing shouldn’t have been affected.
  
  Looking at Ryann’s appointment (on Ron’s calendar), it looks like the client cancelled on August 9, 2018 12:09pm EDT. So it’s curious why their syncing didn’t go through!
  
6. Since there aren’t any oddities (like “event doesn’t match Acuity”) on the backend, and looking at the changelog, they haven’t done anything weird like disable/reconnect syncing on the account around that time, we may need to do that “force sync” to see if that change will then get sent through. 

INFREQUENT SITUATIONS TO LOOK OUT FOR
  
AADSTS50020: “Azure Active Directory user account”
This comes up with folks who try to sync with an O365 calendar, because they purchased the (usually) Office 365 Home Edition and that doesn’t necessarily come with an O365 calendar; seems like the Office 365 Business Editions does.
Either way, because they purchase that, they believe they have the O365 calendar, but that’s not necessarily the case.

To debug:
- Ask them to go to the O365 online calendar link to see if they can access the calendar: https://outlook.office.com/owa/#path=/calendar/view/Month
- Ask them to go to the Outlook.com calendar link to see if they can access the calendar: https://outlook.live.com/owa/?realm=outlook.com&path=/calendar/view/Month
    - Generally, that's what the error message indicates. 
    - Outlook.com is a free online Outlook calendar which can be connected to Acuity, as well as the Outlook 365 downloadable app.

Example: https://secure.helpscout.net/conversation/634666946/361512/

Exchange to O365 Migration
Sometimes companies who used Outlook Exchange migrate their systems over to Office 365.
When this happens, their syncing stops and even if they disable and reconnect, syncing will not work. 

To debug:
- Look up the account ID associated with their sync
    - This can be found in the changelog, and it will look something like acc_5791c78fb4ccd0583a0142bb
    - Need to create a new email to support@cronofy.com 
        - Garry is our go-to man there who takes care of this for us

What to look out for:
- Once the account has been removed on the Cronofy side, they need to still reconnect with Exchange and not O365
    - If they connect with O365, we’ll need to go through the process again

Examples:
(user) https://secure.helpscout.net/conversation/384891452/209078/?folderId=63602
(Cronofy) https://secure.helpscout.net/conversation/384944329/209133/?folderId=63602


“Event Does Not Match Acuity”
This is something that can show up on the backend, under the Calendar Debug section for Acuity bookings that get synced over to the external calendar.

What this usually means: 
- The user has edited the synced event directly on their external calendar
    - When this happens the event ID no longer matches between that synced event and the one in Acuity, so if an update to the event happens, it won’t automatically update on the external calendar

To debug:
- In the instance it’s for only a single or handful of appointments, you can manually force an update to make the events match
    - “Edit” appointment details and hit “Save” without actually making any changes
    - This will basically “refresh” the event and cause a re-sync

Example: https://secure.helpscout.net/conversation/637481300/363302/?folderId=63602 (Erin’s from yesterday)


DEBUGGING + BACKEND

“Created” and “Updated” timestamps
This can come in handy especially when users are convinced that a time was supposed to be blocked off from their external calendar but a client was able to book at that time, or something along those lines.

To debug:
- Check the “created” and “updated” timestamps and compare that to the timestamp of when the appointment in Acuity was booked

Example: https://secure.helpscout.net/conversation/576775692/323246/?folderId=63602