通过做项目以及群里面的一些大神的聊天，总结一下关于项目中的两个知识点，以后当做参考。
一. 在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).
Integration_Setting__c integrationSetting;
Map<String,Integration_Setting__c> integrationSettingMap = Integration_Setting__c.getAll(); Organization currentOrganization = [SELECT IsSandbox from Organization limit 1]; //if current organization is sandbox, then return true; if current organization is production,then return false
if(!currentOrganization.IsSandbox) {
integrationSetting = integrationSettingMap.get('XX_Integration_Production');
} else {
//get dev or full sandbox integration setting information
String orgBaseURL = URL.getSalesforceBaseUrl().toExternalForm();
//each sandbox may have different single sign on URL,use contains function to identify which environment it is
//here simulate dev sandbox URL contains 'dev' and full sandbox URL contains 'full'
if(orgBaseURL.containsIgnoreCase('dev')) {
integrationSetting = integrationSettingMap.get('XX_Integration_Dev');
} else if(orgBaseURL.containsIgnoreCase('full')) {
integrationSetting = integrationSettingMap.get('XX_Integration_Full');
}
} 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.
trigger CompanyInfoTrigger on Company_Info__c (before insert, before update) {
White_List_Setting__c whiteListSetting = White_List_Setting__c.getInstance(UserInfo.getUserId());
if(whiteListSetting != null && whiteListSetting.White_List_For_Trigger__c) {
return;
}
Triggers companyInfoTrigger = new Triggers();
if(TriggerExecutionHelper.enableExecuteF1) {
companyInfoTrigger.bind(Triggers.Evt.BeforeInsert, new F1Handler());
}
if(TriggerExecutionHelper.enableExecuteF2) {
companyInfoTrigger.bind(Triggers.Evt.BeforeInsert, new F2Handler());
}
companyInfoTrigger.Execute();
}2）Workflow/Validation中进行控制：使用$Setup.CustomSettingName.FieldName可以获取到当前User对某个字段的访问权限，通过这种方式便可以进行逻辑判断。
demo的内容为只有指定的用户才可以将status设置为approved.
（注：Workflow/Validation Rule只可以访问hierarchy的Custom Setting）
总结：此篇内容主要是通过做项目以及前辈们总结的经验写的上面的两个注意点，有错误的地方欢迎指出，有更好的方案欢迎提出，有不懂的欢迎提问。