Shared services platform: unit-level isolation with reuse

I would model the shared services organization at the Organization layer, each business unit as a Division, and each operations team as a Unit. The common case types and data model live in an Organization framework. Division implementation layers hold unit-specific SLAs, approval matrices, and regulatory reports. This gives reuse of the 70% common case types while keeping each unit's rules separate. The current single application with one access group per unit is insufficient because access groups authenticate users but do not by themselves filter list views, reports, or data pages. I would also add a BusinessUnit property to case and data classes, and enforce it in access control policies. The tradeoff is more divisions and a heavier security model, but it is the only way to support quarterly access reviews and a new unit every nine months without cloning. I would not create five separate applications because that would destroy the reuse target and multiply upgrade cost.

Internal users get access groups scoped to their division and unit, with role-based privileges for case actions. Record-level isolation should use attribute-based access control: an access control policy on work and data classes requires .BusinessUnit equals the operator's unit, and for partners .PartnerID equals the operator's partner ID. Do not rely on UI visibility alone; list views, report definitions, and data pages must all use the same policy or a filtered data page. External partners should use a separate access group and portal, with a restricted case type view, no internal notes, and no access to internal reports. For quarterly reviews, export access group membership and ABAC policy coverage, and test with negative cases: a retail user querying a commercial case ID, and a partner querying another partner's case. The tradeoff is that ABAC adds evaluation cost and test complexity, but it directly addresses the 14 out-of-unit accesses found by audit.

Create a new Division and implementation layer, not a new application. Reuse the Organization framework and common case types. Put unit-specific SLAs, approval thresholds, and reports in the new implementation layer. If the new unit's process differs, use circumstancing or extension points in the framework rather than copying case types. Use a configuration workbook and delegated rules for business-owned parameters, but keep structural changes in the implementation layer. The nine-month plan should include a framework gap assessment, a security model extension for the new unit code, data migration for open cases, and a pilot with 50 users before full rollout. The risk is that the framework has hidden unit-specific assumptions; I would run application validation and a rule-resolution review before build. This is slower than cloning in the first month, but cloning would create a sixth upgrade path and undermine the shared platform.