1.2 Public Sector Solutions Layered Architecture & Industry Common Layer

1.2 Public Sector Solutions Layered Architecture & Industry Common Layer

Architectural Principle: Salesforce Public Sector Solutions (PSS) is not a monolithic application or a collection of isolated custom objects. It is a modular, multi-tiered enterprise architecture built upon the high-availability Salesforce multi-tenant platform and powered by the Industry Common Layer (ICL). Architects designing for government must master the boundaries and interactions among all six architectural tiers to avoid technical debt and deliver scalable, secure public services.

---

The Six-Tier Architecture of Public Sector Solutions

Enterprise public sector implementations require a cohesive stack that links raw platform infrastructure to autonomous artificial intelligence. PSS organizes this functionality into six distinct architectural layers:

+-----------------------------------------------------------------------------------+
| Layer 6: Agentforce 360 & Autonomous Intelligence (Agents, Topics, Trust Layer)  |
+-----------------------------------------------------------------------------------+
| Layer 5: Presentation & Engagement Layer (Experience Cloud, Service Console)     |
+-----------------------------------------------------------------------------------+
| Layer 4: Digital Process Automation & BRE (OmniScripts, Data Mappers, BRE)       |
+-----------------------------------------------------------------------------------+
| Layer 3: PSS Domain Data Models (LPI, Grants Management, Benefits, ERM)          |
+-----------------------------------------------------------------------------------+
| Layer 2: Industry Common Layer (Discovery Framework, Action Plans, Assessments)  |
+-----------------------------------------------------------------------------------+
| Layer 1: Core Salesforce Platform (Security, OWD, Accounts, Contacts, Cases)     |
+-----------------------------------------------------------------------------------+

Layer 1: Core Salesforce Platform (Foundation Tier)

The bedrock of PSS is the core Salesforce multi-tenant platform. This layer provides enterprise-grade infrastructure, high-availability data centers, metadata-driven database architecture, and granular security controls. Core capabilities include:

• Security & Sharing: Organization-Wide Defaults (OWD), Role Hierarchy, Criteria-Based Sharing Rules, and Field-Level Security (FLS).
• Platform Data Models: Standard CRM entities including Account, Contact, Case, Task, Event, and User.
• Core Automation: Flow Orchestrator, Platform Events, Change Data Capture (CDC), and Apex execution runtime.

Layer 2: Industry Common Layer (ICL - Cross-Cloud Foundational Tier)

Historically, individual industry verticals (Health Cloud, Financial Services Cloud, Public Sector) engineered independent, duplicative features for tasks like checklist tracking, customer surveys, and relationship mapping. Salesforce unified these shared requirements into the Industry Common Layer (ICL). The ICL provides standardized, cross-industry micro-services and data structures that power all Salesforce Industries products.

Layer 3: Public Sector Solutions Domain Data Models (Functional Tier)

Built directly upon the ICL, this layer supplies pre-configured standard objects tailored to specific public sector statutory programs:

• Licenses, Permits, and Inspections (LPI): Authorizations, applications, fees, code definitions, inspection visits, and violation enforcement.
• Grants Management (Grantmaking): Notice of Funding Opportunities (NOFOs), application scoring matrices, awards, and disbursement schedules.
• Benefits Management: Public assistance programs, benefit schedules, eligibility criteria, and enrollment tracking.
• Emergency Response Management (ERM): Crisis triage, contact tracing graphs, and care plan allocation.

Layer 4: Digital Process Automation & Business Rules Engine (Automation Tier)

This layer abstracts business process execution from the database layer:

• OmniStudio: Consists of OmniScripts (guided digital intake forms), FlexCards (modular, 360-degree constituent user interfaces), Data Mappers (declarative ETL engines mapping JSON to Salesforce records), and Integration Procedures (server-side controllers that batch operations, transform data, and invoke external REST APIs).
• Business Rules Engine (BRE): A high-performance calculation engine that executes complex public policies, statutory fee schedules, and means-tested eligibility formulas declaratively using Expression Sets, Decision Tables, and Decision Matrices.

Layer 5: Presentation & Engagement Layer (Channel Tier)

Constituents and government workers interact with PSS through specialized interfaces:

• Experience Cloud Portals: Pre-built public sector LWR (Lightning Web Runtime) and Aura templates supporting both unauthenticated guest citizens and authenticated portal users.
• Public Sector Service Console: Tailored for intake workers, case managers, and compliance inspectors, featuring workspace tabs, subtabs, constituent interaction timelines, and Omni-Channel routing.

Layer 6: Agentforce 360 & Autonomous Intelligence (AI Tier)

The pinnacle of the architecture enables autonomous and assistive AI across public service workflows:

• Agentforce Public Sector Agents: Autonomous agents that resolve constituent inquiries, verify submitted documentation, schedule inspection visits, and guide users through application filings.
• Agent Builder & Topics: Tools for declaring operational topics, natural language instructions, and deterministic actions grounded in CRM records and Data Cloud.
• Einstein Trust Layer: Enforces zero-data-retention agreements, dynamic PII masking, toxic content filtering, and complete audit logging for government compliance.

---

Deep Dive: The Industry Common Layer (ICL)

The Industry Common Layer is one of the most heavily tested architectural concepts on the AP-222 exam. Candidates must understand the exact purpose and mechanics of each major ICL component.

1. Discovery Framework vs. Schema Proliferation

In government, public agencies regularly update application questionnaires based on annual legislative sessions. For example, a child welfare intake form might require 60 questions that change annually.

• The Anti-Pattern: Adding 60 custom fields to the Case or Account object each legislative year. This rapidly consumes custom field limits, clutters page layouts, complicates reporting, and degrades database performance.
• The ICL Solution (Discovery Framework): Questions are created as reusable data records (AssessmentQuestion). Questions are versioned (AssessmentQuestionVersion), grouped into logical question sets, and rendered dynamically via OmniScripts. When a constituent submits the form, their answers are stored in AssessmentQuestionResponse records linked to the parent transaction without altering the underlying database schema.

2. Action Plans & Action Plan Templates

Regulatory compliance requires standardized administrative rigor. When a constituent submits a commercial restaurant permit, the agency must execute dozens of mandatory checks:

• Zoning verification;
• Fire suppression inspection;
• Health department sanitary review; and
• Liquor board background check.

An Action Plan Template is authored once by an administrator to capture this repeatable blueprint, defining task durations, target queues, document checklist requirements, and dependencies. When a new BusinessLicenseApplication record is submitted, an automated Flow or Integration Procedure instantiates an Action Plan, instantly generating assigned tasks and required document checklist items.

3. Assessments & Assessment Indicators

In the field, building inspectors and code enforcement officers must evaluate properties against statutory building codes. Rather than using subjective free-text notes, PSS leverages the ICL Assessment engine:

• Assessment Indicator Definitions (AIDs): Objective rules defined at the system level (e.g., "Working smoke detectors present on every floor" with a boolean data type; or "Fire suppression water pressure" with a minimum numeric threshold of 65 PSI).
• Assessment Tasks: Groupings of indicators assigned to an inspection Visit.
• Inspection Assessment Indicators: The actual recorded observation captured in the field by the mobile inspector, linked directly to the regulatory code.

---

Declarative-First Architecture vs. The Legacy Anti-Pattern

A critical failure pattern in public sector IT modernization is the Legacy Custom Schema Anti-Pattern. System integrators transitioning an agency from an old SQL Server or mainframe environment often attempt to map every legacy relational table 1-to-1 into custom Salesforce objects (e.g., creating City_Permit__c, License_Renewal__c, Citizen_Master__c).

Downstream Consequences of Custom Schema Proliferation

When an architect implements custom objects instead of standard PSS models:

1. Loss of Pre-Built Assets: Salesforce provides pre-configured Business Process Libraries for common licenses (e.g., cosmetology, commercial cannabis, building permits). Custom schemas render these assets unusable.
2. Breakage of Automated Compliance: Standard PSS objects automatically link inspection visits to violations (RegulatoryCodeViolation), which automatically generate enforcement actions (ViolationEnforcementAction). Custom schemas require thousands of lines of fragile Apex code to emulate this native lifecycle.
3. Agentforce Blind Spots: Agentforce public sector reasoning tools are pre-grounded on standard entities like RegulatoryAuthorizationType and IndividualApplication. Grounding an autonomous agent on proprietary custom objects introduces hallucination risks and configuration overhead.

---

Architectural Trade-offs & Decision Criteria in Government Engagements

Architects must balance multiple constraints when implementing Public Sector Solutions:

1. Spring '21 Architectural Milestone: Native Standard Objects

Prior to Spring 2021, much of Public Sector Solutions was delivered via a managed package with namespace prefixes (e.g., vlocity_ps__). In Spring '21, Salesforce transitioned PSS into platform-native standard objects.

• Exam Implication: Modern PSS architectures do not rely on managed package custom objects for core licensing or permitting. Standard objects enjoy higher governor limits, native SOQL query performance, standard reporting, and full compatibility with Flow Orchestration.

2. Large Data Volume (LDV) Strategies

State and national agencies process millions of transactions annually. To ensure high performance:

• Custom Indexing: Ensure external identifiers used in legacy lookups (e.g., Legacy_License_Number__c) are designated as External IDs and indexed.
• Data Skinning & Archiving: Use Salesforce Big Objects or Data Cloud data lakes to archive historical inspections and expired licenses older than statutory retention windows (e.g., 7 years), keeping the operational transactional store lean.

3. Government Cloud Compliance (FedRAMP & DoD Baselines)

Public sector solutions deployed for U.S. federal and defense agencies frequently run in Salesforce Government Cloud environments:

• FedRAMP High & DoD IL4/IL5: Require strict perimeter security, dedicated physical infrastructure, FIPS 140-2 validated encryption in transit and at rest, and US-citizen-screened operational personnel.
• Salesforce Shield: Essential for meeting public sector audit mandates, combining Platform Encryption (encrypting data at rest at the database layer), Field Audit Trail (retaining historical data changes for up to 10 years), and Event Monitoring (tracking unauthorized constituent data exports).

---

💡 Real-World Exam Scenarios & Case Analysis

Scenario 1: Multi-Department Environmental Review Questionnaire

A state Department of Environmental Protection must implement an annual environmental compliance questionnaire for 12,000 industrial facilities. The questionnaire contains 85 detailed questions regarding chemical storage, waste disposal, and emissions. The state legislature amends 10 to 15 of these questions every year. The agency's lead developer proposes creating 85 custom fields on the Account object to capture answers.

Why will this proposal fail an architectural review, and what is the correct AP-222 solution?

• Flaw in Developer Proposal: Adding 85 custom fields every legislative cycle causes catastrophic schema bloat, exhausts field limits, and requires continuous code deployments and regression testing.
• AP-222 Standard Solution: Deploy the Discovery Framework from the Industry Common Layer. Configure each question as an AssessmentQuestion, manage annual legislative updates via AssessmentQuestionVersion, bundle questions into an AssessmentQuestionSet, and collect responses dynamically via OmniScript into AssessmentQuestionResponse records without touching database metadata.

Scenario 2: Legacy Mainframe Migration to Standard Licensing Objects

A municipal building department is migrating 25 years of building permit records from an IBM DB2 database into Salesforce. The project manager insists on creating a custom object called Building_Permit__c with 70 custom fields to mirror the DB2 schema exactly, arguing that it will simplify data migration.

How should the Lead Architect counter this proposal?

• Demonstrate that adopting standard BusinessLicenseApplication and RegulatoryAuthorizationType objects enables the department to immediately utilize pre-built OmniStudio guided intake flows, native Document Checklist Items for architectural blueprint reviews, and automated Inspection Visit scheduling.
• Show that the DB2 fields can be mapped into standard PSS fields during the ETL process, using custom fields only for unique municipal data elements that have no standard PSS counterpart.