Solution: MetroServe City Services

Work in Progress

This content is currently being reviewed for accuracy and will be updated soon.

Architecture Decisions

Decision 1: Single Org with Role Hierarchy and OWD Isolation

The City Manager’s mandate is non-negotiable: one Salesforce org for all three departments. The architecture supports this through a combination of private org-wide defaults, a department-aligned role hierarchy, and sharing rules that grant cross-department access only where the business requires it (the shared citizen contact record).

The key tension in this scenario is that the shared citizen contact record must coexist with hard data isolation between departments. The resolution is to set the Contact OWD to Public Read Only: all departments can see citizen contact records (needed for deduplication and 311 routing) while all case and permit objects remain at Private OWD. This means a Planning analyst who looks up a citizen’s name sees the person exists, but cannot see their Code Enforcement case notes or Public Works inspection history.

Decision 2: Case Object with Record Types for 311, Combined with a Custom Permit Object

311 service requests map naturally to the standard Case object. They have a requester, a description, a status lifecycle, SLAs, and email notifications. Using Case for 311 gives Service Cloud’s built-in entitlements, escalation rules, and email templates without custom development.

Permit applications are not cases. They have a multi-step approval workflow, fee schedules, inspection children, and a long-lived lifecycle that does not fit the Case escalation model cleanly. A custom Permit__c object with its own status lifecycle and a master-detail to a custom Inspection__c object gives the flexibility to model building, electrical, plumbing, and encroachment permits as record types with different required fields.

This avoids the trap of forcing permits into Cases with complex workarounds, while keeping 311 requests on a well-understood standard object.

The city will not operate its own identity provider (requirement 14). The correct approach is an Experience Cloud site with Experience Cloud self-registration using Salesforce as the authentication provider, combined with social login options (Google, Apple) where supported by the city’s digital accessibility and procurement requirements. This gives citizens a standard registration flow without the city building or maintaining auth infrastructure. (Note: “Salesforce Identity” as a product refers to Salesforce acting as an IdP for SSO into external third-party apps; it is not the right framing for citizen portal self-registration, which is handled natively by Experience Cloud’s self-registration flow.)

Guest user access (public permit record search, requirement 18) uses the Experience Cloud guest user profile with read-only access to a Permit Search page that queries Permit__c records directly. Guest user requests do not count against login licenses.

Decision 4: External Credential + Named Credential for All API Integrations

All three integrations (ArcGIS, CivicPay, PermitTrack batch) use Named Credentials in Salesforce to hold endpoint URLs and authentication tokens. This keeps credentials out of Apex code and makes endpoint management configurable by the IT team without code changes, directly addressing the IT Director’s concern (requirement 6).

System Landscape

Data Model

Core Objects

Object	Type	Purpose	OWD
Contact	Standard	Shared citizen record; one per person across departments	Public Read Only
Account	Standard	Citizen household or business; parent of Contact	Public Read Only
Case	Standard	311 service requests; record types per department	Private
Permit__c	Custom	Permit applications; record types per permit type	Private
Inspection__c	Custom	Inspection events; master-detail to Permit__c; optional lookup to Case (for 311/Case-based work such as pothole repairs and tree hazard inspections)	Controlled by Parent
Fee__c	Custom	Fee line items; master-detail to Permit__c	Controlled by Parent
Payment__c	Custom	Payment records from CivicPay; lookup to Permit__c	Private
Code_Violation__c	Custom	Formal violation records; lookup to Case	Private
Department__c	Custom	Department reference for role-based scoping	Public Read Only

Permit Record Types

Building Permit: full structural review fields, energy compliance checklist
Electrical Permit: panel details, load calculations, inspector certification
Plumbing Permit: fixture count, water service connection, backflow prevention
Encroachment Permit: ROW location, duration, traffic control plan attachment

311 Case Record Types

Public Works: pothole, tree hazard, illegal dumping
Code Enforcement: graffiti, code complaint, property maintenance
Planning: zoning inquiry, nuisance report

Key Relationships

Shared Citizen Contact: The Architecture Tension Resolved

The Contact record is the single citizen identity across departments. When a citizen registers on the portal, Experience Cloud creates one Contact. All permit applications and 311 cases link to that Contact via lookup. The Contact OWD is Public Read Only, so any department can find a citizen when they call in, but the cases and permits linked to that contact remain private to the owning department.

A Duplicate Rule on Contact using the standard Standard Contact Duplicate Rule (match on email + name + address fuzzy) prevents duplicate portal registrations. The pre-migration deduplication process (requirement 11) uses Data Loader + external dedup tooling before import.

Integration Architecture

ArcGIS: Synchronous Address Validation + Asynchronous Permit Push

Inbound address validation (requirement 21): When a citizen submits a permit application through the portal, a Screen Flow calls an invocable Apex action that makes a synchronous callout to the ArcGIS REST parcel lookup endpoint. If a parcel match is returned, the normalized address and parcel ID are written to the permit record and submission proceeds. If no match is returned, the permit is saved with a status of Pending Address Review and assigned to an intake queue. The application is not rejected. This addresses the explicit requirement that unmatched addresses go to manual review, not automatic rejection.

Outbound parcel history update (requirement 22): When a permit is approved, a Platform Event (PermitApproved__e) is published. A trigger-based subscriber Apex class consumes the event and makes a REST callout to ArcGIS to push the permit summary to the parcel history layer. Because the trigger fires asynchronously after the approval transaction commits, the permit approval itself has no dependency on ArcGIS availability. If the callout fails, the subscriber Apex throws EventBus.RetryableException to trigger a retry. Platform Events are retained for 72 hours, giving the retry window time to recover from transient ArcGIS outages. After the maximum number of retries is exhausted, the failure is logged to an Integration_Error_Log__c record for manual review by the IT team. No automatic Case creation occurs on max retry failure.

CivicPay: REST Payment Processing (PCI Scope Reduction)

Payment flow (requirement 23): The portal’s payment page renders CivicPay’s hosted payment iFrame (a standard CivicPay integration pattern). Card data is entered directly in CivicPay’s iframe and never touches Salesforce DOM or storage. Salesforce is entirely outside PCI scope for cardholder data.

After the citizen completes payment, CivicPay calls a Salesforce Apex REST endpoint with a payment confirmation or failure payload. The External Client App (ECA) provides OAuth 2.0 authentication for this callback. It is not a public REST endpoint but an authenticated integration entry point secured via OAuth client credentials. A Flow triggered by the incoming webhook creates or updates the Payment__c record and updates the Permit__c payment status field. The 5-minute sync requirement (requirement 23) is met by CivicPay’s real-time callback; there is no polling.

PermitTrack: One-Time Batch CSV Migration

No real-time integration with PermitTrack is required or built. All data exchange is one-way, one-time, via structured CSV export. See Migration Strategy section for sequencing.

Role Hierarchy

City of Millbrook (Root)
  City Manager
    Public Works Director
      Public Works Supervisor
        Public Works Inspector
    Planning Director
      Planning Supervisor
        Planning Staff
    Code Enforcement Director
      Code Enforcement Supervisor
        Code Enforcement Officer
  IT Director (System Admin profile)

OWD Settings

Object	OWD	Rationale
Contact	Public Read Only	Shared citizen identity; all departments can view, none can edit across departments
Account	Public Read Only	Same as Contact
Case	Private	Department isolation; cases visible only to owner and above in role hierarchy
Permit__c	Private	Department isolation
Inspection__c	Controlled by Parent	Inherits from Permit__c
Fee__c	Controlled by Parent	Inherits from Permit__c
Payment__c	Private	Financial data; scoped to permit-owning department
Code_Violation__c	Private	Code Enforcement only

Profiles and Permission Sets

User Group	License	Profile	Key Permission Sets
Public Works Staff	Salesforce	Public Works User	Permit Read/Write, Inspection Manage
Planning Staff	Salesforce	Planning User	Permit Read/Write, Planning Review Stage
Code Enforcement	Salesforce	Code Enforcement User	Case Read/Write, Violation Manage
Department Supervisors	Salesforce	Supervisor (per dept)	Bulk Reassignment, Dashboard Admin
IT Admin	Salesforce	System Administrator	All
Citizen Portal Users	Customer Community Login	Citizen Self-Service	Own Permits, Own Cases, Own Payments
External Reviewers	Customer Community Plus Login	External Reviewer	Read Case/Permit in review stage, submit comments
City Council	Salesforce (read-only)	Council Dashboard	Report Run only, no record access
Guest (public)	None	Guest User	Permit public search page only

External Third-Party Reviewers (Requirement 34)

Fire marshal and utility reviewers need to view permit documents and submit comments during one review stage. The correct license is Customer Community Plus Login, not basic Customer Community Login. Basic Customer Community supports only Sharing Sets, not criteria-based sharing rules, role hierarchies, or Apex managed sharing; Customer Community Plus (Login variant) adds those capabilities at a modest cost increase and is the minimum license that supports the sharing rule pattern used here. Each external reviewer gets a portal account with a restricted profile that grants:

Read access to Permit__c during the External Review status only, enforced via a criteria-based sharing rule that grants read to a dedicated “External Reviewers” public group when Permit__c.Status = "External Review"
Create access to a custom Review_Comment__c object (lookup to Permit__c)
No access to Case, Contact, or other department data

Customer Community Plus Login keeps reviewers out of the internal user base and is still meaningfully cheaper than a full Salesforce license for low-frequency external access. A named credential is not needed. These users authenticate via the portal.

Why not basic Customer Community Login?

Basic Customer Community (Member and Login variants) only supports Sharing Sets for external record access. A Sharing Set grants access when a field on a record matches a field on the user’s Contact or Account, which does not fit the “access when Permit status = External Review” pattern described here. Customer Community Plus (Member and Login) adds criteria-based sharing rules, role hierarchies, and Apex managed sharing, which are all available to licenses that expose the role hierarchy. For this requirement, Plus Login is the minimum viable license.

Guest User Access (Requirement 18)

The public Permit Search page on the Experience Cloud site runs under the site’s Guest User profile. Guest users always have a Private external OWD on every object; guest user record access is granted only through guest user sharing rules, and guest users cannot participate in role hierarchies, manual sharing, or criteria-based sharing rules targeted at authenticated users. The design is:

Guest user profile: Minimum Access profile with Read object permission on Permit__c and no access to any other object. No field-level access to applicant contact fields (Permit__c.Applicant_Name__c, Permit__c.Applicant_Email__c, Permit__c.Applicant_Phone__c are all FLS-denied for the guest profile).
Guest user sharing rule on Permit__c: a guest user record-sharing rule grants Read access when Permit__c.Is_Public__c = true AND Status IN ("Issued", "Final", "Closed"). Draft, in-review, and denied permits are not exposed. The Is_Public__c checkbox defaults to true for building and encroachment permit record types and false for code enforcement-linked records.
External OWD on Contact and Account: internal Contact / Account OWD remains Public Read Only for internal staff, but external OWD is set to Private so that authenticated portal users and the guest user profile cannot see any Contact or Account records through Experience Cloud. External users only see their own Contact via the site’s implicit Account-to-Contact sharing.
No guest user access to Case or Code_Violation: standard object permissions withheld for the guest profile.

Guest user requests do not consume login licenses. Guest users cannot be granted manual sharing, cannot be listed in role hierarchies, and cannot appear in groups used by criteria-based sharing rules targeting authenticated users, so the guest user sharing rule above is the only mechanism for public record exposure. The design also satisfies the “Secure guest user record access” setting (enforced since Winter ‘22), which requires all guest access to go through explicit guest user sharing rules.

Department Data Isolation: The Exact Mechanism

Each Permit__c and Case record is stamped with a Department__c lookup at creation (set automatically by the record type default or a before-insert Flow). OWD is Private. The role hierarchy ensures supervisors see their team’s records. No sharing rules are needed between departments: isolation is the default. The only cross-department visibility is the City Manager role (sits at root, sees all) and the cross-department reporting dashboard (uses a System-level running user on the report, accessible only via the City Manager’s dashboard folder).

Audit Trail (Requirement 31)

Field History Tracking is enabled on all key fields across Permit__c, Inspection__c, and Case (status, owner, decision fields). Salesforce retains field history for 18 months natively. For the 7-year retention requirement, a scheduled Data Export to an external archive (city-managed cloud storage) runs monthly and stores field history records as immutable CSVs. Note: Field Audit Trail (a Shield add-on) would extend retention to up to 10 years natively within Salesforce, but it is not required here given the budget constraint. The scheduled export approach covers the requirement at no additional license cost. Event Monitoring is a separate Shield capability that captures access telemetry (login events, URI events, report events) and is not the same as field change history. The two are complementary, not interchangeable.

Migration Strategy

Source-to-Target Mapping

Source	Records	Target Objects
PermitTrack permit applications	~47,000	Permit__c (4 record types)
PermitTrack inspection events	~210,000	Inspection__c (master-detail)
Code Enforcement Excel workbook	~14,000 rows	Case (Code Enforcement record type)
Word document case notes	Variable	ContentNote or ContentDocument on Case

Pre-Migration Steps

Address normalization (requirement 10): Export PermitTrack addresses to CSV. Run each address through the ArcGIS geocoding REST endpoint in batch (Python script). Write normalized address and parcel ID back to the staging CSV. Flag records with no parcel match for manual review (separate queue).
Contact deduplication (requirement 11): Merge contact records from PermitTrack applicant data and the Excel workbook using email as the primary match key, then name + address fuzzy match for records without email. Use a tool such as Data Loader + Excel deduplication logic or a lightweight ETL script. Output: a deduplicated Contact staging file with a source-system-to-Salesforce-ID mapping table.
Excel case note extraction (requirement 9): Parse the Word documents using a Python script to extract notes per case ID. Create a CSV of case ID to note text. These will be imported as ContentNote records after Cases are created.

Migration Sequence

Phase 1 (4 weeks before cutover):
  - Stand up Salesforce sandbox with full configuration
  - Run trial migrations with production data volume
  - Validate record counts and spot-check field mapping
  - Resolve address normalization exceptions manually

Phase 2 (2 weeks before cutover):
  - Delta migration of any PermitTrack records created since Phase 1
  - Full Code Enforcement Excel import to sandbox
  - Validate all parent-child links (Permit to Inspection)

Phase 3 (Cutover weekend):
  - Saturday 18:00: PermitTrack set to read-only by IT
  - Saturday 18:00 to Sunday 06:00: Final delta export and production import
  - Sunday 06:00: Automated reconciliation scripts run (record counts, spot sample of 500 records)
  - Sunday 08:00: Go/No-Go decision by IT Director and City Manager
  - Sunday 10:00: Portal opens, internal staff given go-live communication

Phase 4 (Days 1-90 post go-live):
  - PermitTrack remains accessible read-only on internal network
  - Lookup procedure documented for staff: if a citizen references an old permit not visible in Salesforce, IT provides a PermitTrack lookup guide
  - Day 90: PermitTrack decommissioned

Rollback Criteria (Requirement 12)

If the Sunday 06:00 reconciliation shows record count variance greater than 0.1% on parent records, or any child records with broken parent links, the migration team does not proceed to go-live. The production org is wiped (it has no active user data yet), and the team reverts to PermitTrack for the week while the root cause is investigated. Zero data loss is enforced by requiring exact count match on permit applications before cutover approval.

Reporting Approach

Access Tiers

Audience	Access Mechanism	Scope
Department heads	Standard dashboard, folder shared to role	Own department only
City Manager	Dashboard with system-context running user	All three departments
City Council	Dedicated dashboard folder, view-only access	Aggregate metrics, no record detail
Department analysts	Report Builder, restricted by role	Own department only (OWD enforcement)
Inspector supervisors	Standard dashboard	Own team’s inspection records

Department Head Dashboards (Requirement 25)

Each department head gets a dashboard in a folder shared to their role (and above). The dashboard draws from reports running as the logged-in user, which means OWD enforcement applies automatically. A Planning Director running the dashboard sees only Planning permits. Components: open cases/permits by status, average resolution time (formula field on Case/Permit close date minus created date), cases by type (donut chart), overdue items (filtered on SLA breach flag set by escalation rule).

City Manager Cross-Department Dashboard (Requirement 26)

The City Manager’s dashboard uses reports with running user set to a dedicated System Context User (an internal user with read access to all records via a permission set). The System Context User is created, frozen immediately (preventing interactive login), and set as the dashboard running user. The frozen status does not affect dashboard execution. Freezing blocks interactive login only, not dashboard or report evaluation. This running user pattern is the standard approach for cross-department reporting in private-OWD orgs. The dashboard displays total 311 volume, average resolution time by department (grouped summary), permit throughput, and citizen satisfaction (if surveys are implemented via Salesforce Surveys or a survey component in the portal).

City Council View (Requirement 27)

City Council members receive Salesforce licenses with a read-only profile that can access only the Council Metrics dashboard folder. Reports in this folder aggregate at the city level (record counts, completion rates, pass/fail rates) and do not expose individual case IDs, citizen names, or contact information. This satisfies both the reporting requirement and Washington State public records law. Aggregate statistics are not subject to individual disclosure restrictions.

Schedulable Reports (Requirement 28)

Standard Salesforce report scheduling is used. Department heads subscribe to reports with monthly email delivery. No IT involvement is required. This is a user-configurable feature in the Reports tab.

Ad Hoc Report Scoping (Requirement 29)

Because OWD on Case and Permit__c is Private and role hierarchy is department-aligned, any report a Planning analyst runs is automatically limited to records they have read access to. There is no way for a Planning analyst to inadvertently return Code Enforcement records. The sharing model enforces this at the data layer, not at the UI layer. No custom report type restrictions are needed.

Inspector Workload Reports (Requirement 30)

A Summary report on Inspection__c grouped by Assigned Inspector (a lookup field to User on Inspection__c) shows completion rates and overdue counts. This report is in the supervisor’s dashboard folder. The Overdue field is a formula: if the scheduled inspection date is past and status is not Completed, the record is flagged. Escalation rules notify the supervisor when overdue count exceeds a configurable threshold.

Requirements Addressed

Req	Addressed by
1: Single org	Single org design; multi-org rejected explicitly
2: Department data isolation	Private OWD on all case/permit objects; role hierarchy scoped per department
3: Shared citizen contact	Contact OWD Public Read Only; Duplicate Rules enforce one record per citizen
4: 110 staff + 5,000 portal users	Salesforce licenses for staff; Customer Community Login licenses for portal citizens
5: Appropriate license types	Salesforce (internal), Customer Community Login (portal citizens), Customer Community Plus Login (external reviewers — required for criteria-based sharing), read-only Salesforce (City Council)
6: IT-maintainable	Configuration-first approach; no custom Apex except integration callouts; Named Credentials for endpoints
7: 47,000 permit records migrated	PermitTrack CSV batch migration via Data Loader; full field mapping
8: 210,000 inspection records migrated	Inspection__c batch import; parent-child link validated in reconciliation step
9: 14,000 Excel rows + Word notes migrated	Case batch import; ContentNote records for case notes
10: Address normalization	Pre-migration ArcGIS geocoding batch script; normalized address written back to staging CSV
11: Contact deduplication	Pre-migration dedup pass; Duplicate Rules active in org post-import
12: Cutover plan + zero data loss	Three-phase migration; reconciliation checkpoint; explicit rollback criteria
13: PermitTrack read-only 90 days	PermitTrack left on internal network in read-only mode; procedure documented
14: External identity for portal auth	Experience Cloud self-registration with Salesforce as the authentication provider; social login option; no city-operated IdP
15: Permit application and tracking	Screen Flow in portal for 4 permit types; real-time status via Experience Cloud page
16: 311 filing and tracking	Case record types in portal; citizen can view own cases
17: Online payment via CivicPay	CivicPay hosted iFrame in portal; Payment__c record created on callback
18: Public permit search (unauthenticated)	Guest user profile; public Permit Search page on Experience Cloud site
19: Mobile browser support	Experience Cloud LWR site is responsive by default; no native app required
20: Email notifications	Flow-triggered email alerts at each status transition; standard email templates
21: ArcGIS address validation at submission	Synchronous callout in Screen Flow; no-match sends to Pending Address Review queue
22: ArcGIS parcel update on approval (async)	Platform Event published on approval; subscriber Apex makes async callout
23: CivicPay payment processing, no card storage	CivicPay hosted iFrame; webhook callback updates Payment__c within 5 minutes
24: PermitTrack batch CSV import only	No real-time integration built; one-time Data Loader import
25: Department head dashboards (scoped)	Dashboard per department; OWD-enforced reports; running-user = logged-in user
26: City Manager cross-department dashboard	System Context User as running user; all-departments summary
27: City Council aggregate metrics	Council Metrics dashboard folder; no record-level detail
28: Schedulable monthly reports	Standard Salesforce report subscription feature
29: Ad hoc report isolation	OWD private enforcement; no additional restrictions needed
30: Inspector workload tracking	Inspection__c summary report by assigned inspector; supervisor dashboard
31: 7-year audit trail	Field History Tracking (18 months native) + monthly scheduled export to city archive storage. Field Audit Trail (Shield) would extend native retention to 10 years but is not required given budget. Event Monitoring captures access telemetry separately and is not a substitute for field change history.
32: Multi-step permit workflow with SLAs	Approval Process for supervisor sign-off; Entitlement Process or Escalation Rules for SLA
33: Photo attachments on mobile	Files + ContentDocument on Case; Experience Cloud mobile browser supports file upload
34: External third-party reviewers	Customer Community Plus Login licenses (required to support criteria-based sharing); restricted profile; sharing rule on External Review status
35: Bulk case reassignment by supervisor	Standard Mass Transfer functionality; supervisors have the Mass Transfer permission

Risk Assessment

Risk 1: Contact Deduplication Quality at Migration

Description: PermitTrack and the Excel workbook both contain citizen data without consistent email fields. Fuzzy name+address matching will produce false positives (merging different people) and false negatives (leaving true duplicates separate). Poor deduplication creates fragmented citizen histories and confuses the shared-contact model.

Likelihood: High. This is a 20-year-old Windows application with no email mandate.

Mitigation: Run two independent dedup tools (e.g., OpenRefine + a Python Levenshtein script) and compare outputs. Where tools disagree, flag for manual review by a department representative. Accept a small percentage of unresolved duplicates at go-live and remediate post-launch via an ongoing Duplicate Management dashboard. Do not hold go-live for cosmetic dedup issues. Hold it only for structural breaks (permits with no linked contact).

Risk 2: ArcGIS Availability During Summer Peak

Description: If ArcGIS is unavailable and the permit submission flow cannot complete address validation, citizens receive errors at the worst possible time (summer construction season, peak permit volume).

Likelihood: Medium. ArcGIS is actively maintained but not SLA-guaranteed for the Salesforce integration endpoint.

Mitigation: The flow already puts no-match records into a Pending Address Review queue rather than rejecting. Extend this logic: if the ArcGIS callout times out or returns an HTTP 5xx error, the permit is saved with status Pending Address Review and a system note indicating the geocoding service was unavailable. Staff manually validate the address before advancing the application. This degrades gracefully without blocking citizens.

Risk 3: Budget Pressure Leading to Configuration Shortcuts

Description: At $2.1M with no contingency and a hard Q2 FY2026 deadline, the implementation team faces pressure to cut scope. The risk is that configuration shortcuts (e.g., hard-coded department labels in Apex, merged profiles instead of separate ones, skipping the External Review sharing rule) create a system that is difficult for the three-person IT team to maintain.

Likelihood: Medium-High in any fixed-price government project.

Mitigation: Establish a Scope Change Board in the project charter with the IT Director as voting member. Any configuration shortcut must be documented as technical debt with a remediation task before the IT team accepts support responsibility. The IT Director should sign off on the maintainability of each configuration decision before the implementation team closes out that workstream.

Risk 4: Washington State Public Records Law and Experience Cloud Data

Description: Washington State’s Public Records Act (RCW 42.56) requires disclosure of most government records on request. Permit records submitted through Experience Cloud by citizens may be subject to disclosure requests. If the org is not configured correctly, a bulk export for a public records request could expose citizen contact data, email addresses, or case notes beyond what the law requires.

Likelihood: Medium. The city’s legal team will receive a public records request for permit data within the first 12 months.

Mitigation: Before go-live, the city attorney reviews which Permit__c fields are disclosable and which are exempt (e.g., applicant home address if different from permit site address, certain Code Enforcement complainant identities). Create a Public Records Export report type that includes only disclosable fields. Document the field exemption logic in the system’s data dictionary so the IT team can respond to disclosure requests without requiring legal review each time.

Domain Scoring Notes

System Architecture Probes

A board examiner is likely to push on three points in this scenario:

“Why not a separate org for Code Enforcement since they handle sensitive complaints?” The answer is that the City Manager’s budget constraint eliminates multi-org regardless of theoretical preference, and Private OWD with a separate role branch achieves the isolation goal within a single org. The architecture delivers the outcome (isolation) without the cost or complexity of a second org.

“How does the shared citizen contact survive when two departments both create records for the same person?” Duplicate Rules at the point of record creation prevent this in the live system. The pre-migration dedup addresses the historical data. The Contact OWD being Public Read Only means any department can find an existing contact before creating a new one. Staff are trained to search before creating.

“You said ArcGIS is fire-and-forget. What if 500 permits are approved in one day and ArcGIS falls behind?” Platform Events are processed asynchronously and Salesforce’s event bus can handle high volumes. The subscriber Apex is designed to be idempotent (checking if the parcel record already has this permit before pushing). If the queue backs up, records catch up once ArcGIS recovers. No data is lost. The event bus retains events.

Data Domain Probes

“How do you enforce the 7-year audit trail without Shield?” Field History Tracking (native, no additional cost) covers 18 months in the UI. A scheduled Apex job exports field history records monthly to an external storage destination maintained by the city. The IT team maintains the export procedure. This is documented and testable, not a hand-wave. Field Audit Trail (the Shield add-on) would extend native retention to 10 years and simplify compliance, but is not in scope given the budget constraint. Event Monitoring is a separate capability that captures access telemetry. It does not record field change history and cannot substitute for Field History Tracking in this context.

“What’s the dedup strategy for 47,000 + 14,000 records from two different systems?” The answer must include: (a) a primary match key (email), (b) a secondary match strategy for records without email (name + normalized address), (c) a tool for the actual matching, (d) a human review process for uncertain matches, and (e) a documented acceptable residual error rate. Vague answers here indicate shallow understanding of migration practice.

What Would Fail This Solution

Anti-Pattern 1: Separate Apps with Separate Orgs

Recommending a Connected App or a second org to isolate Code Enforcement fails the explicit City Manager requirement and the budget constraint. If you went here, you either misread the scenario or anchored on theoretical best practice without hearing the stakeholder constraint. Boards penalize designs that ignore explicit client directives.

Anti-Pattern 2: Recommending a Full External IdP for Citizen Self-Registration

Requirement 14 says the city will not operate its own identity provider. An Experience Cloud site with Salesforce as the authentication provider for self-registration (which handles registration and password reset without the city running any infrastructure) is the correct read. Recommending a full external IdP (Okta, Azure AD) is over-engineering for a 5,000-user citizen portal with a $2.1M budget, and adds ongoing vendor cost the city has not approved. (Salesforce Identity as a product is for Salesforce acting as an IdP for SSO into third-party apps, not for citizen portal self-registration.)

Anti-Pattern 3: Storing Payment Tokenization Data in Salesforce

Any design that touches card data in Salesforce (whether through a custom payment form, a stored card token in a Payment__c field, or any mechanism that routes card numbers through the Salesforce server) puts Salesforce in PCI scope and creates a compliance problem the city cannot manage with three IT staff. The CivicPay hosted iFrame pattern is the only acceptable design. The solution must be explicit that card data never enters Salesforce.

Scoring Rubric

Criterion	Weight	Full Credit	Partial Credit
Org and sharing model	25%	Private OWD, correct role hierarchy, Contact isolation exception explained, External Review sharing rule	OWD mentioned without hierarchy, or isolation mechanism vague
Data model and migration	25%	Permit__c + Inspection__c + Case separation, dedup strategy, address normalization, cutover plan with rollback	Objects correct but migration plan incomplete
Integration architecture	20%	ArcGIS sync + async, CivicPay hosted iFrame, no card data in SF, Platform Event for async	Integrations described but patterns not named, or sync/async distinction missing
Portal and identity	15%	Experience Cloud LWR, Experience Cloud self-registration (Salesforce as auth provider), guest user for public search, mobile support	Portal mentioned without license model or auth approach
Reporting and governance	15%	Three-tier reporting (dept, cross-dept, council), running user pattern, OWD enforcement on ad hoc, 7-year audit export	Dashboards mentioned without isolation mechanism

Self-Assessment Checklist

Did I address the shared citizen contact vs. department isolation tension explicitly, not just acknowledge it?
Did I name the specific Salesforce license type for portal citizens (Customer Community Login) and external reviewers (Customer Community Plus Login, required for criteria-based sharing)?
Did I explain how City Council sees aggregate data without accessing individual records?
Did I describe the CivicPay integration as a hosted iFrame and explain why card data never touches Salesforce?
Did I include a rollback criterion and go/no-go checkpoint in the migration plan?
Did I address what happens when ArcGIS is unavailable at permit submission (not just at permit approval)?
Did I name the running user pattern for the City Manager cross-department dashboard?
Did I cover the 7-year audit requirement with a specific retention mechanism, not just “enable Field History Tracking”?

Q&A Prep

Q: The City Manager said “proper walls between departments.” How do you define proper walls and where do they break down intentionally?

Proper walls means Private OWD on all operational objects (Case, Permit__c, Inspection__c) with a role hierarchy that restricts visibility to each department’s branch. The intentional exception is the Contact object, which is Public Read Only so that any department can find a citizen without creating a duplicate. The walls hold for everything the City Manager cares about: case notes, permit details, officer records, fee and payment data. The contact record is shared specifically because deduplication is a business requirement: a citizen who calls Public Works and then files a 311 complaint should appear as the same person, not two strangers.

Q: You put 311 requests on the standard Case object. Why not a custom object?

Case gives us Entitlements, Escalation Rules, Email-to-Case for the existing shared inbox, and a built-in SLA framework. All of those are requirements: SLA escalation (requirement 32), email notifications (requirement 20), and the existing phone/email intake route. Building these capabilities on a custom object means building them from scratch in Flow and Apex, which is more code for the IT team to maintain. Configuration over code is an explicit directive.

Q: How do you handle the PermitTrack 90-day read-only period operationally?

PermitTrack stays running on the internal network with a read-only flag set at the database layer by IT. Staff are given a one-page lookup guide: if a citizen references a permit number that is not in Salesforce (possible only for very old records outside the 5-year migration scope), they open PermitTrack, look it up, and read the details to the citizen. After 90 days, PermitTrack is decommissioned and the archived CSVs serve as the permanent record for pre-migration data.

Q: External reviewers need to comment on permits. Why not give them a Salesforce Community profile on the full Experience Cloud site?

They do get an Experience Cloud license, specifically Customer Community Plus Login. That IS the portal. The Plus license is required because basic Customer Community (Login or Member) supports only Sharing Sets, which cannot express “status equals External Review” across all permits; Plus adds criteria-based sharing rules, role hierarchies, and Apex managed sharing. The distinction is profile and permission set restrictions on top of the Plus license. Reviewers cannot see Case records, Contact records, or anything outside the permits currently in External Review status. A criteria-based sharing rule grants read access to Permit__c when status = External Review. A custom Review_Comment__c object with a public-write/read-own sharing model lets them submit comments. Customer Community Plus Login licenses are still meaningfully cheaper than internal Salesforce licenses and appropriate for part-time external access.

Q: Planning Director Sofia Ramos said preliminary conversations with applicants are confidential until formal submission. How do you handle pre-submission confidentiality?

Pre-submission permit applications can be saved in Draft status, visible only to the Planning staff member who created the record and their supervisor. The OWD private model enforces this. A draft permit is owned by the creating user, and no other department can see it. When the applicant submits formally (changes status from Draft to Submitted), standard intake workflow begins. The key is that Draft status records are not shared via any cross-department sharing rule.

Q: What if the IT Director’s team of three cannot keep up with post-go-live support requests?

The architecture is designed for low maintenance overhead: configuration-first, no custom Apex beyond integration callouts, Named Credentials for all endpoints, Flow for automation. Post-go-live, the three main support categories are: (a) user access issues (handled via permission set assignments, no code), (b) report and dashboard changes (handled by department super-users trained during go-live), and (c) integration errors (Named Credential rotation and error queue monitoring). If volume exceeds the team’s capacity, the IT Director should escalate to City Council for a support retainer, but the architecture does not create this need artificially.

Q: How do you prove zero data loss after migration?

Before cutover, the team runs a record count query against the PermitTrack SQL Server database for each table being migrated. After import, a corresponding SOQL count query on Salesforce must return matching numbers. For a 0.1% variance threshold: 47,000 permits allows for 47 discrepancies maximum before triggering rollback. Spot-sampling validates field-level accuracy. A random 500 permit records are compared field-by-field between PermitTrack and Salesforce by a data analyst before go-live sign-off.

Q: The portal needs WCAG 2.1 AA accessibility. How does Experience Cloud address this?

Experience Cloud LWR (Lightning Web Runtime) sites use semantic HTML and meet WCAG 2.1 AA for standard components. Any custom LWC built for the portal must be tested with a screen reader (NVDA or JAWS) and a color contrast analyzer before launch. The CivicPay payment iFrame must also be WCAG AA compliant. This is a procurement checkpoint the city should verify with CivicPay before go-live, as they are an existing contract partner.

Q: Inspector field access: can a Code Enforcement officer see a Public Works inspector’s inspection notes?

No. Inspection__c records are in a master-detail with Permit__c (OWD Private). A Code Enforcement officer’s role is in the Code Enforcement branch of the hierarchy. They have no read access to Public Works Permit__c records, and therefore no access to their child Inspection__c records. The role hierarchy and OWD together enforce this without any additional configuration.

Q: The Planning Director said staff are not tech-savvy. How do you accommodate that in the portal and internal UI?

In the portal, Screen Flows guide citizens through permit applications step-by-step with contextual help text and validation messages in plain language. Internally, the Planning profile uses a simplified App Page layout with only the fields relevant to Planning workflows. Record Types limit the objects and fields visible to each department. Flows handle status transitions with guided prompts rather than requiring staff to manually update multiple fields. The goal is that a Planning staff member can process a standard permit application without needing to understand the broader data model.

Q: You mentioned a System Context User for the City Manager dashboard. How do you prevent that user from being used for interactive login?

The System Context User is an internal Salesforce user with a profile that has no UI access: no tab visibility, no app launcher items, no record access beyond report execution. The user’s password is generated once, stored in a vault by IT, and never shared. The user is frozen immediately after setup. Freezing prevents interactive login but does not affect dashboard or report execution, so the user continues to function as the dashboard running user while frozen. An IP restriction policy and login hours of 00:00-00:01 provide additional safeguards. This is a standard reporting pattern for cross-OWD dashboards.

Q: What is the biggest risk to the Q2 FY2026 go-live deadline?

Address normalization. The PermitTrack database has 47,000 permit applications with inconsistent address formats accumulated over 20 years. Running these through ArcGIS geocoding, resolving no-match records manually, and iterating until the exception list is small enough for go-live is the longest-pole task in the migration. It cannot be parallelized easily because each no-match requires a human decision. Starting the address normalization process in the first month of the project (not two weeks before cutover) is the single most important schedule mitigation action.

Presentation Notes

When presenting this solution in a board setting, lead with the two tensions the scenario is built around: department isolation vs. shared citizen identity, and configuration simplicity vs. complex requirements. Boards reward candidates who name the tension, explain why it is a tension, and then show a specific mechanism that resolves it. Vague statements like “we would use appropriate security settings” score poorly. Saying “Contact OWD is Public Read Only while Permit OWD is Private, and here is why that combination works” demonstrates architectural precision.

For the migration, lead with process before data. Boards want to hear that you have thought about rollback, reconciliation, and what happens when it goes wrong. Candidates who only describe the happy path fail the data domain.

For integrations, name the pattern explicitly: synchronous callout, fire-and-forget Platform Event, one-time batch CSV. Then explain the failure handling for each. ArcGIS and CivicPay both have availability dependencies; the board will probe here.

For the external reviewer requirement, be ready to compare Customer Community Plus Login vs. a full Salesforce license and explain the cost difference. Expect a probe on why basic Customer Community Login cannot be used (Sharing Sets only, no criteria-based sharing rules). Government clients are budget-constrained and boards value candidates who think about licensing cost alongside technical elegance.

Always verify against official Salesforce documentation

This content is study material for CTA exam preparation. Content compiled and presented with AI assistance. Not affiliated with Salesforce.

Personal study notes for the Salesforce CTA exam. Content compiled from VJ's study notes, official Salesforce documentation, community sources, and online publicly available content, then organized and presented with AI assistance. Not affiliated with Salesforce. © 2025–2026 VJ Srivastava.