Dataverse 赋予君三種權限控制之基元，合而為權限之模：業務單位（BUs）、安全角色、隊伍。紙上之理，簡單明瞭。然實際操作，凡運行逾歲之項目，皆發展同此敗壞之模式：安全之模，積累而增長——每部門立一新角色，每項目立一新隊伍，每當有人言「然吾輩需區域資料分離」時，立一新業務單位。及至三載，模中已有二十角色，無人記其設立之由，而權限審計需時一周。
吾等已历三事，更其安之。首事历五旬，盖待之过久。末事仅一旬，缘察之在季月。此乃其律也。
其本实为之何
业部：居用者与载籍之层器。Dataverse之一行，属用者或众，而处业部。业部自本而下，为木之形。
安全角色：每表之权限集（创建/读取/写入/删除/追加/追加至/分配/共享），及每域（用户/业务单元/父：子/组织）。用户得一或数角色。
团队：用户群，可共拥记录，且可赋角色予团队（众成员皆承之）。
通识之误，以角色为职衔（如"Sales Rep"），以业务单元为部门（如"Sales"）。其本真之配，实为：
- 数据隔离之BU（区域、国家、其数据不宜混杂之并购公司）
- 职能之任（阅帐、修机、出至Excel）
- 跨部门协作之团队及记录共有之制
尔欲以角色隔离数据（如欧洲销售代表角色与美利坚销售代表角色之别）而非事业部，则终成N地各置N同角色之状。尔欲以事业部明权能（如设只读事业部），则得荒诞之枝干.
积弊之征兆 __JHSNS_SEG_50623266_12__观一项目之安全模型渐移，其状乃若：
- 有十或十以上定制角色，其名如"销售代表v2"、"销售代表特殊案例"、"销售代表美国山地地区"
- 有用户于单一账户上叠加四或五角色，以得恰当之组合权限
- 为容纳不实际共享记录所有权之用户而设之团队（用作组别分配之代称）
- BU树深逾三级
- 商贾不能无工程师询查，而应答"孰可睹此录？"之问者
去岁于客户处承继五症，其下之方乃吾辈所施
八步重构之法
汇列现存之物。将安全角色矩阵导出为电子表格。每一角色，每一表格，每一特权。此独本文件，乃诸般议论之始基。
以意分群组。察各角色之权限列，寻其聚簇。多数"定制角色"实为3-5意：仅读、标准用户、高级用户、管理员、系统管理员。细密者，几乎皆稍变而已。
定能级角色。以第2步之聚簇，易为3-5典常角色：
- acme_read_only - 每业表皆可读，不可写
- 专精标准用户 - 擅读兼善书写于所授记录（用户范围）
- 专精强权用户 - 擅读兼善书写兼增附兼授于BU范围
- 专精总管 - 众权尽享，组织范围
- 再增一选：专精整合，供服务主体之融合
辨虚实之别。大抵诸务，根元之外，零BU足矣。当直问曰："若用户见非其见之记，商贾可有稽核合规之患？"内务CRM，多无之。然跨国商贾，有数据属地之规，则应有之，每国需一BU。
倾覆BU之树。若汝有七BU，而无一BU具合规之由，则悉移诸用户于根BU，而删其余者。此乃最大之解禁——当树形平展时，多“BU范围之访问”之问题遂消。
以团队为归属，非为指派。团队当掌管众用户共负其责之记录（如交易台队列、支持分诊池）。勿以团队容纳共司一职之用户——此乃角色之用也.
迁用户于新角色集。授新之规范角色；次第去旧之定制角色，并验无碍。当先于UAT镜像行之，非于生产环境。
禁增角色。新设安全角色须有明确之票及理由。欲为X设新角色者，多需于既有角色增能。以"不"为默认答，可保模型长远之洁。
每季之访问复审吾辈所行
纵净模型亦渐迁。每季：
- 输出角色至用户之分配矩阵
- 标识拥有三职或以上者（或有合并之机）
- 标识仅一用户之职（或有删除之机）
- 抽查十人：彼等可睹其当睹而无所越乎？行其权于界面
- 审团队之属：诸队犹存其本乎？
每季四十五分钟，一工程师。其出或曰"无改"，或曰"汇一职之票"。二者皆善。
一窍之失，常使众惑
更易安全角色，若已分配于用户，其变不恒即传。角色之更，效于次用者之动，或待缓存之新，或可至十五刻。
若自角色中移除一项特权，而预期此变更为即时生效，然有此角色之用户于汝之变更与缓存刷新之间行事，则旧特权仍有效。
非紧急之变，可忽之，缓存自清。要害之撤权（账户失陷，员工离职），当禁用户之户，非其职。户禁立时生效；职变终将一致.
今若处累积之期，当何为？
若尔之项目已行六月，而见四定制之职，其用相重：当止勿增，且勿更制。俟其范围稍定，再历一月，凡"新职"之票至，皆记之而勿许，及至三月，乃行八步更制之术。一周专力之功，可省后四周之劳。
若尔之项目已行两载而不可修：辟专两旬之期，行全然重构，视之若一次性之债偿，继而置季度之检于其上。痛楚非自消也。