12.1 Data Security, Org-Wide Defaults (OWD) & Sharing Architecture

12.1 Data Security, Org-Wide Defaults (OWD) & Sharing Architecture

Exam Focus: Public sector agencies handle some of the most sensitive constituent data in society—ranging from child protective services cases and criminal history to healthcare disclosures and welfare disbursements. Designing a data access architecture that strictly adheres to statutory confidentiality mandates while simultaneously enabling multi-departmental collaboration is a core requirement of the AP-222 blueprint. Architects must master baseline Organization-Wide Defaults (OWD), internal sharing mechanics (Role Hierarchy, Criteria-Based Sharing, Restriction Rules, Scoping Rules), and external sharing paradigms (Sharing Sets and Share Groups for high-volume Community users).

---

Public Sector Data Classifications & Statutory Mandates

In commercial CRM deployments, data sharing is often designed around open collaboration—sales teams and service agents frequently share visibility into leads, accounts, and opportunities. In Public Sector Solutions (PSS), this paradigm is reversed: data must remain strictly compartmentalized under the principle of least privilege.

Government agencies operate under rigorous federal, state, and international statutory frameworks:

1. Personally Identifiable Information (PII) & Sensitive PII: Full legal names, Social Security Numbers (SSN), Individual Taxpayer Identification Numbers (ITIN), biometric data, dates of birth, and banking details. Regulated under state data privacy laws, OMB mandates, and the Privacy Act of 1974.
2. Criminal Justice Information Services (CJIS): Criminal history record information (CHRI), biometric scans, arrest records, and investigative notes collected by law enforcement and regulatory enforcement agencies. CJIS Security Policy mandates logical separation, encryption at rest, and strict role-based access.
3. Health Insurance Portability and Accountability Act (HIPAA): Protected Health Information (PHI) and electronic PHI (ePHI) captured during Medicaid enrollment, disability assistance evaluations, or public health contact tracing.
4. Financial Disclosures & Taxpayer Information: Audited corporate balance sheets, Federal Tax Information (FTI governed by IRS Publication 1075), and personal income verifications submitted during means-tested benefit or grant evaluations.

Failure to enforce airtight data isolation can lead to statutory penalties, revocation of federal agency Authorization to Operate (ATO), and severe public trust compromises.

---

Baseline Organization-Wide Defaults (OWD): The Private Mandate

Organization-Wide Defaults (OWD) establish the baseline level of access that the most restricted user in an organization has to records they do not own.

On the AP-222 exam, a fundamental architectural rule applies: For all core constituent, licensing, inspection, and benefit entities, the baseline Org-Wide Default must be set to Private.

Setting OWD to Public Read-Only or Public Read/Write on constituent records is an automatic failure on the examination and an unacceptable security vulnerability in government.

---

Internal Sharing Architecture: Vertical, Lateral & Deterministic Isolation

Once the baseline OWD is established as Private, access is opened selectively to internal staff based on job role, jurisdictional responsibility, and case assignment.

+-----------------------------------------------------------------------------------+
| Internal Sharing Architecture Layering                                            |
+-----------------------------------------------------------------------------------+
| [1. OWD: Private]         --> Mandatory baseline lockdown for all PSS entities   |
| [2. Role Hierarchy]       --> Vertical managerial roll-up access                  |
| [3. Criteria Sharing]     --> Lateral cross-departmental & jurisdictional access  |
| [4. Public Groups/Queues] --> Multi-agency intake queues and review panels        |
| [5. Restriction Rules]    --> Deterministic hard filter (overrides all above)     |
+-----------------------------------------------------------------------------------+

1. Role Hierarchy: Vertical Management Roll-Up

The Role Hierarchy automatically grants users higher in the hierarchy the same level of record access as users below them.

• In PSS, the Role Hierarchy typically reflects the agency's operational structure (e.g., Agency Director -> Regional Supervisor -> District Case Worker / Field Inspector).
• Architectural Exception (Grant Access Using Hierarchies): For custom objects and certain standard objects, administrators can uncheck "Grant Access Using Hierarchies." In public sector scenarios involving Internal Affairs, Whistleblower Complaints, or Confidential Ethics Inquiries, this setting must be disabled to prevent senior agency executives from viewing confidential investigations involving themselves or their direct reports.

2. Criteria-Based Sharing Rules & Public Groups

Criteria-based sharing rules grant record access to defined groups of users when record fields meet specific values:

• Jurisdictional Sharing: A rule sharing BusinessLicenseApplication records where Jurisdiction__c == 'Northern District' with the Northern District Reviewers Public Group with Read/Write access.
• Program-Specific Sharing: A rule granting the Child Welfare Case Managers Public Group read access to IndividualApplication records where Program_Type__c == 'Foster Care Assistance'.
• Public Groups vs. Queues: Queues act as record owners during intake triage (e.g., Unassigned Intake Queue). Once a record is claimed by an individual worker, Public Groups maintain shared visibility for multi-disciplinary review teams (e.g., Fire Department, Public Works, and Public Health reviewers).

3. Restriction Rules vs. Scoping Rules

Introduced to address complex public sector compliance requirements, Restriction Rules and Scoping Rules represent a critical testing area on the AP-222 exam.

[!IMPORTANT] Key Exam Distinction: Sharing rules can only grant access; they can never restrict access below the OWD baseline. When an exam question requires hiding a subset of sensitive records (such as sealed cases, confidential informant reports, or VIP constituent records) from users who would otherwise inherit access via Role Hierarchy or Sharing Rules, the ONLY declarative platform solution is a Restriction Rule.

---

External Sharing Architecture: Portals & High-Volume Community Users

Public agencies engage millions of constituents via Experience Cloud citizen portals. Designing the external sharing architecture requires balancing massive user scalability with strict constituent privacy.

High-Volume Portal Licenses (Customer Community)

The vast majority of public sector constituents are provisioned with Customer Community licenses (high-volume portal licenses).

• The Architectural Constraint: High-volume Customer Community users do not utilize the standard Salesforce sharing table (Object__Share). Standard sharing rules, role hierarchies, and manual sharing do NOT apply to high-volume portal users.
• The Solution: Sharing Sets. A Sharing Set grants high-volume community users access to records that match a relationship between the user's User record (specifically User.ContactId or User.AccountId) and an Account or Contact lookup field on the target object.

+---------------------------+           +--------------------------------+
| Authenticated Constituent |           | Target PSS Record              |
| User Record               |           | (e.g., IndividualApplication)  |
| * ContactId = 003xx...    |           | * AccountId = 001xx...         |
| * AccountId = 001xx...    |           | * Applicant_Contact__c = 003xx.|
+-------------+-------------+           +----------------+---------------+
              |                                          |
              +-------------> [ Sharing Set ] <----------+
                       Matches: User.ContactId ==
                       IndividualApplication.Applicant_Contact__c
                       Grants: Read/Write Access

Key Elements of the External Sharing Stack

1. Sharing Sets:
   • Evaluates direct relationships: Matches User.AccountId to BusinessLicenseApplication.AccountId (for commercial contractors) or User.ContactId to IndividualApplication.ApplicantContactId (for citizen applicants).
   • Allows high-volume portal users to securely view, edit, and track their own applications, inspections, and benefits without consuming internal sharing infrastructure.
2. Share Groups:
   • Records created and owned by high-volume Customer Community users have no role in the internal hierarchy.
   • A Share Group is configured to grant specified internal Salesforce users (e.g., intake supervisors or public assistance caseworkers) access to records owned by high-volume community users.
3. Customer Community Plus & Partner Community Licenses:
   • Used for specialized external personas requiring advanced sharing capabilities, such as delegated third-party architectural review consultants, external legal counsel, or foster care placement agency partners.
   • These licenses possess individual roles in the Role Hierarchy, participate in standard Object__Share tables, and support Criteria-Based Sharing Rules and Manual Sharing.

---

Programmatic Sharing: When Apex Managed Sharing is Required

While declarative configuration is always the primary architecture in PSS, certain complex statutory requirements demand Apex Managed Sharing.

Evaluation Criteria: Declarative vs. Programmatic Sharing

• Use Declarative Sharing (Sharing Sets / Sharing Rules) When: Access is based on static user attributes, account relationships, record ownership, or simple picklist criteria (e.g., status, program category, district).
• Use Apex Managed Sharing When:
  1. Access must be granted to dynamic, ad-hoc groups of external or internal users that change continuously based on business logic (e.g., assigning three rotating peer reviewers from an external board of 200 medical examiners to evaluate a physician license).
  2. Access criteria require traversing complex multi-object junction relationships that exceed the single-level lookup capabilities of Sharing Sets.
  3. Sharing logic must be recomputed programmatically upon external system webhook events or complex BRE calculation outputs.

Apex Managed Sharing Mechanics

• Records are inserted into the object's share table (e.g., BusinessLicenseApplication__Share).
• Developers must define a custom Apex Sharing Reason (RowCause). This ensures that if the record owner changes or sharing rules are recalculated, Salesforce does not purge the programmatic access grant.

---

💡 Real-World Exam Scenarios & Case Analysis

Scenario 1: High-Volume Citizen Permit Tracking

A city building department deploys an Experience Cloud site for residential building permits using Customer Community licenses. After submitting applications, constituents report that their application status tracker dashboard is completely blank, even though the records exist in Salesforce and are assigned to the Intake Queue.

What is the root cause and AP-222 architectural fix?

• Root Cause: Customer Community licenses are high-volume portal licenses that do not utilize standard sharing rules or queue sharing. When the application was assigned to the internal Intake Queue, the constituent lost implicit ownership visibility.
• Architectural Fix: Configure a Sharing Set on the BusinessLicenseApplication object that matches User.ContactId with the Applicant_Contact__c field on the application, granting Read access.

Scenario 2: Confidential Human Services Records Isolation

A state human services agency manages child welfare investigations alongside general supplemental nutrition assistance (SNAP). SNAP caseworkers and child welfare caseworkers share the same profile and sit at the same level in the role hierarchy. State statute mandates that child welfare investigation records must NEVER be accessible to general SNAP caseworkers under any circumstances.

How should the Lead Architect enforce this requirement?

• Ensure the OWD for welfare case records is set to Private.
• Implement a Restriction Rule on the case object specifying that if the case record type is Child Welfare Investigation, the record is only accessible if User.Department == 'Child Protective Services'.
• Because Restriction Rules filter records after sharing rules, SNAP workers are completely prevented from accessing the records via search, list views, or reports.