通過做項目以及群里面的一些大神的聊天，總結一下關於項目中的兩個知識點，以后當做參考。
一. 在custom setting中配置集成接口信息后刷sandbox的問題
我們做項目時，經常會遇見和其他平台集成，比如和SAP等系統平台進行集成。因為salesforce開發模式大部分是dev -> full -> production. 所以當我們做類似callout等操作時，集成的賬號密碼或者Endpoint等通常要動態的配置。這種操作通常會配置在Custom Setting或者custom metadata type中。然而，因為某些開發規范性問題，我們無法保證dev或者full環境和生產代碼或者配置是最新的或者說正確的。所以一定時間我們有可能需要進行刷sandbox操作。所以我們針對這種Custom Setting 需要設計好，免得生產刷到full或者dev將生產相關的配置刷下來，引發問題，或者每次刷新sandbox都需要進行重復的配置操作。
解決方案為在custom setting或者custom metadata type 創建完必要的字段后，manage數據的時候，根據項目的要求，分別配置dev/full/production的配置信息，程序中根據當前的org類型或者org的名稱獲取不同的配置信息。這樣后期刷sandbox便不再需要考慮重復的配置操作。下面的內容以custom setting進行描述。
1.啟用list類型的custom setting:現在custom setting中默認不可以選擇list，如果需要選擇list需要啟用list custom setting type.
2. 針對Dev、Full、Production 均創建一套配置信息。
3.代碼中根據 Organization以及URL類獲取當前的org的類型(sandbox/production)以及sandbox類型(dev/full).
1 Integration_Setting__c integrationSetting; 2 Map<String,Integration_Setting__c> integrationSettingMap = Integration_Setting__c.getAll(); 3 4 Organization currentOrganization = [SELECT IsSandbox from Organization limit 1]; 5 6 //if current organization is sandbox, then return true; if current organization is production,then return false 7 if(!currentOrganization.IsSandbox) { 8 integrationSetting = integrationSettingMap.get('XX_Integration_Production'); 9 } else { 10 //get dev or full sandbox integration setting information 11 String orgBaseURL = URL.getSalesforceBaseUrl().toExternalForm(); 12 //each sandbox may have different single sign on URL,use contains function to identify which environment it is 13 //here simulate dev sandbox URL contains 'dev' and full sandbox URL contains 'full' 14 if(orgBaseURL.containsIgnoreCase('dev')) { 15 integrationSetting = integrationSettingMap.get('XX_Integration_Dev'); 16 } else if(orgBaseURL.containsIgnoreCase('full')) { 17 integrationSetting = integrationSettingMap.get('XX_Integration_Full'); 18 } 19 } 20 21 System.debug(LoggingLevel.INFO, '*** integrationSetting: ' + JSON.serialize(integrationSetting));
(注：Organization的IsSandbox僅適用於API version在31及以上才可以使用)
二.某些用戶針對某些場景下（Workflow/Trigger/Validation Rule）作為白名單用戶
項目中，我們為了完成特定的業務或者進行特定的限制，會對表創建Workflow,Trigger,Validation Rule等等內容。然而，我們后期還是希望一些特定的用戶有能力跳過這些校驗(Validation Rule)或者不走相關的或者這個表的所有的Trigger，或者相關的Workflow Rule，即白名單用戶。這種情況下，使用基於hierarchy的custom setting便可以搞定這種需求。
1.創建基於Hierarchy 的Custom Setting，設置三個布爾類型的變量，用於控制當前的用戶是否有對Workflow/Trigger/Validation Rule的白名單權限，默認均為false。
2.針對指定的User或者Profile設置Hierarchy的數據，這里設置了一個User。
3. 邏輯中控制白名單邏輯。其中Workflow以及Validation Rule控制方式相同，這里只對其中一個進行描述。
1) Trigger中進行控制：項目現在針對Trigger基本上會采用Handler方式，所以只要在最外面控制是否需要調用Trigger便可以。Hierarchy的Custom Setting可以通過.getInstance(ProfileId/UserInfoId)來獲取到Custom Setting的實例化對象。下面的例子為只要有Trigger的白名單權限，就不需要執行這個表的所有Trigger.
1 trigger CompanyInfoTrigger on Company_Info__c (before insert, before update) { 2 3 White_List_Setting__c whiteListSetting = White_List_Setting__c.getInstance(UserInfo.getUserId()); 4 if(whiteListSetting != null && whiteListSetting.White_List_For_Trigger__c) { 5 return; 6 } 7 8 Triggers companyInfoTrigger = new Triggers(); 9 if(TriggerExecutionHelper.enableExecuteF1) { 10 companyInfoTrigger.bind(Triggers.Evt.BeforeInsert, new F1Handler()); 11 } 12 13 if(TriggerExecutionHelper.enableExecuteF2) { 14 companyInfoTrigger.bind(Triggers.Evt.BeforeInsert, new F2Handler()); 15 } 16 17 companyInfoTrigger.Execute(); 18 19 }
2）Workflow/Validation中進行控制：使用$Setup.CustomSettingName.FieldName可以獲取到當前User對某個字段的訪問權限，通過這種方式便可以進行邏輯判斷。
demo的內容為只有指定的用戶才可以將status設置為approved.
（注：Workflow/Validation Rule只可以訪問hierarchy的Custom Setting）
總結：此篇內容主要是通過做項目以及前輩們總結的經驗寫的上面的兩個注意點，有錯誤的地方歡迎指出，有更好的方案歡迎提出，有不懂的歡迎提問。