A well-developed, logic-driven project schedule a) Reflects the technological and logical constraints between activities as accurately as possible; and b) Supports a valid forecast of the consequences when activities do not proceed as planned.
The essence of the logical statements under automatic scheduling is that the “Successor” shall be scheduled As Soon As Possible subject to the constraint that it May Not Start (or Finish) before its “Predecessor” has Finished (or Started) – (depending on the type of relationship, FS is assumed). Scheduling the Notification as a (SS-14) Successor of the FAT is stating that the Notification will be scheduled As Soon As Possible except that it May Not Start before (14 days before) the FAT Starts. Any circumstance that delays the Notification has no consequence for the FAT. The Early Start date may end up exactly where you want it, but the Late Start and Slack values would be incorrect.
If the contract prohibits carrying out the FAT without first notifying the customer, then the notification must be a predecessor of the FAT. The approach I suggested keeps the logic flowing in the right direction.