Skip to content
SF CTA Study Hub

Solution 08: GreenGrid Energy Services

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 Scenario 08: GreenGrid Energy Services FIRST. Set a 180-minute timer and build your own solution before reading this.

Assumptions

  1. Energy & Utilities Cloud (Industries package) licensed
  2. Salesforce Field Service (SFS) replaces Oracle WAM
  3. MuleSoft Anypoint as enterprise integration layer
  4. Data Cloud for smart meter data ingestion and analytics
  5. Experience Cloud for customer portals (outage reporting, usage dashboards, solar)
  6. Single Salesforce org for all three business units (Electric, Gas, Renewables)
  7. SAP IS-U remains billing and metering system of record for the entire program

Key Architectural Decisions

Decision 1: Single Org with Business Unit Separation

I chose a single org with BU-based permission sets, record types, and sharing rules over multi-org.

Rejected multi-org for three reasons: (1) 2.68M customers frequently have both electric AND gas — multi-org requires cross-org sync for a unified customer view, adding latency and data integrity risk; (2) Field Service dispatch must see all technicians across BUs for emergency reallocation during storms — cross-org FSL coordination is architecturally painful; (3) maintaining three orgs triples DevOps burden for the 45-person team.

Implementation: Custom Business_Unit__c field on Account/Work Order/Case. Permission Set Groups per BU control visibility. Record Types differentiate workflows. Sharing Rules isolate third-party solar contractor access. A “Unified Customer View” Lightning page assembles cross-BU data.

Decision 2: Smart Meter Data — Data Cloud Summaries, Itron API for Detail

I chose Data Cloud for daily/monthly usage summaries (batch from Itron) and on-demand Itron REST API for 15-minute interval drill-down.

Rejected loading all 240M daily readings into Data Cloud because the raw volume (87.6B records/year) would consume credits rapidly with minimal operational value — agents need daily summaries, not 15-minute intervals.

Implementation: Itron pushes daily summaries via MuleSoft to Data Cloud. Calculated Insights generate high-bill alerts and usage anomalies. Agent workspace embeds CRM Analytics showing 12-month trends. “View Interval Data” action calls Itron REST API via MuleSoft for on-demand detail (sub-5-second). Meter event streaming (power-loss, tamper, voltage) flows via Itron webhooks to MuleSoft to Platform Events in real time.

Decision 3: Field Service for 1,800 Technicians

I chose SFS with offline mobile, Enhanced Scheduling and Optimization (ESO), and an Emergency Dispatch Console for storm operations.

Implementation:

  • Offline: SFS mobile with offline priming at shift start — technicians download work orders, assets, map tiles. Completion data syncs on reconnect. Critical for rural KY/IN gaps.
  • Scheduling: ESO considers skills, proximity (GPS), workload, equipment, and appointment windows. Dispatchers use the Dispatch Console map for real-time rebalancing.
  • Storm Mode: Custom toggle activates emergency prioritization, enables mutual aid crew registration (temporary community users with limited permission sets), and switches to command-center view.
  • Notifications: Work order completion triggers Platform Event -> Flow -> SMS/email within 15 minutes.
  • Preventive maintenance: Maintenance Plans auto-generate work orders based on age, schedule, and condition scores.

Decision 4: SAP IS-U Integration via MuleSoft (Dual Pattern)

I chose MuleSoft for all SAP IS-U communication with pattern-matched integration flows.

  • Real-time: BAPI call for customer identification during inbound calls (sub-second via MuleSoft Object Store caching)
  • Near-real-time: SAP IS-U IDocs for account changes (new accounts, address, rate plan) transformed and upserted into Salesforce (< 15 min)
  • Daily batch: Nightly IDoc batch of billing/payment/balance updates loaded by 6:00 AM
  • Bidirectional conflict resolution: SAP IS-U masters billing/rates/meters; Salesforce masters interactions/work orders/cases. Address changes from Salesforce flow back to SAP IS-U via MuleSoft for validation before committing.

Critical Diagrams

System Landscape

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

    subgraph SF["Salesforce - Single Org"]
        SC[Service Cloud<br/>Customer 360]
        SFS[Field Service<br/>1,800 techs]
        DC[Data Cloud<br/>Usage Summaries]
        EC[Experience Cloud<br/>Customer Portal]
    end

    subgraph Int["MuleSoft Anypoint"]
        API[API Gateway + ESB]
    end

    SAP[SAP IS-U<br/>Billing SOR]
    ITRON[Itron AMI<br/>2.5M meters]
    ADMS[GE ADMS<br/>Outage Detection]
    GIS[Esri ArcGIS<br/>Asset Maps]
    WAM[Oracle WAM<br/>transition]
    IVR[Avaya IVR<br/>250K calls/mo]

    SAP <-->|"BAPI real-time + IDoc batch nightly"| API
    ITRON -->|"REST + webhooks real-time"| API
    ADMS -->|"REST real-time < 2 min"| API
    GIS -->|"REST batch daily delta"| API
    WAM <-->|"REST bidirectional near-real-time"| API
    IVR -->|"CTI screen pop real-time"| API
    API <-->|"REST + Platform Events"| SF

    style SC fill:#cce5ff,stroke:#0d6efd
    style SFS fill:#d4edda,stroke:#28a745
    style DC fill:#d4edda,stroke:#28a745
    style EC fill:#d4edda,stroke:#28a745
    style API fill:#fff3cd,stroke:#fd7e14
    style SAP fill:#e9ecef,stroke:#6c757d
    style ITRON fill:#e9ecef,stroke:#6c757d
    style ADMS fill:#e9ecef,stroke:#6c757d
    style GIS fill:#e9ecef,stroke:#6c757d
    style WAM fill:#f8d7da,stroke:#dc3545,stroke-dasharray: 5 5
    style IVR fill:#e9ecef,stroke:#6c757d

Integration Data Flows

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

    subgraph RT["Real-Time"]
        R1[SAP BAPI — account lookup]
        R2[Itron webhooks — meter events]
        R3[ADMS — outage events < 2 min]
    end

    subgraph NRT["Near-Real-Time"]
        N1[SAP IDoc — account changes < 15 min]
        N2[WAM sync — bidirectional]
    end

    subgraph Batch["Batch"]
        B1[SAP billing — nightly by 6 AM]
        B2[Itron daily usage to Data Cloud]
        B3[ArcGIS asset sync — daily delta]
    end

    RT -->|"REST/BAPI real-time"| MS[MuleSoft Anypoint]
    NRT -->|"IDoc/REST near-real-time"| MS
    Batch -->|"Batch nightly/daily"| MS
    MS -->|"REST + Platform Events"| SF[Salesforce]

    style MS fill:#fff3cd,stroke:#fd7e14
    style SF fill:#cce5ff,stroke:#0d6efd
    style R1 fill:#e9ecef,stroke:#6c757d
    style R2 fill:#e9ecef,stroke:#6c757d
    style R3 fill:#e9ecef,stroke:#6c757d
    style N1 fill:#e9ecef,stroke:#6c757d
    style N2 fill:#f8d7da,stroke:#dc3545,stroke-dasharray: 5 5
    style B1 fill:#e9ecef,stroke:#6c757d
    style B2 fill:#e9ecef,stroke:#6c757d
    style B3 fill:#e9ecef,stroke:#6c757d

Examiner Focus

With 7 external systems, judges probe per-system: pattern, protocol, direction, error handling, and data ownership. “MuleSoft connects everything” will not score well.

Identity & SSO Flow

sequenceDiagram
    participant User as Internal User<br/>(CSR / Dispatcher)
    participant Browser as Browser
    participant AD as Active Directory<br/>(On-Premise AD + Azure AD)
    participant SF as Salesforce

    User->>Browser: Navigate to Salesforce
    Browser->>AD: Redirect (SP-initiated SSO)
    AD->>AD: Authenticate (MFA via Microsoft Authenticator)
    AD->>Browser: SAML 2.0 Assertion
    Browser->>SF: POST SAML to ACS URL
    SF->>SF: Match Federation ID → User record
    SF->>Browser: Session Cookie + Service Console
sequenceDiagram
    participant Tech as Field Technician<br/>(1,800)
    participant App as SFS Mobile App
    participant AD as Azure AD<br/>(Corporate IdP)
    participant SF as Salesforce

    Tech->>App: Launch Field Service app
    App->>AD: OAuth 2.0 + PKCE
    AD->>AD: Biometric / PIN
    AD->>App: Access Token + Refresh Token
    App->>SF: API calls with Bearer token
    SF->>App: Work order data + offline cache
sequenceDiagram
    participant Cust as Customer<br/>(2.68M accounts)
    participant Browser as Browser / Mobile
    participant SF as Salesforce<br/>(Experience Cloud)

    Cust->>Browser: Navigate to Customer Portal
    Browser->>SF: Login page
    SF->>SF: Email/Password + MFA (SMS OTP)
    SF->>Browser: Session Cookie + Customer Dashboard
sequenceDiagram
    participant Solar as Solar Contractor<br/>(Third-Party)
    participant Browser as Browser
    participant SF as Salesforce<br/>(Experience Cloud)

    Solar->>Browser: Navigate to Contractor Portal
    Browser->>SF: Login page (Experience Cloud)
    SF->>SF: Username/Password + MFA (TOTP App)
    SF->>Browser: Session Cookie + Limited Work Order View

Internal users (420 CSRs + dispatchers + HQ staff): SAML 2.0 SP-initiated SSO with on-premise Active Directory synced to Azure AD. Utilities typically maintain on-premise AD for NERC compliance and legacy system integration. Microsoft Authenticator for MFA. Emergency operations center staff use the same SSO with elevated emergency mode permissions activated by Flow.

Field technicians (1,800): OAuth 2.0 with PKCE flow via Azure AD for the SFS mobile app. Biometric authentication as primary factor for speed in the field. Refresh tokens enable offline session continuity — critical for rural OH/IN/KY areas with connectivity gaps. Token refresh occurs silently on reconnection.

Customers (2.68M): Experience Cloud native login for the customer portal. SMS OTP for MFA. Separate authenticated zones (usage data, billing, outage reporting) and unauthenticated zone (outage map, general info). Self-registration via account number + last 4 of SSN + service ZIP.

Third-party solar contractors: Experience Cloud Partner portal with limited access. Username/password + TOTP-based MFA. Access provisioned per contract term with automatic deactivation on contract expiry. Sharing rules restrict visibility to assigned solar work orders and interconnection details only.

Integration Error Handling

IntegrationPatternRetry StrategyDead Letter QueueMonitoringFallback
SAP IS-U Account Lookup (real-time BAPI)Sync REST via MuleSoft2 retries: 200ms, 1s backoff (sub-second SLA)N/A (stateless lookup)Alert on avg latency > 500ms; circuit breaker at 2sMuleSoft Object Store cache returns last-known account data; “data may not be current” indicator
SAP IS-U Account Changes (IDoc near-real-time)Near-real-time IDoc via MuleSoft3 retries: 1s, 5s, 30s backoff per IDocFailed IDocs → Anypoint MQ DLQ → SAP_Sync_Error__cAlert if sync lag > 30 min; IDoc queue depth dashboardStale data displayed with “last synced” timestamp; CSR can trigger manual refresh
SAP IS-U Billing (nightly batch)Batch IDoc via MuleSoftFull batch re-run on systemic failure; record-level retry for individualsFailed billing records → Billing_Error__c staging objectAlert if batch not complete by 6 AM; reconciliation count alert at > 0.05% variancePrevious day’s billing displayed; CSR redirects to SAP billing screen for current data
Itron AMI Daily Usage (batch)Batch REST via MuleSoft → Data CloudFull batch re-run; individual meter failures logged and skippedFailed meter summaries → Meter_Sync_Error__cAlert if batch not complete by 7 AM; missing meter count alert”Usage data temporarily unavailable” for affected meters; CSR uses Itron portal directly
Itron AMI Interval Data (on-demand)Sync REST via MuleSoft → Itron2 retries: 1s, 3s backoff (5-second SLA)N/A (stateless query)Alert on avg latency > 3s; circuit breaker at 8s”Interval data temporarily unavailable”; agent offered to email detailed usage report
Itron Meter Events (webhooks, real-time)Event-driven webhooks → MuleSoft → Platform Events3 retries: 1s, 5s, 30s backoffFailed events → Anypoint MQ DLQ; Platform Events 72-hour replayAlert on event processing lag > 5 min; storm mode: alert on queue > 50KEvents queued; outage detection falls back to ADMS-only (no meter-level confirmation)
GE ADMS Outage Events (real-time)Event-driven REST via MuleSoft (< 2 min SLA)3 retries: 1s, 5s, 15s backoffFailed outage events → priority Anypoint MQ DLQAlert on ANY unprocessed outage event > 3 min; PagerDuty to network opsManual outage creation by EOC staff; Experience Cloud outage map updated manually
Oracle WAM Bidirectional Sync (transition)Near-real-time REST via MuleSoft3 retries: 1s, 5s, 30s backoffConflict records → WAM_Conflict__c with both versionsDaily reconciliation report; duplicate work order alertUnique external ID prevents duplicates; clear cutover criteria per service center
Esri ArcGIS (daily delta)Batch REST via MuleSoftFull batch re-run on failureFailed asset records → GIS_Sync_Error__cAlert if sync not complete by 5 AM; asset count reconciliationPrevious day’s asset positions; field crews use ArcGIS directly for map data

Storm-Event Error Handling

During major storms, Itron generates 500K+ meter events (33x normal) and the Experience Cloud portal faces 85K concurrent sessions. MuleSoft rate-limits inbound Itron webhooks to prevent overwhelming Platform Events (hourly publishing allocation varies by edition — 250K/hour for high-volume platform events on Enterprise/Unlimited). Excess events queue in Anypoint MQ with FIFO processing. Platform Events enable 72-hour replay for any missed events. The Experience Cloud outage map uses Platform Cache + CDN with static page templates that remain functional even during extreme load. SAP IS-U batch billing continues on schedule — storm events do not affect billing pipeline.

Requirements Addressed

  1. Unified customer view (< 4 seconds) — Single org across 3 BUs; MuleSoft-cached SAP lookup; cross-BU Lightning page (Reqs 1, 2)
  2. Field Service for 1,800 technicians — SFS with offline mobile, ESO scheduling, emergency dispatch console (Reqs 6, 7, 8, 9)
  3. Smart meter data architecture — Data Cloud for daily summaries, Itron API for interval detail, Platform Events for real-time events (Reqs 3, 16)
  4. Outage management — ADMS-triggered incidents within 5 min, multi-channel reporting, proactive notifications (Reqs 12, 13, 14)
  5. Community solar engagement — Dedicated Experience Cloud views for credit allocations, production data, CO2 offsets (Req 4)
  6. SAP IS-U integration — Dual-pattern: real-time BAPI + batch IDoc; SAP remains billing/metering SOR (Reqs 15, 29)
  7. Storm scalability — Platform Events 72-hour replay, MuleSoft rate-limiting, CDN/cache, static templates (Reqs 30, 34)
  8. Third-party contractor access — Experience Cloud with limited sharing rules, contract-term-based provisioning (Req 24)
  9. Regulatory compliance — PUC audit trail, NERC reliability data, rate structure configurability within 90-day windows (Reqs 36, 39)

Governance & DevOps

flowchart LR
    PLAT[Platform Team<br/>Dev Sandbox x4<br/>12 Staff] --> INT_ENV[Integration Test<br/>Partial Copy<br/>SAP/Itron/ADMS Test]
    SI[Systems Integrator<br/>Dev Sandbox x4<br/>25 Consultants] --> INT_ENV
    OPS[IT Ops<br/>Dev Sandbox x2<br/>8 Staff] --> INT_ENV
    INT_ENV --> UAT[UAT — Full Copy<br/>2.68M Accounts<br/>Storm Simulation Data]
    UAT --> PROD[Production]

    REG[Regulatory Hotfix<br/>Dev Pro Sandbox] -.-> INT_ENV

Branching Strategy

Main + develop + feature branches with strict regulatory change management for a 45-person team across 3 groups.

  • main — production-ready. All deployments cut from here. Protected with 3 approvals (1 per group).
  • develop — integration branch. All feature branches merge here. CI runs full validation suite.
  • feature/* — short-lived branches (max 1 week). Clear ownership per team: platform features, integration flows, IT ops configurations.
  • hotfix/* — regulatory changes with 90-day PUC deadlines. Fast-tracked through integration test with business owner sign-off per Req 36.
  • release/* — bi-weekly release stabilization. Created 3 days before Sunday deployment window.

Sandbox Strategy

Sandbox TypeCountPurpose
Developer104 for platform team (12 staff), 4 for SI (25 consultants, paired dev), 2 for IT ops (8 staff).
Developer Pro1Regulatory hotfix environment for urgent rate structure / reporting changes with 90-day PUC deadlines.
Partial Copy1Integration test with connections to SAP IS-U test, Itron sandbox, GE ADMS test, Oracle WAM test, and ArcGIS dev.
Full Copy1UAT with 2.68M account dataset. Storm simulation data pre-loaded for volume testing. Refreshed before each major release.

Testing Strategy

Environmental compliance and seasonal demand testing are unique requirements for a regulated utility.

  • Apex unit tests: >80% coverage. SAP BAPI/IDoc mocks with realistic response payloads. SFS scheduling logic tests with emergency mode scenarios. Platform Event trigger tests with volume simulation.
  • Integration testing: End-to-end SAP IS-U account sync (< 15 min SLA). Itron webhook processing for normal (15K events/day) and storm (500K+ events). ADMS outage-to-incident pipeline (< 2 min). Oracle WAM bidirectional sync with conflict resolution.
  • Storm-event load testing: Simulate 500K+ Itron meter events, 85K concurrent portal sessions, and 300-500% call volume spike simultaneously. Validate Platform Events replay buffer, MuleSoft rate-limiting, CDN caching, and Experience Cloud static page fallback. Run quarterly before storm seasons (spring/winter).
  • Seasonal demand testing: Load test with summer peak (AC load), winter peak (heating), and spring storm scenarios. Validate SFS scheduling handles 2x normal work order volume during seasonal spikes.
  • Regulatory compliance validation: Verify SAIDI/SAIFI/CAIDI calculation accuracy against IEEE 1366. Validate rate structure changes propagate correctly from SAP IS-U through billing sync. Confirm PUC audit trail captures all billing/metering/notification changes.
  • Oracle WAM parallel operation: Bidirectional sync testing with conflict scenarios (work order updated in both systems within sync window). Cutover criteria validation per service center.
  • UAT: 4-week cycle given 3 business units and 7 integration systems. CSR supervisors, field ops managers, EOC staff, renewable energy team, and IT ops each validate their domain. Business unit-specific workflows tested (electric vs. gas vs. solar).
  • Regression: Automated test suite covering outage lifecycle, work order lifecycle, customer inquiry flow, and portal self-service. Run on every merge to develop and before every production deployment.

CoE / Governance

VP of IT serves as executive sponsor with a dedicated Platform Owner reporting to the CIO.

  • Post-go-live ownership: Transition from 25-person SI to internal team of 12 platform staff + 8 IT ops. SI retains 6 consultants for 9 months post-go-live. Clear handoff plan with documentation and knowledge transfer sessions.
  • Change management: All changes affecting billing, metering, notifications, or regulatory reporting require documented business owner sign-off retained for PUC audit (Req 36). Metadata changes tracked in Git with full audit trail.
  • Regulatory change process: Rate structure changes, reporting requirement updates, and notification modifications follow an expedited path with 90-day implementation windows. Developer Pro sandbox reserved for regulatory work. Business owner sign-off mandatory before deployment.
  • Release cadence: Bi-weekly production releases during Sunday 2-6 AM maintenance window (Req 38). Zero-downtime for customer-facing channels using blue-green deployment pattern. Feature flags enable instant rollback.
  • Emergency operations: Storm mode activation grants EOC staff temporary elevated permissions via Flow-triggered permission set assignment. Mutual aid crew registration provisions temporary community users with pre-configured limited permission sets. All temporary access auto-expires 72 hours after storm mode deactivation.
  • Cross-system coordination: Joint release calendar with SAP IS-U, Itron, and GE ADMS teams. Integration contract changes require 4-week advance notice and regression testing. Oracle WAM sync monitored daily during transition with reconciliation reports.

Risk Assessment

RiskLikelihoodImpactMitigation
Storm-event scaling: 500K+ meter events + 85K concurrent portal sessionsMediumCriticalPlatform Events 72-hour replay buffer; MuleSoft rate-limiting/queuing; CDN + Platform Cache; static outage page templates
SAP IS-U integration exceeds 15-minute SLA for account changesMediumHighMuleSoft Object Store caching; IDoc processing parallelized; monitoring on queue depth; fallback: embedded SAP iframe
Field Service offline data conflicts on technician reconnectHighMediumSFS built-in conflict resolution (last-write-wins for status, server-wins for dispatcher overrides); offline priming reduces stale data
Oracle WAM bidirectional sync creates duplicate work ordersHighHighUnique external ID; MuleSoft idempotent processing; daily reconciliation report; clear cutover criteria per service center

Domain Scoring Notes

D1 System Architecture (HEAVY): Single org is the correct answer — judges probe WHY. Shared customer base, shared dispatch, shared integration layer outweigh process differences. Storm-event scalability: Platform Events, CDN, caching, graceful degradation. SFS mobile with offline is non-negotiable. Experience Cloud with authenticated (usage data) and unauthenticated (outage map) zones.

Reporting Approach

CRM Analytics for VP dashboards (Customer Ops, Field Ops, Renewable Energy) with hourly refresh and 15-minute storm-mode refresh. Regulatory indices (SAIDI/SAIFI/CAIDI/MAIFI) calculated from outage data with IEEE 1366 major event day exclusions — built as CRM Analytics dataflows, NOT real-time reports against transactional data. CFO reconciliation dashboard compares SAP IS-U billing totals against Salesforce-synced records with variance drill-down.

D5 Integration (HEAVY): Pattern specificity for each of 7 systems — protocol, direction, frequency, error handling, retry. SAP IS-U dual-pattern (real-time BAPI + batch IDoc) is the canonical utility integration. Itron event handling with 33x storm spike. ADMS outage-to-incident within 2 minutes. Dead letter queues, circuit breakers, and alerting — especially for SAP billing sync affecting 2.68M customers.

What Would Fail

Critical Failures

  1. Multi-org for 3 business units — unified customer base, shared field dispatch, and 7-system integration landscape demand a single org. Multi-org duplicates all integrations and requires cross-org customer sync.

  2. Storing 240M daily meter readings in Salesforce — 87.6B records/year. Data stays in Itron with on-demand API access. Only daily/monthly summaries enter the Salesforce ecosystem.

  3. No offline mobile strategy — rural connectivity gaps are explicit. SFS offline mode is a hard requirement for 1,800 technicians.