Solution 03: SafeCity Public Safety

AI-Generated Content — Use for Reference Only

This content is AI-generated and has only been validated by AI review processes. It has NOT been reviewed or validated by certified Salesforce CTAs or human subject matter experts. Do not rely on this content as authoritative or completely accurate. Use it solely as a reference point for your own study and preparation. Always verify architectural recommendations against official Salesforce documentation.

Spoiler Warning

Attempt the scenario paper FIRST before reviewing this solution. Set a 180-minute timer, build your own artifacts using the 9 Essential Artifacts checklist, then compare.

Assumptions

1. CJIS Security Policy v5.9.5 applies; all CJI access requires Advanced Authentication (MFA) and FIPS 140-2 encryption at rest. A CJIS Security Addendum must be executed between the agency and Salesforce (FedRAMP alone is insufficient)
2. Salesforce Government Cloud (GovCloud) meets FedRAMP Moderate baseline
3. The 14M mainframe records average ~2 KB each; only active records (last 5 years, ~3-4M) will be migrated into Salesforce
4. Budget $4.2M/24 months supports GovCloud licensing, Experience Cloud, and SI engagement
5. Microsoft Entra ID supports SAML 2.0 federation with conditional access policies for CJIS MFA
6. CAD systems (GPD and GFEMS) remain untouched; integration is read-only inbound for reporting
7. 311 replacement is the Phase 1 deliverable on the mayor’s 9-month timeline

Key Architectural Decisions

Decision 1: Single Org (GovCloud) with Security Boundaries (D1 + D2 — HEAVY)

Single org because cross-department citizen view and unified reporting are core requirements. Multi-org would synchronize citizen records across 3 orgs, increase cost 2.5-3x, and make the unified dashboard architecturally painful.

The police union’s concern is valid but solvable — not through separate orgs, but through provable, auditable data isolation: profiles, permission sets, sharing rules, and Shield encryption. Offer an independent security audit as a confidence measure.

4-tier data classification model:

Tier	Classification	Examples	Access Control
T1	Public	Fire inspection results, 311 status	Unauthenticated portal
T2	Internal	311 case details, OEM plans	Authenticated employees
T3	Confidential (PHI)	EMS patient care records	GFEMS medical staff + HIPAA controls
T4	Restricted (CJI)	Criminal records, IA cases	CJIS-cleared + hardware MFA + encryption

Decision 2: Mainframe Tiered Migration (D3 — MEDIUM)

Tiered approach because migrating all 14M records is cost-prohibitive and the data quality issues (15% bad addresses, 8% invalid cross-references) make big-bang migration extremely risky.

• Migrate (into Salesforce): Last 5 years (~3-4M records), cleaned and deduplicated
• Virtual (Salesforce Connect / OData): 5-15 years old, read-only on-demand lookups. Requires a translation layer (e.g., IBM DataGate) to bridge COBOL/DB2 to OData
• Archive (mainframe with REST API): 15+ years, legal lookup only

This reduces active mainframe dependency immediately and provides a decommission path as records age past retention requirements.

Decision 3: CJIS Authentication + Citizen Portal (D2 + D4)

Entra ID federation with CJIS-specific conditional access policies. Step-up MFA (hardware token or FIDO2 key, not SMS) for CJI-classified object access. Non-CJI sessions use standard Entra MFA. Rejected a separate IdP for CJIS users because maintaining two IdPs increases admin burden.

Experience Cloud for the citizen portal — supports unauthenticated public access (fire inspections under FOIA), authenticated citizen self-service (311 tracking), and integrates directly with Service Cloud case management. The 9-month Phase 1 deadline leaves no room for custom portal development.

Critical Diagrams

System Landscape

graph TB
    subgraph GovCloud["Salesforce GovCloud — Single Org"]
        SC[Service Cloud — 311 + Cases]
        EC[Experience Cloud — Citizen Portal]
        SHIELD[Shield Encryption + Event Monitoring]
        subgraph Depts["Department Boundaries"]
            GPD[GPD: Police Records + IA]
            GFEMS[GFEMS: Inspections + ePCR]
            OEM[OEM: Emergency Mgmt]
        end
    end

    subgraph Integration["MuleSoft — Integration Layer"]
        API[API Gateway + Orchestration]
    end

    subgraph Retained["Retained Systems"]
        CAD[CAD Systems x2]
        MF[IBM Mainframe RMS]
        MUNIS[Tyler Munis HR/ERP]
    end

    ENTRA[Entra ID — SAML + MFA]

    subgraph Legend
        direction LR
        NEW[🟢 NEW - Being Built]
        KEEP[⚪ KEEPING - No Changes]
        RETIRE[🔴 RETIRING - Decommissioning]
        INT[🟠 INTEGRATION LAYER]
    end

    ENTRA -->|SAML 2.0 SSO| SC
    WEB[Citizens] -->|Unauthenticated + Auth| EC
    CAD -->|Read-only REST| API
    API -->|CDC events| GPD
    MF -->|Salesforce Connect OData| API
    API -->|Batch migration| GPD
    MUNIS -->|Nightly CSV batch| API
    API -->|REST sync| SC

    style SC fill:#cce5ff,stroke:#0d6efd
    style EC fill:#cce5ff,stroke:#0d6efd
    style SHIELD fill:#cce5ff,stroke:#0d6efd
    style GPD fill:#d4edda,stroke:#28a745
    style GFEMS fill:#d4edda,stroke:#28a745
    style OEM fill:#d4edda,stroke:#28a745
    style API fill:#fff3cd,stroke:#fd7e14
    style CAD fill:#e9ecef,stroke:#6c757d
    style MF fill:#f8d7da,stroke:#dc3545,stroke-dasharray: 5 5
    style MUNIS fill:#e9ecef,stroke:#6c757d
    style ENTRA fill:#e9ecef,stroke:#6c757d

Role Hierarchy and Security

graph TB
    CM[City Manager — Dashboards Only]
    CM --> CHIEF_P[Police Chief — All GPD]
    CM --> CHIEF_F[Fire Chief — All GFEMS]
    CM --> OEM_D[OEM Director]

    CHIEF_P --> IA[Internal Affairs — Restricted PS]
    CHIEF_P --> CMD[Watch Commanders]
    CMD --> OFF[Officers — Own Cases]

    CHIEF_F --> INSP[Inspection Mgr — All Zones]
    CHIEF_F --> EMS[EMS Medical — PHI Access PS]
    INSP --> FI[Inspectors — Assigned Zone]

    style IA fill:#dc3545,color:#fff
    style EMS fill:#fd7e14,color:#fff

OWD Settings: Police Cases/Investigations: Private. IA Cases: Private (IA + Chief + City Attorney via permission set). Fire Inspections: Public Read Only (FOIA). EMS Patient References: Private (medical staff only). 311 Service Requests: Public Read/Write within org. Emergency Incidents: Private with temporary sharing during activations.

Identity & SSO Flow

sequenceDiagram
    participant Officer as GPD Officer<br/>(CJI Access)
    participant Browser as Browser / MDT
    participant Entra as Microsoft Entra ID
    participant SF as Salesforce GovCloud

    Officer->>Browser: Navigate to Salesforce
    Browser->>Entra: Redirect (SP-initiated SAML 2.0)
    Entra->>Entra: Primary Auth (password + MFA push)
    Entra->>Entra: Conditional Access: CJIS policy detected
    Entra->>Officer: Step-up: FIDO2 hardware key or PIV card
    Officer->>Entra: Hardware token response
    Entra->>Browser: SAML Assertion<br/>(includes CJIS_Cleared=true claim)
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User record
    SF->>SF: Verify CJIS permission set + active background check
    SF->>Browser: Session (CJI-enabled) + Redirect

sequenceDiagram
    participant Staff as City Employee<br/>(Non-CJI — Fire, OEM, Admin)
    participant Browser as Browser
    participant Entra as Microsoft Entra ID
    participant SF as Salesforce GovCloud

    Staff->>Browser: Navigate to Salesforce
    Browser->>Entra: Redirect (SP-initiated SAML 2.0)
    Entra->>Entra: Authenticate (password + standard MFA)
    Entra->>Browser: SAML Assertion (Federation ID = employee ID)
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User (no CJI access)
    SF->>Browser: Standard Session + Redirect

sequenceDiagram
    participant Citizen as Citizen
    participant Browser as Browser / Mobile
    participant SF as Experience Cloud Portal

    Citizen->>Browser: Navigate to City Portal
    Browser->>SF: Public page (fire inspections — FOIA, no auth)
    Note over SF: Unauthenticated: public fire inspection results only
    Citizen->>Browser: Click "Track My Request" (311)
    Browser->>SF: Login page (email + password)
    SF->>SF: Authenticate (optional MFA)
    SF->>SF: Apply sharing: citizen sees only own 311 requests
    SF->>Browser: Session Cookie + My Requests view

SSO Design Rationale

CJI-classified users (GPD officers, detectives, IA): SAML 2.0 via Microsoft Entra ID with CJIS-specific Conditional Access Policy. Standard Entra MFA (push notification) is the first factor; CJIS Advanced Authentication requires a SECOND factor via FIDO2 hardware security key or PIV card (not SMS — CJIS Security Policy v5.9.5 prohibits SMS as a sole second factor for CJI access). Entra Conditional Access triggers this step-up only when the user’s group membership or app assignment indicates CJI access, avoiding burdening non-CJI employees.

Non-CJI city employees (fire, OEM, admin): Same Entra ID SAML federation but standard MFA only. No hardware token required. Same IdP, different Conditional Access policy based on department group membership.

Citizens: Unauthenticated access for public fire inspection results (FOIA compliance, Req 28). Authenticated self-service for 311 request tracking. Username/password with optional MFA. No Entra integration — citizens do not have city AD accounts.

Governance & DevOps

Environment Strategy

flowchart LR
    DEV1[Developer Sandbox<br/>311 / Portal Team] --> QA[QA / Integration<br/>Partial Copy]
    DEV2[Developer Sandbox<br/>Fire Inspections] --> QA
    DEV3[Developer Sandbox<br/>GPD / Security] --> QA
    SI[SI Sandbox<br/>Developer Pro<br/>Integrator Work] --> QA
    QA --> UAT[UAT<br/>Full Copy]
    UAT --> CAB{Change Advisory<br/>Board<br/>Bi-Weekly}
    CAB -->|Approved| PROD[Production<br/>GovCloud]
    CAB -->|Deferred| DEV1

    style QA fill:#e3f2fd,stroke:#1565c0
    style UAT fill:#fff3cd,stroke:#fd7e14
    style PROD fill:#fce4ec,stroke:#c62828
    style CAB fill:#f8d7da,stroke:#dc3545

Sandbox Strategy

Sandbox	Type	Purpose	Data Policy
DEV-1	Developer	311 / citizen portal development	Synthetic data only; no CJI or citizen PII
DEV-2	Developer	Fire inspection mobile app, workflows	Synthetic inspection data; no real property addresses
DEV-3	Developer	GPD security model, IA workflows, CJIS controls	No CJI data — synthetic criminal records with realistic but fictional data
SI-DEV	Developer Pro	Systems integrator work (CAD, mainframe, Munis integration)	Mock API endpoints; no production system connections
QA	Partial Copy	Integration testing, regression, security validation	All CJI and PII fields masked; data classification labels preserved for security testing
UAT	Full Copy	Department representative acceptance testing	All CJI and PII fields masked; GPD’s 2 part-time testers validate security model with masked data

CJIS Data Handling in Sandboxes

CJIS Security Policy requires that Criminal Justice Information never exist in non-production environments without equivalent security controls. The pragmatic approach: use fully synthetic criminal records in all sandboxes. Data Mask applied immediately after every sandbox refresh. The CJIS Security Officer must verify masking before any sandbox is released for use. This is auditable and will be reviewed during the CJIS compliance audit (planned Month 2).

Branching Strategy

• main — production-ready; deploys to Production GovCloud ONLY after CAB approval
• develop — integration branch; deploys to QA sandbox after peer review
• feature/phase-[1|2|3]/[ticket]-description — feature branches organized by phase
• hotfix/[ticket]-description — emergency path bypassing normal CAB cycle (post-deployment CAB ratification required within 48 hours)
• All merges require peer code review + CI-enforced Apex test pass
• CAB meets bi-weekly (Req 38); changes submitted by Wednesday are reviewed the following Tuesday

Testing Strategy

Test Type	Environment	Scope	Criteria
Apex Unit Tests	Developer sandboxes	All custom Apex, triggers, Flows	>75% coverage; all assertions pass; no CJI references in test data
Integration Tests	QA	CAD read-only feeds, mainframe OData connector, Munis CSV batch	End-to-end with mock CAD data; validate OData bridge to mainframe staging
Security Model Tests	QA	Cross-department data isolation, IA case restrictions, CJIS controls	Dedicated test users per department; verify zero cross-department data leakage
UAT	Full Copy	Department-specific acceptance	GPD: 2 part-time testers (security-focused); GFEMS: mobile inspections (offline); OEM: emergency activation workflow
CJIS Compliance Audit	QA + UAT	Access logging, encryption, authentication, personnel security	Independent CJIS auditor engagement (Month 2); remediate findings before Phase 2
Phased Rollout Testing	UAT	Phase 1: 311 + portal within 9 months	Citizen-facing UAT with synthetic service requests; load test at 4,500 requests/week

CoE / Post-Go-Live Governance

Change Advisory Board (CAB): Bi-weekly meetings (Req 38) with representatives from IT, GPD, GFEMS, OEM, and City Manager’s office. All production changes require CAB approval. Emergency changes follow a hotfix path with post-deployment ratification.

Knowledge Transfer (Req 41): 6-month structured handover from SI to the 3 internal IT staff. Deliverables: system admin runbook, integration monitoring guide, security model documentation, and paired administration sessions. Monthly readiness assessments during the transfer period.

Release Cadence:

• Standard releases: Bi-weekly, aligned with CAB meeting schedule
• Phase 1 (Months 1-9): Accelerated cadence for 311 + portal to meet mayor’s 9-month commitment
• Phase 2-3: Standard cadence with department-specific UAT windows
• Emergency patches: Hotfix path with mandatory CAB ratification within 48 hours; CJIS-impacting changes require CJIS Security Officer sign-off before deployment regardless of urgency

Government Compliance:

• Annual CJIS security audit with pre-audit self-assessment
• All artifact changes (code, config, metadata) in version control (Req 42)
• Automated deployment pipeline with audit trail of who deployed what, when, and which CAB approval authorized it

Integration Error Handling

SafeCity integrates with multiple retained systems. Each integration has error handling appropriate to its criticality and compliance requirements.

Integration	Pattern	Retry	DLQ	Monitor	Fallback
CAD Systems (GPD + GFEMS)	Read-only REST via MuleSoft	3x exponential (2s, 10s, 60s)	Integration_Error__c with CAD event ID and timestamp	Real-time alert to IT + department dispatch supervisor on any failure (dispatch data is life-safety critical)	CAD systems continue operating independently; Salesforce dashboards show stale-data indicator with last-sync timestamp
IBM Mainframe RMS (OData)	Salesforce Connect OData via IBM DataGate bridge	N/A (on-demand query)	Failed queries logged in Integration_Error__c with query parameters	Alert to IT when OData endpoint is unreachable for >15 minutes	Migrated records (last 5 years) available natively in Salesforce; only historical lookups (5-15 years) are affected; retry with manual mainframe terminal access
Tyler Munis HR/ERP	Nightly CSV batch via MuleSoft	1 automatic re-run at T+4 hours	Failed records flagged in HR_Staging__c with Status__c = Error	Morning alert to HR admin + IT if nightly sync fails entirely	Employee records in Salesforce remain unchanged until next successful sync; manual CSV upload available as emergency fallback
City 311 System (Phase 1)	REST JSON via MuleSoft (bidirectional)	3x exponential (1s, 5s, 30s)	Integration_Error__c with 311 request ID and payload	Citizen-facing: request accepted with pending-sync status; internal: alert to IT on >5 failures/hour	311 requests created directly in Salesforce if legacy system is down; backfill to legacy during transition period

Life-Safety Integration Priority

CAD integrations are classified as life-safety critical. Unlike other integrations where delayed processing is acceptable, CAD feed failures trigger immediate alerts to both IT and the relevant department’s dispatch supervisor. The architecture ensures CAD systems are never dependent on Salesforce — data flows are read-only inbound. If Salesforce is unavailable, dispatch operations continue unaffected.

Requirements Addressed

1. ✅ Single citizen digital front door — Experience Cloud portal with unauthenticated (FOIA) and authenticated (311) access (Reqs 1, 22, 28)
2. ✅ Cross-department incident coordination — Shared incident records with audit trail + temporary emergency access grants (Reqs 3, 24)
3. ✅ CJIS compliance — GovCloud + Shield encryption (FIPS 140-2) + Entra step-up MFA + CJIS Security Addendum (Reqs 19, 25-26)
4. ✅ Inter-department data isolation — 4-tier data classification model with profile/permission set/sharing enforcement (Reqs 20-21)
5. ✅ Mobile fire inspections with offline — Salesforce Mobile + offline capability for basement/elevator shaft scenarios (Req 4)
6. ✅ Mainframe tiered migration — Migrate (5 yr) / Virtual OData (5-15 yr) / Archive (15+ yr) approach (Reqs 11-12, 16)
7. ✅ IA case isolation — Private OWD + dedicated IA permission set; chain of command excluded during active investigation (Req 21)
8. ✅ Phase 1 within 9 months — 311 + citizen portal scoped for mayor’s commitment; fire inspections and police records deferred (Req 40)
9. ✅ CAB-governed release process — Bi-weekly CAB with formal change approval; 6-month SI knowledge transfer (Reqs 38, 41-42)

Risk Assessment

Risk	Impact	Prob	Mitigation
CJIS audit failure blocks law enforcement access	Critical	Med	Engage CJIS auditor in Month 2; GovCloud + Shield; document controls early
Police union rejects single org	High	Med	Demonstrate provable isolation via security review with union reps; offer independent audit
Mainframe data quality causes migration delays	High	High	Migrate in waves starting with cleanest data; quality dashboard; 20% contingency time
Phase 1 misses 9-month deadline	High	Med	Limit Phase 1 to 311 + portal only; defer fire inspections and police records to Phase 2

Domain Scoring Notes

• D1 System Architecture (HEAVY): Clear org strategy justification with trade-off analysis. GovCloud selection. Credible 9-month Phase 1 scope. Know what NOT to replace (CAD systems stay). Licensing: GovCloud + Service Cloud + Experience Cloud + Shield.
• D2 Security (HEAVY): CJIS Security Policy specifics (Advanced Auth, FIPS 140-2, personnel security, audit logging). Tiered data classification mapping to real access controls. IA cases isolated from GPD role hierarchy. CJIS Security Addendum requirement. PHI treated separately from CJI (different compliance regime).
• D3 Data (MED): Tiered migration (migrate/virtual/archive). Data quality remediation. Unified citizen profile linking across departments while keeping CJI invisible to non-GPD users.
• D6 Dev Lifecycle (LIGHT): CAB bi-weekly cadence constrains releases. 2 part-time police UAT testers is a risk.

Reporting Approach

Standard Salesforce reports and dashboards cover most departmental needs: Fire Chief monthly inspection dashboard (Req 30), 311 volume/resolution reports, and council quarterly summaries (Req 32). The Police Chief daily dashboard (Req 29) with 15-minute refresh requires a near-real-time reporting approach — CRM Analytics with a dataflow scheduled every 15 minutes pulling from CAD integration staging records. OEM real-time situation reports during emergencies (Req 33) leverage CRM Analytics dashboards pulling cross-department data with emergency-activated sharing. Ad-hoc reporting (Req 36) uses standard report builder with row-level security enforced by the sharing model — report builders cannot expose data beyond their classification tier. NIBRS submissions (Req 34) require a scheduled Apex batch exporting police incident data in the mandated FBI format.

What Would Fail

Common Mistakes

1. Recommending multi-org without doing the math. Multi-org triples licensing, kills unified reporting, and makes the citizen portal a nightmare. Single org with provable security boundaries is the answer. If you cannot articulate WHY it works for CJIS, you lose both D1 and D2.

2. Ignoring CJIS or treating it as generic “security.” CJIS has specific requirements (Advanced Authentication, FIPS 140-2, background checks, audit logging). “We will use MFA and encryption” without referencing CJIS shows the board you have not done your homework.

3. Trying to migrate all 14M mainframe records. Data quality issues make this a deathtrap. Tiered strategy is the only credible approach within budget and timeline.

Self-Scoring Checklist

• Did I justify single org with specific trade-offs (not just “it’s simpler”)?
• Did I reference CJIS Security Policy requirements specifically?
• Did I design a tiered data classification model with real access controls?
• Did I limit Phase 1 scope to what is achievable in 9 months?
• Did I address the police union concern with provable isolation?
• Did I handle fire inspections as public (FOIA) and IA cases as restricted?