Case Management Security and Server-Side Validation

Use one business unit per region under a root business unit. Assign each caseworker a security role at their regional business unit with create/read/write on cases at the business unit level. Because business units are hierarchical, a user in a region sees records owned by that region, not other regions.

• National supervisors: assign a supervisor role at the root business unit with organization-level read on cases. Do not give them write unless required; if they must reassign, scope write separately.
• Regional leads: assign a lead role at the regional business unit and add them to a field security profile for Investigator notes.
• 8-week task force: create an access team or owner team with a template that grants read/write on the cases in the two neighboring regions. Access teams are record-level but avoid one-off individual shares and are auditable by team membership. If the two regions sit under a shared division business unit, a team in that division with business-unit-level read is simpler; otherwise, use a Power Automate flow to add the task force team to the relevant cases and remove it after eight weeks.

Do not solve this with 260 individual shares. Sharing 90,000 records is slow, hard to revoke, and hides the real security design. Enable auditing on team membership changes and on case access.

The current JavaScript is client-side only. It runs on the form and is bypassed by Excel import, Web API, and integrations. A model-driven business rule has the same limitation unless it is also enforced on the server.

Use a synchronous pre-operation plug-in on Create and Update of the case table. It should:

• Reject a transition to Closed when ClosureDate is empty or SupervisorCheck is false.
• Reject invalid transitions, such as Draft directly to Closed, unless a documented override exists.
• Throw an InvalidPluginExecutionException with a clear message so the import row fails and the user sees why.

Keep a business rule or form logic for immediate feedback, but treat the plug-in as the enforcement point. A Power Automate flow triggered on create/update is asynchronous and can run after the record is already saved; it is useful for notifications and follow-up, not for hard validation. If the team cannot maintain plug-ins, use a required closure date column plus a synchronous classic workflow, but document that it is a weaker alternative. Test with an Excel import and a Web API update, not just the form.

Create a field security profile named Investigator Notes – Regional Leads, add the Investigator notes column, and grant Read (and Update only if leads must edit) to the profile. Assign the profile to the regional lead users or, better, to a team that contains the leads. Everyone else, including caseworkers, should have no field-level permission on that column; the field will be hidden or masked in forms, views, and exports. System administrators and the record owner with org-level access may still see it unless you plan for that; do not assume FLS overrides all privileged access.

Also check:

• Excel import respects field-level security for the importing user, but the import user may have broad privileges. Use a dedicated import account with a narrow role and test the notes column with a caseworker account.
• Enable auditing on the notes column and on field security profile membership changes.
• Review dashboards and views that might expose the column; FLS hides the data, but a poorly designed view may still show a blank column and confuse users.
• Document that integrations using an application user with a system administrator role can read the field. If that is unacceptable, use a separate secure table or column-level encryption pattern, not just FLS.