Siebel应用里的另一个权限控制是数据权限，也即功能里的数据的可见性（比如一个销售代表可以看见自己的所有销售机会，但是几乎没有什么必要让他看见其他销售代表的销售机会，而他们的Manager则可以看见他所管理的所有销售代表的销售机会），这称之为数据的可见性，也就意味着哪怕具有相同职责的用户所看见的数据是不一样的，这种Siebel里是通过position职位来控制的，View的控制和数据的控制这两种控制都是彼此独立的，他们结合起来一起控制着Siebel应用用户的权限。

按照数据权限控制的不同，Siebel里的数据可以分为两种类型，一种类型称为Customer Data，这种类型的数据包含销售机会，服务请求等交易类型的数据，这些数据主要由使用Siebel应用的过程中产生，这种数据权限都是控制在记录级别。

另一个相对静态的数据称为Master Data，这些数据相对而言比较静态，包含一些引用类型的数据，比如产品列表，这些数据通常由管理员产生，并按照类型归类，这些数据的权限控制按照类型（catelog）的权限控制进行。

实际上Siebel里的权限控制的思路来源于真实世界里的公司组织里的权限的思路（比如Manager可以看见他所领导的所有的销售的Opportunity），所以Siebel的权限是和公司的组织结构挂钩的，职位在一个组织里形成树状的结构，这样的结构意味着一个层次高的职位可以看见属于他的所有子职位的所有数据，职位并不是这棵树上的所有东西，在这棵上还挂着Division和Organization的概念，Division和Organization和我们平常所见的公司结构图里的分支和部门是一样的概念，其实建立Division和Organization的方法一样，只不过要在建Division的时候选择一个checkbox指定该Division为Organization。但是Organization和Division也有区别，他们都可以用于来设置公司组织架构的层次，但是Divsion里的数据都是共享的（division里可见），如果希望不同的Organization不能够互相看见对方的数据进行数据的控制，则要使用Organization。也就是说Organization可以作为一个数据权限的控制的单位但是Division不可以。
在Siebel应用里，数据的权限可以划分到用户的ID，职位，所属组织上，下图是雇员，职位和组织的关系：

即雇员用户可以有多个职位，每个职位也可以属于多个雇员，但是每一个职位一定是属于某个组织的，雇员用户在登录后只能够看见他们当前登录所选择职位的数据，当然他们登录后也可以改变自己的当前职位，从而能够看见他所赋予的别的职位的数据，我的感觉是，这个Siebel里的职位反而有点象11i里的职责的概念！

对于动态的Customer Data数据，权限的控制如下图：

也就是说，记录的权限控制可以是在employee，position或者在Organization级别上又或者它们的一个组合进行，采用哪张方式主要取决于该数据所属的BC的一些特性，通常这些数据都对应着相应的View，如：

•  My View指得是我的数据，如My Account
•  My Teams’ View指的是我的团队的数据（Manager视图）
•  All View则是属于一个Organization的所有的数据

通常在一条记录创建的时候，这条的记录的Organization属性就是该用户职位所属的机构，当然也可以手工更改这条记录的机构属性，

职位也是一个公司组织结构图上的一个小方块，用于组成公司的上下级汇报关系，而且因为职位远要比雇员要稳定（雇员很可能离职），所以职位的访问控制在企业的很多场景里提供了恰当的数据访问控制方式，，而且使用职位进行访问控制比之使用雇员进行权限控制有更大的稳定性。

前面提到View已经很多次了，但是只有在交代了权限控制之后才能够完全说清楚View的概念，实际上View就是看数据的一种方式，一个View必须以某种权限模式去观察数据（也就是说一个View要么赋予Employee权限，要么赋予position权限，要么赋予Organization权限），如果需要以新的权限方式来观察数据，就需要建立一个新的View，这个就是Siebel里View的概念。