Sam noted the SAIL Boat to SAIL-AWAY migration may need to be tied to a PTO sync change. I verified that live instead of treating it as a calendar-only move.
Loaded Litify and Salesforce workup guidance. Ran live read-only Salesforce checks against LITIFY_ORG, including org connection, one Matter smoke query, Apex triggers on Time_Off_Request__c, PTO/calendar-related Flow inventory through Tooling API, and an Apex body scan for Outlook fields, Graph, callout, HttpRequest, NamedCredential, and calendar terms.
Yes, the migration needs to be tied to PTO sync. Salesforce stores the existing Outlook calendar linkage in Time_Off_Request__c.Outlook_Event_ID__c. If events are copied without repointing the writer or mapping old IDs to new IDs, Salesforce will still point to SAIL Boat events.
Active triggers on Time_Off_Request__c include dlrs_Time_Off_RequestTrigger and TimeOffRequestPolicyTrigger. TimeOffRequestPolicyTrigger routes to TimeOffRequestPolicyService, which handles PTO policy and unscheduled usage logic. It does not create Outlook events.
Live Flow inventory shows active PTO flows such as Employee PTO Updater v19, New Time Off Request v50, and Time Off Request - After Insert Update Dates v2. Local metadata shows Employee_PTO_Updater creates accrual records and sets Outlook_Sync_Status__c to No Sync Needed. It is not the Microsoft Outlook writer.
The Apex body scan did not find a custom Apex PTO Outlook writer. The only custom Apex hit on Outlook_Sync_Status__c was a test class. Other callout hits were Litify package classes, Zipliens, ScreenMagic, CaseStatus, or unrelated calendar wording.
Current interpretation: the PTO-to-Outlook writer likely lives outside ordinary Salesforce metadata, such as external automation, a local/cloud scheduled routine, Power Automate, an opaque managed integration, or a manual/external process that later patches Outlook_Event_ID__c.
Created: admin/outlook-audits/sail-away-calendar-migration-20260603/PTO-sync-coupling-addendum-2026-06-03.md
Do not bulk-copy SAIL Boat events and call it complete. The next safe step is to find the current PTO sync writer, create/designate a writable SAIL-AWAY shared mailbox calendar, repoint the writer, pilot one PTO record, verify the event lands in the new calendar, and verify Time_Off_Request__c.Outlook_Event_ID__c stores the new destination event ID.
No live Salesforce, mailbox, or calendar writes were performed. The destination calendar remains blocked until a true shared mailbox calendar is created/designated or the current group-calendar path is consented and tested. The sync writer remains the next discovery target.