Skip to content
Shannon

Salesforce code architecture at PWG

Salesforce code architecture at PWG

Section titled “Salesforce code architecture at PWG”

Custom code sits on top of Financial Services Cloud and DLRS. Apex triggers follow a roughly consistent handler pattern — with 14 known violations — and Flow is the strongly-preferred automation surface. Cross-cutting logic (rollups, KYC, payments, PDF generation) is pushed into managed packages or named-credential callouts.

Layers

Section titled “Layers”

Apex triggers

Section titled “Apex triggers”

113 triggers across 14 multi-trigger SObjects.

Naming tells you the owner:

PrefixOwnerCount (approx)
PWG*TriggerInternal PWG code~10
dlrs_*TriggerDeclarative Lookup Rollup Summaries (pkg)~10
OtherFSC / third-party managed packages~90

Full inventory: docs/generated/apex-graph/INDEX.md.

Handler pattern

Section titled “Handler pattern”

Internal PWG triggers follow the one-trigger-per-object pattern and delegate to handler classes (e.g. PWGOpportunityTrigger → PWGOpportunityTriggerHandler). 14 SObjects have multiple triggers — typically a PWG trigger and a DLRS trigger coexisting. The order of execution between separate trigger files is not guaranteed, so if you see rollup drift, check whether two frameworks are mutating the same field.

Trigger call graph

Section titled “Trigger call graph”

docs/generated/apex-graph/triggers/ has one page per trigger with:

  • Handler class dependencies
  • Helper classes called
  • Invocable methods exposed to Flow
  • Flow launcher relationships (which Flows call this trigger’s path)

Complexity ranking is at the top of docs/generated/apex-graph/INDEX.md.

Flows

Section titled “Flows”
  • 271 active Flows, 1,611 versions.
  • 80 Flows have ≥ 5 versions.

Record-Triggered and Screen Flows dominate. Version churn is flagged as a quality signal in analysis/misconfig-*.md.

Per-Flow Mermaid diagrams in docs/generated/flows/. Elements covered: record lookups/creates/updates/deletes, decisions with rule labels, assignments, actionCalls, subflows, screens, loops, waits.

State machines (data-layer)

Section titled “State machines (data-layer)”

Stage/status fields on Opportunity, Case, and Lead are modelled as explicit state machines:

  • docs/generated/state-machines/Opportunity-StageName.md
  • docs/generated/state-machines/Case-Status.md
  • docs/generated/state-machines/Lead-Status.md

These are derived from the combination of picklist values, Flow-driven transitions, and trigger-driven transitions — not just the picklist alone.

Custom object inventory

Section titled “Custom object inventory”

272 custom objects — far more than the 27 CRM core objects retained. This reflects the depth of FSC customisation plus PWG-specific process objects (e.g. ABN__ABN_Lookup__c).

Per-object pages in docs/generated/objects/ cover fields, record types, child relationships, picklists, formula source, and validation rules.

Large classes

Section titled “Large classes”

67 Apex classes exceed 3,000 lines. These concentrate in FSC and third-party managed packages; PWG’s 156 custom classes are proportionally healthier. analysis/performance-*.md has the ranking.

Legacy API versions

Section titled “Legacy API versions”

23 custom Apex classes are on API version < 45. Platform features such as user-scoped System.runAs, newer SOQL capabilities, and some security-relevant defaults are version-gated. When you touch one of these classes, bump the API version alongside the change.

Further reading

Section titled “Further reading”
  • docs/generated/apex-graph/INDEX.md — trigger-level call graph
  • docs/generated/process-maps/ — per-SObject automation map
  • docs/generated/process-narratives/ — named business processes stitched across multiple Flows and Apex