- Organization
在学习salesforce，经常会看到Org这一名词，其实就是Organization（组织）。如果一家企业想要使用Salesfroce产品，首先得向Salesforce公司购买一个Org instance，其实就是给你一个用户名和密码，登录后，可以创建用户，配置业务逻辑以及二次开发等等。
存储空间
当购买Org instance后，它会限制存储空间外，主要分为Data Storage, File Storage以及Big Object Storage（如果不够用，可加钱扩展空间，类似国内的某些云盘）
License
每个Org都会配置制定数量的License，每创建一个User都需要消耗一个User License（一般创建用户时使用Salesforce License)
API Request
这里需要注意的是，除了Storage和License外，Salesforce还有API的数量限制，毕竟高请求意味着高并发，消耗的性能更多，所以这肯定是个卖点指标啦。正常情况下，API Request是够用的，但是如果设计大量数据的操作还是要关注的，防止请求数量被使用完。
PS: 当然，在Org的信息中，还有Language, Time Zone, Fiscal Year以及Currencies等相关概念，但这些相对简单，大家看一眼就明白，这里就不说了。
- User
user，某个可登陆该Org的人，可以是developer, sales也可以是Partner。一般主要包含一下几个属性：personal, Security & Access, Locale
其中，最重要的概念是Role，User Liencese, Profile
PS: User一经创建便无法删除，只能去掉Active选项，该设计理念是为了方便查询某些历史记录。当然，inactive后，License 便会释放掉。
- Profile
profile，其实就是一组settings和Permissions，用来决定该用户登录时可以见到什么，以及可以做些什么。
PS: 每个User都归属于某一Profile，并且User与Profile是多对一的关系，详情请点击（https://www.cnblogs.com/cloudman-open/p/11552089.html）
-
Role
在私有或者混合模型中，Role层次结构允许更高级别的User继承了直系底层User的权限。比如：如果EMEA Sales Rep是某个case的owner，那么他的直系领导们(EMEA Sales Director, VP of Global Sales, CEO)都拥有访问这个case的权限，并且权限的继承是单项的。这里可能会有人疑问，什么是私有或者混合模型？那么就得提出sharing的概念。
-
Sharing
针对所有的sObjects，除了对该sObject schema的访问权限外（对该sObject具有增删改查权限），对其中的某条记录也有严格的控制。如上述的role中所说，EMEA Sales Rep是某个case的owner，那么在Case这个Object中，EMEA Sales Rep便有该条记录的访问权限，其他的case记录对他来说是不感知的。
那么问题来了，除了该条记录的owner之外，还有谁可以该条记录的增删该查权限呢？
这里可以看出，针对每个sObject我们都可以设置访问权限：Private, Public Read Only, Public Read/Write。
private：只有该条记录的拥有者才拥有读写权限。
Public Read Only: 除了拥有者之外，其他人都是只读权限。
Public Read/Write：所有人都有读写权限。
PS: 当然，这里的设置只是默认的访问权限，除此之外，还有Role hierarchy，Sharing Rules，Team and Manual Sharing这几种方式来分享记录的访问权限。（具体的内容，会在后面的帖子中分享）
- sObjects
sObjects(Salesforce Objects), 是Salesforce平台封装的对象，与传统的数据库table有异曲同工之妙。
sObject分为标准对象和自定义对象，标准对象是平台自动生成的对象例如：Account, Contact, Lead, Opportunity；而自定义对象可以按照各自业务需求自行设置，但是Salesforce为在API Name中自动加上“__c”这样的后缀（customize)。
每个对象都可以定义多个字段，并且每个字段可以是字符串，数字，公式，日期等类型。
针对每个字段，都可通过Field-Level Security设置访问权限。
当然，你可以设置Trigger，类似于数据库操作，before/after insert/update/del，例如：
trigger PairPtAttachToAccount on Pt_Attach__c (before insert) {
for(Pt_Attach__c ptAttach: trigger.New) {
List accounts = [select Id, Account_Id__c from Webex_Account__c];
for(Webex_Account__c account: accounts) {
if(ptAttach.Account_Id__c == account.Account_Id__c){
ptAttach.Webex_Account__c = account.Id;
break;
}
}
ptAttach.Site_Name__c = ptAttach.Site_Name__c + '.webex.com';
}
}