Mustafa.
ende
Back to all projects

TechnoStore — Revenue Cloud Quote-to-Cash for the DACH market

End-to-end B2B electronics Quote-to-Cash demo on Salesforce Revenue Lifecycle Management, Contract Lifecycle Management, and Industries CPQ — orchestrated with MuleSoft Anypoint across ten external systems.

Year
2025
Role
Salesforce Developer
Tech stack
ApexRevenue Lifecycle ManagementContract Lifecycle ManagementIndustries CPQAgentforce Actions (@InvocableMethod)SAP OData v2 (CSRF, deep-insert)CAMT.053 / ISO 20022DATEV (EXTF / SKR04)Approval Processes (multi-tier)MuleSoft AnypointPlatform EventsNamed CredentialsSFDX (6 packages)Kevin O'Hara trigger frameworkOpenAPI 3.0arc42

Highlights

  • 10 external systems via MuleSoft + Apex — incl. SAP S/4HANA (OData v2: CSRF, deep-insert, CloudEvents) and the German finance stack (lexoffice + DATEV EXTF/SKR04)
  • Agentforce-ready Apex actions, Einstein Copilot-invocable (revenue summary + payment reminders)
  • CAMT.053 / ISO 20022 bank-statement parser for SEPA payment reconciliation
  • Multi-tier discount approval (>30 % Finance Director, >50 % VP) + account-context product qualification (Expression Sets)
  • Integration-health observability: correlation IDs, error classification, two-layer idempotency, Slack escalation + dashboards
  • ~79 Apex classes across 6 SFDX packages; 33 ADRs (Nygard) + arc42 Solution Blueprint
  • 50-entry STAR-format Notion portfolio published programmatically
  • DACH-specific: 19 % VAT (multi-country fallback table), DHL preference, DE/AT/CH address parsing

Feature walkthrough

Salesforce → Stripe, end to end

The payment flow in Anypoint Studio: a Salesforce Platform Event (On Invoice Payment Requested) triggers the Mule flow, which builds the Stripe body in DataWeave, creates a Stripe Checkout session, and writes the payment URL straight back into Salesforce. Below it, the stripe-webhook-flow routes the incoming webhook by event type. The console reports the application DEPLOYED — this runs.

Anypoint Studio: the invoice-payment-requested flow — a Salesforce Platform Event triggers Mule, which builds the Stripe body and creates a Checkout session

The order fan-out — with the failure paths drawn in

A Choice router branches on the fulfillment flags (physical / digital / both). Each branch calls Sendcloud inside a Try scope that has its own error handler and a Sendcloud GET Fallback, then a retry scope creates the Salesforce record and a logger records the outcome. This is the integration-health layer the case study describes — error classification, fallbacks and idempotency — made visible instead of merely claimed.

Anypoint Studio: the order fan-out — a Choice router branches on fulfillment flags, each branch wrapped in a Try scope with error handling, fallbacks and retry scopes

DataWeave — where “DHL prioritised” actually lives

The Extract Preferred Carrier transform, in DataWeave: it reads Sendcloud's shipping methods, filters for DHL (the DACH carrier preference), falls back to the first available method when there is none, and puts a default on every field it touches. The line in the case study that says the DACH carrier is prioritised is not a slide — it is these six lines of code.

DataWeave: the Extract Preferred Carrier transform filters Sendcloud shipping methods for DHL and defaults every field

SAP S/4HANA — actually queried, not mocked

The SAP integration flow: a GET against SAP S/4HANA Cloud for Business Partner records, the response logged and diagnosed, the records extracted in DataWeave, and a final response assembled. This is the OData layer behind the SAP claim in the case study — the flow runs and the console reports the records it read.

Anypoint Studio: the SAP S/4HANA Business Partner query flow with the DataWeave response transform

No secrets in source

The Configuration XML: the Salesforce connector, the webhook HTTP listener, and the Stripe / Slack / Sendcloud request configs. Every credential resolves through a property placeholder — ${salesforce.password}, ${stripe.host}, ${sendcloud.secret} — never a hard-coded value. The secrets live outside the repository, which is the difference between a demo and something you could actually deploy.

Anypoint Studio Configuration XML: Salesforce, HTTP listener, Stripe, Slack and Sendcloud configs — all credentials as property placeholders

The problem

DACH enterprise Salesforce roles (T-Systems, Allianz Technology, Mercedes-Benz.io, BMW Group IT, SAP Industries practice) consistently ask for the same combination: Revenue Cloud + Industries CPQ on the Salesforce side, plus real MuleSoft + payment + logistics + e-signature integration on the orchestration side. Most portfolio projects demonstrate one or the other, not both, and almost none reflect German-market specifics such as Mehrwertsteuer, DHL preference, or multi-country address parsing.

Architecture

Reps work with an account-context-aware Industries CPQ catalogue. Bundle configuration triggers an asynchronous attribute-based pricing service. On Order activation, the OrderTriggerHandler fans out across five downstream systems in parallel: JIRA (direct Apex callout) for inventory tickets, Slack #warehouse (Platform Event → MuleSoft) for picking, DocuSign (Apex + Named Credential) for the contract envelope, Stripe (MuleSoft outbound) for payment, and a branded invoice email. The Stripe webhook arrives at MuleSoft, is HMAC-SHA256 verified, then scatters back to Salesforce (mark Paid), Slack #payments-team, and a Choice router for fulfilment — Sendcloud/DHL for physical items, license-key generation for digital. The DocuSign Connect webhook lands at a Salesforce Site, publishes a Platform Event to escape Guest User FLS limits, and an autolaunched Flow creates the Asset. Cross-cutting, an integration-health layer threads correlation IDs from Salesforce → MuleSoft → provider, classifies failures (auth / validation / timeout / downstream), escalates 5xx to Slack, and enforces two-layer idempotency; revenue and payment-reminder logic is also exposed as Agentforce-ready Apex actions (Einstein Copilot-invocable).

The approach

Code is organised into six SFDX packages (force-app + controllers + services + handlers + actions + tests) so architectural boundaries are visible at the filesystem level — a Service class calling ApexPages would be obvious in code review. All triggers extend the Kevin O'Hara TriggerHandler base with recursion guards and a bypass mechanism. Each external call uses a Named Credential and is wrapped in an idempotent service: the Stripe webhook checks Order.Status before mutating, DocuSign uses a Platform Event indirection to satisfy Guest User context, JIRA stays in direct Apex because the flow is synchronous and low-volume while Stripe goes via Mule for retry and queueing. The 50-entry Notion documentation is itself a feature: NotionPublishService.publishEnterprise() orchestrates six API calls per entry to work around Notion's two-level nesting limit.

The outcome

A coherent twelve-minute Quote-to-Cash demo narrative across ten external systems, ready for both portfolio interviews and customer-facing solution conversations. The project is documented as 33 Architecture Decision Records in Nygard format, an arc42 Solution Blueprint, OpenAPI 3.0 specs for inbound webhooks, and a 17-request Postman collection. Measured end-to-end latency lands at 2–6 seconds. The DACH framing — Mehrwertsteuer formulas, DHL preference, DE/AT/CH address parsing — is the level of detail German enterprises expect, not generic Salesforce knowledge.

External integrations

GitHub & Notion — private, walkthrough on request