Skip to content
theCodeFlash

Scenario 08: MetroServe City Services

Work in Progress

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

Scenario Snapshot

FieldDetail
Start hereThis question page
DifficultyMedium
IndustryGovernment / Municipal
Heavy domainsSystem Architecture and Data
Recommended prep window180 minutes total: 120 min preparation + 30 min presentation + 30 min Q&A
Coverage availableQuestion + Solution
Study flowAttempt this page first, then review the sibling solution page after your own attempt.

Recommended Approach

Print this scenario. Read it twice using the Two-Pass Reading Method: once for understanding and once to surface implicit requirements. Then build your architecture within a focused 90-minute window before opening the solution.

Project Overview

The City of Millbrook (population 120,000) is a mid-size municipality in the Pacific Northwest. The city provides services through four major divisions, three of which are in scope for this project: Public Works, the Planning and Development Department, and Code Enforcement. A fourth division, the Millbrook Police Department, operates independently and is out of scope.

For 20 years, Millbrook’s permit and inspection workflows have lived in two aging systems that no longer meet operational needs. The mayor has directed an IT modernization program (internally called “Millbrook Connects”) with two parallel goals: replace the legacy permit and inspections platform with Salesforce Service Cloud, and launch a citizen self-service portal (Experience Cloud) that handles permit applications, payment, and 311-style non-emergency service requests.

The project is funded in the city’s current two-year capital budget cycle ($2.1M, FY2025-2026). The City Council must approve any scope or budget changes before Q3 2025 elections.

AttributeDetail
Population120,000
Departments in scopePublic Works, Planning and Development, Code Enforcement
Total city employees640
Staff in scope110 (all three departments combined)
Permits issued per year~9,500 across building, electrical, plumbing, and encroachment types
311 service requests per year~18,000 (potholes, illegal dumping, graffiti, tree hazards, code complaints)
Budget$2.1M over 24 months (FY2025-FY2026)
GIS systemEsri ArcGIS (city-owned, staying in place)

Stakeholder Positions

City Manager Diana Cheung: “Every department thinks it deserves its own system, but we are a 640-person organization. I will not approve three separate Salesforce contracts. Find a way to share a single environment (with proper walls between departments) and bring this in under budget.”

Public Works Director Marcus Obi: “My inspectors cover the whole city every day. If the new system goes down or is slow, I lose field productivity. I also need assurance that Code Enforcement cannot see Public Works case notes. There have been… political sensitivities.”

Planning Director Sofia Ramos: “Planning cases involve preliminary conversations with applicants that are confidential until a formal submission. We need to control who sees what at each stage. And our staff are not very tech-savvy, so the interface needs to be simple.”

IT Director Paul Grewal: “We have three people who can support a Salesforce org. Whatever is built has to be maintainable by a small team. I am worried about over-customization. Keep it close to standard configuration.”

Current Systems

PermitTrack (Legacy Permit System)

PermitTrack is a Windows-based client-server application deployed in 2004 and maintained under vendor end-of-life since 2019. It is used by Public Works and Planning for permit issuance, inspections scheduling, and fee tracking. The vendor no longer issues security patches. The database is Microsoft SQL Server 2012.

PermitTrack holds approximately 5 years of active records and a partial archive going back to 2009. Full historical exports are available as structured CSV files with consistent schema. Total estimated record count: 47,000 permit applications and 210,000 associated inspection events.

Code Enforcement Spreadsheets

Code Enforcement currently tracks all complaints and violations in a shared Excel workbook on a network drive. The workbook has grown to 14,000+ rows covering the past 4 years. There is no formal archive for earlier records. Staff manually email status updates to complainants. Case notes are stored in a separate Word document directory.

GIS (Esri ArcGIS)

The city’s GIS system is current, actively maintained, and is not being replaced. It holds all parcel data, street centerlines, and city infrastructure layers. The Planning Department relies on GIS for zoning overlays on permit applications. Public Works uses GIS for work order routing. ArcGIS exposes REST APIs for parcel lookup, address geocoding, and map tile delivery.

311 Process (Current)

There is no formal 311 system. Citizens call a general city phone number or email a shared inbox. A part-time coordinator manually routes requests to the appropriate department each morning. There is no tracking, no SLA, and no way for citizens to check the status of their requests.

Payment Processing

Permit fees are currently collected over the counter or by check. No online payment capability exists. The city has a pre-negotiated contract with a payment processor (CivicPay) that provides a REST API for one-time and recurring payment processing. CivicPay is PCI DSS Level 1 certified.

Business Requirements

Org Strategy and Platform

  1. The three in-scope departments (Public Works, Planning and Development, and Code Enforcement) must operate within a single Salesforce org. Multi-org is not approved and not in budget.
  2. Each department must be isolated at the data layer: staff in one department cannot view cases, notes, or contact records belonging to another department during normal operations.
  3. A shared citizen contact record must exist across departments so that a citizen who files a permit application and a 311 request appears as one person, not three duplicate records.
  4. The platform must support at least 110 named internal users across the three departments plus up to 5,000 authenticated citizen portal users.
  5. Licensing must be appropriate to each user type: internal staff require full feature access; citizen portal users require only self-service access to their own records and public information.
  6. The IT Director must be able to manage the org without dedicated developer support. Configuration over code wherever feasible.

Data Migration

  1. All permit applications from PermitTrack dated within the past 5 years (approximately 47,000 records) must be migrated to the new system with full field mapping.
  2. All inspection event records associated with migrated permit applications (approximately 210,000 records) must be migrated and linked to their parent permit.
  3. Code Enforcement complaints and violations from the shared Excel workbook (approximately 14,000 rows) must be migrated. Case notes stored in separate Word documents must be migrated as related attachments or notes.
  4. Addresses in PermitTrack use inconsistent formats (abbreviations, missing unit numbers, non-standard street suffixes). All migrated addresses must be normalized against the Esri ArcGIS geocoding service before import.
  5. Duplicate citizen contact records are expected across both legacy sources. A deduplication pass must be performed before final migration to avoid fragmented citizen histories.
  6. A migration cutover plan must define the blackout window, rollback criteria, and data reconciliation checkpoints. Zero data loss is required; partial migration is not acceptable for go-live.
  7. After go-live, PermitTrack must remain available in read-only mode for 90 days to support permit lookups during transition.

Citizen Portal

  1. Citizens must be able to register for a portal account using their email address. The city will not operate its own identity provider; authentication must use an external identity approach appropriate for public-facing government services.
  2. Authenticated citizens must be able to submit new permit applications for the four permit types (building, electrical, plumbing, encroachment) and track application status in real time.
  3. Authenticated citizens must be able to file 311-style service requests across all three departments and track status through resolution.
  4. Citizens must be able to pay permit fees online through the portal using the CivicPay payment gateway. The portal must display payment status and receipt history.
  5. Citizens must be able to view public permit records for any property by parcel number or street address, without authentication. This is a public records requirement.
  6. The portal must be accessible on mobile browsers. No native mobile app is in scope.
  7. Citizens must receive automated email notifications at key status transitions: application received, additional information required, approved, inspection scheduled, inspection outcome, payment confirmed.

Integration

  1. The ArcGIS REST API must be called at permit application submission to validate and normalize the site address against city parcel data. If no parcel match is found, the application must be held for manual address review rather than rejected outright.
  2. When a permit application is approved, the system must push a permit record summary to ArcGIS to update the parcel’s permit history layer. The integration must be fire-and-forget (no blocking dependency on ArcGIS availability).
  3. Payment for permit fees must be processed through CivicPay’s REST API. The Salesforce org must not store card data at any point. Payment status (confirmed, failed, refunded) must sync back to the permit record within 5 minutes.
  4. PermitTrack historical records must be ingested via a one-time batch CSV import during the migration phase. No ongoing real-time sync with PermitTrack is required after go-live.

Reporting

  1. Each department head must have a dashboard showing their department’s open cases, average resolution time, cases by type, and overdue items. Each dashboard is scoped to that department’s own data only.
  2. The City Manager must have a cross-department dashboard showing total 311 volume, average resolution time by department, permit application throughput, and citizen satisfaction scores. This dashboard must draw from all three departments.
  3. City Council members must be able to view aggregate city-wide metrics (permit volumes, 311 resolution rates, inspection pass/fail rates) without accessing individual case records or citizen information.
  4. Monthly reports for department heads must be schedulable and deliverable via email without IT involvement.
  5. Ad hoc report builders within each department must be limited to their own department’s data scope. A Planning analyst must not be able to build a report that surfaces Code Enforcement records, even inadvertently.
  6. Inspection completion rates and overdue inspection counts must be tracked per inspector for workload management purposes, visible to department supervisors.

Additional Requirements

  1. All internal case records must carry an audit trail: who created the record, all status changes with timestamps and user attribution, and any field edits. Audit logs must be retained for a minimum of 7 years.
  2. The workflow for permit applications must support multi-step review: intake, technical review, supervisor approval, and issuance. Each step must have a configurable SLA with escalation notifications to the supervisor when SLAs are breached.
  3. Code Enforcement cases must support attaching photographs taken in the field. Field officers use Android and iOS devices.
  4. The Planning Department requires a review stage at which external third-party reviewers (fire marshal’s office, utility companies) are notified and can provide comments through a controlled access mechanism. These external reviewers are not city employees and must not have full internal user licenses.
  5. The system must support bulk reassignment of cases when an inspector or officer is on extended leave, executable by a supervisor without IT involvement.

Constraints

  • The project must be delivered within the approved FY2025-2026 capital budget ($2.1M). There is no contingency fund. Any scope change requires City Council approval, which adds a 6-10 week delay.
  • The city’s IT team has three staff members. Ongoing system maintenance must be supportable by this team post-go-live without a systems integrator retainer.
  • Go-live must occur before the end of Q2 FY2026 to allow permit processing to be operational before the summer construction season (the city’s peak permit period).
  • Government procurement rules require the city to use pre-approved state cooperative purchasing agreements or run a formal RFP for any vendor contract not already in place. CivicPay is already under contract.
  • All new city-facing applications must meet WCAG 2.1 AA accessibility standards per the city’s digital accessibility policy.
  • The solution must comply with Washington State public records law. Citizen-submitted records are potentially subject to public disclosure requests.

Implicit Requirements

The following are not stated as formal requirements but will drive architecture decisions:

  • How does a shared citizen contact record coexist with hard department-level data isolation?
  • What happens if ArcGIS is unavailable when a citizen submits a permit application?
  • What license type covers external third-party reviewers who need read/comment access without full internal seats?
  • How does the portal’s public permit search interact with Experience Cloud guest user limits?
  • CivicPay handles card data: what does that mean for data architecture and PCI scope on the Salesforce side?
  • Should 311 requests and permit applications share a Case object with record types, or live on separate objects?
  • PermitTrack stays live in read-only mode for 90 days post-cutover: how is that period managed operationally?

Deliverables Checklist

Work through the following before reviewing the solution:

  • Org strategy justification: single org rationale with data isolation approach documented
  • License model: internal users, citizen portal users, and external reviewers (license types and counts)
  • Data model: key objects, record types, relationships, and how shared citizen contact is handled
  • Sharing model: OWD settings, role hierarchy, and sharing rules for all three departments
  • Migration plan: source systems, record counts, deduplication approach, address normalization, cutover sequence
  • Integration architecture: ArcGIS (synchronous address validation + async parcel update), CivicPay (payment + sync-back), PermitTrack batch import
  • Portal design: authentication approach, guest vs. authenticated access, notification flows
  • Reporting architecture: department-scoped vs. cross-department vs. public-facing access tiers
  • Risk register: at least 4 risks with mitigation strategies

Time Management: 180-Minute Practice Session

Prep, first 40 min: Read the scenario twice. Build your requirements list. Flag implicit requirements and tensions: department isolation vs. shared citizen record, budget constraint vs. scope, external reviewer access, and public records portal.

Prep, middle 40 min: Design your architecture. Confirm org strategy. Define the sharing model. Sketch integration patterns for all three integrations (ArcGIS, CivicPay, PermitTrack batch). Outline the migration sequence.

Prep, final 40 min: Build your artifacts. Draft your data model, write a risk summary covering at least four risks, and prepare to defend your three most contested decisions. Use the extra time to rehearse your presentation narrative.

Presentation (30 min): Lead with org strategy and data isolation approach. Then cover the citizen portal design, integration architecture, migration plan, and license model.

Q&A (30 min): Expect probing on how the shared citizen contact coexists with hard department isolation, what happens if ArcGIS is unavailable at permit submission, what license type covers external third-party reviewers, and how public records search is handled for unauthenticated citizens.

Ready to Check?

When you have completed your own solution, compare with the reference solution.

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.