Skip to main content
INDEPENDENT RESEARCH · REVENUE CLOUD (RCA) · ORCHESTRATION · GRAPHSTier 2 Architecture

Save Pipelines Drawn as Graphs, Not Trigger Chains

Make the save order visible and the failure localized - implicit trigger chains do neither.

A small execution engine for multi-stage Salesforce Revenue Cloud (RCA) saves: declare dependencies, sort topologically, fail with a reason.

DAGRCADEPENDENCY GRAPHPIPELINES

Executive BriefSalesforce
Domain / ScopeSalesforce Revenue Cloud (RCA) & Workflow Architecture
Architectural RoleIndependent Architect
Timeline & InitiativeIndependent research · 2025–2026
Key Verified Invariant

Fixture saves run in declared order with cycles rejected at startup

01 · The Constraint

What Made the Problem Difficult

Independent work, fixture models. Quoting-style saves couple calculation with persistence across several related entities, and the stages genuinely depend on each other. Implicit execution order turns every new rule into a regression risk.

Core Platform Constraint

Systemic Friction

Chained handlers and flag-guarded triggers hide the order, allow cycles by accident, and spread one save across many partial writes - which then fail partially and reconcile manually.

Boundary Invariants & Operational Limits:
  • !Stages run in dependency order, stated explicitly in code
  • !Upstream outputs feed downstream inputs without shared mutation
  • !Any stage failure names the stage and preserves diagnostics
  • !Adding a rule means adding a node, not editing five files
02 · The Architecture

What System Was Designed

Each stage is a node with declared inputs, outputs, and dependencies. The engine topologically sorts the graph at startup (cycles fail fast with the offending edge named), threads an immutable context through execution, and defers persistence to a single bulk write at the end. Independent branches can run without waiting on each other.

03 · The Key Decision

Pivotal Architectural Choices

Key Architectural Decisions

ADR // 01DETERMINISTIC CHOICE

Declared DAG vs. chained handlers

Context:

Implicit order is the leading cause of save bugs I have debugged.

Alternatives Evaluated:
  • Trigger-handler frameworks with static flags
  • One large procedural service
Chosen: Explicit graph with declared dependencies.

Order becomes reviewable. Cycles become compile-time errors. Orchestration stays separate from business rules.

ADR // 02DETERMINISTIC CHOICE

Immutable context vs. shared mutable records

Context:

Shared mutation across stages produces action-at-a-distance bugs.

Alternatives Evaluated:
  • Global static state
  • In-place record mutation
Chosen: Immutable context with explicit stage I/O.

Stages become unit-testable in isolation, and the audit of a failed save reads like a trace.

04 · The Engineering

What Was Actually Built

01

Modeled stages as an adjacency-list graph with a fluent builder for registration.

02

Implemented Kahn's topological sort with cycle reporting that names the edge, not just the failure.

03

Carried an immutable execution context with per-stage diagnostics throughout.

04

Deferred writes to one bulk persistence step with heap-conscious DTOs in the study model.

05

Added per-node error boundaries so a tax-rule failure never masquerades as a persistence failure.

05 · The Trade-offs

Deliberate Architectural Compromises

Trade-offs & Mitigations

Graph ceremony vs. scripting speed

Architectural Benefit:

No cyclic saves by construction; new rules slot in safely.

Associated Cost:

Engineers declare nodes instead of writing inline steps.

Mitigation Strategy:

A small builder API keeps registration to a few lines per stage.

Deferred bulk write vs. incremental writes

Architectural Benefit:

One atomic write; no partial-commit cleanup.

Associated Cost:

Modifications accumulate in memory during the run.

Mitigation Strategy:

Lightweight DTOs and explicit heap awareness in long pipelines.

06 · The Result

Verified Outcomes

✓ VERIFIED RESULT

Fixture saves run in declared order with cycles rejected at startup

✓ VERIFIED RESULT

New calculation stages add without touching existing nodes in the study model

✓ VERIFIED RESULT

Failed saves identify the stage, its inputs, and the rule that rejected them

✓ VERIFIED RESULT

Calculation stays decoupled from persistence throughout

07 · Architecture Blueprint

System Schematic & Data Flow

System Topology Blueprint
DAG Save Pipeline (Study Model)
INTERACTIVE SCHEMATIC
NODE A · INGRESSPayload IngestionPre-validation & SchemaImmutable Context InitNODE B · DEPENDENT 01Line Item CalculationVolume Tiers & OptionsOutput: Normalized Net LinesNODE C · DEPENDENT 02Tax & Discount EngineJurisdiction & ApprovalsOutput: Computed SurchargesNODE D · CONVERGENCEAtomic PersistenceBulkified DML CommitPost-Save Event Trigger
EXPLICIT DEPENDENCIESEliminates trigger recursion and cyclic save bugs through formal topological sorting.
ISOLATED STAGESEach calculation node receives immutable context and produces typed output contracts.
ATOMIC CONVERGENCEAll database writes are deferred until all graph dependencies validate, ensuring zero partial commits.

Ingress normalizes once, calculations fan out, persistence commits once - in sorted order.

Text alternative for screen readers: Architecture flow: Node A: Ingress Normalization to Node B: Line Calculation via Dependency Edge 01; Node A: Ingress Normalization to Node C: Tax Resolution via Dependency Edge 02; Node B: Line Calculation to Node D: Atomic Persistence via Calculated Lines Join; Node C: Tax Resolution to Node D: Atomic Persistence via Surcharges Join

08 · Why It Matters

Architectural Conclusion

A save workflow you can draw is a save workflow you can reason about - and fix at 2am without fear.

Key Lessons for Platform Scale:
  • Implicit execution order is the most expensive kind of technical debt in record-heavy systems.
  • Explicit graphs turn save logic from archaeology into reading.