本篇參考：
https://admin.salesforce.com/blog/2022/how-i-solved-it-bypass-validation-rules-in-flows
背景：作為系統的全域性考慮，我們在設計validation rule / flow / trigger時，往往會使用Hierarchy Custom Setting來透過標籤設定白名單，當有資料清洗時，可以只關注於當前的指定欄位，指定邏輯的清洗。
簡單的validation rule作為一個demo：Account表有一個自定義欄位 SLAExpirationDate__c，需要這個欄位超過custom metadata所要求的最低的預設值。
效果展示：
這種設計在實際專案中很正常，考慮到validation rule建立以後，歷史資料可能有髒資料，有些可以基於邏輯進行資料清洗，有些只能資料owner進行手動操作。
我們在專案中除了本表操作以外，還可能涉及到關聯表操作更新父表的情況，舉個例子，當建立Event / Task / Opportunity等資料情況下，某些場景可能需要更新到Account，比如某些場景下，針對Report使用可能需要記錄一些時間戳。這裡進行一個簡單的demo。針對Task，Task針對Account建立的第一條資料，記錄時間戳到Account自定義欄位： Task_First_Created_Date__c。簡單的flow操作以及效果展示。
現在問題在於，針對Account的髒資料，如果SLA Expiration Date有問題，就會導致當建立Task時，會更新Account然後報錯。針對建立Task的使用者不一定是Account的Owner，也可能是Account Team成員，他們不希望建立Task時，因為一個僅用於時間戳的欄位（僅report用）而影響到了他們實際的業務流程或者銷售流程，所以我們在實際專案中還需要考慮 onetime bypass的情況，即針對Task建立更新到Account資料，不應該觸發Validation Rule，只有針對Account自身資料的編輯，才需要遵循。
針對這種情況，目前想到兩種可行的方案。
1. 基於Hierarchy Custom Setting，先將當前User的資料插入進去，設定Disable_Validation_Rule__c為true，當流程結束以後，再將當前user的當前記錄刪除。以下是效果展示。
2. 基於參考連結中的方式，理解起來也很容易，我們可以基於3步走。
1. 目標表建立兩個欄位，一個Datetime型別，設定預設值為系統當前日期，一個Formula checkbox型別，使用剛建立的Datetime型別變數減去（當前日期減去幾秒時間），如果結果大於0，證明允許bypass，值為true，否則不允許bypass，值為false。
Note：之所以這麼設計是當前的Datetime欄位，只有初始化是當前值，之後使用就會小於0，則需要走validation rule，當其他的關聯表需要bypass時，設定這個Datetime欄位為當前時間。之所以減去幾秒時間，代表當前關聯表transaction操作時間，參考連結中寫的是減去5秒，實際的transaction很難超過這個時間，通常都是毫秒級別。
2. Validation Rule進行增強，只有這個formula為false才會要求執行vlaidation rule，如果為true，則bypass跳過validation。
3. Flow進行增強，設定Datetime型別為當前時間。
效果如下方gif所示。
這兩種方式優缺點：
方式1優點：
- 更精確操作，避免幾秒的誤差導致使用者誤操作；
- 可以適用於批次資料的操作。
方式1缺點：
- 儘管Custom Setting屬於資料層面，鑑於hierarchy custom setting的特殊性，可能出現未知的錯誤或者情況。頻繁的插入和刪除需要進行深度測試。
方式2優點：
- 簡單操作並且邏輯易於理解。
方式2缺點：
- 幾秒的時間不適用於批次資料的操作，容易出現偶發性錯誤風險，不夠精確。
總結：本篇主要介紹了針對 validation rule的onetime bypass的兩種方案，篇中的兩種思路僅拋磚引玉，方案2感謝原國外作者的思路。篇中有錯誤地方歡迎指出，有不懂歡迎留言。有更好的實現方式歡迎討論。