// flagship · NDA · Canyon engagement — names, architecture and numbers shown under client-grade access terms.
Access granted · reading the full Canyon dossier
Client
Canyon Bicycles GmbH
Unit
prodct [Elements] · + [CX] adj.
Duration
~ 6 months · 2024
Stack
SAP · SAP Integration Suite · Salesforce
Headline
Fixed the SAP ⇄ Salesforce data sync — isolated, near-real-time, no replatform required.
// prodct [Elements] case · Canyon · 2024 · direct-to-consumer cycling · SAP ⇄ Salesforce

A data problem dressed as an integration problem.

Canyon didn't need a new architecture. They needed someone who could walk into a running SAP + Salesforce estate, find the sync failures, and ship a fix that their own team could own afterwards. No lock-in, no year-long programme. Shop-to-ERP data flowing reliably, in the platform they already pay for.

2 systems
// SAP core + Salesforce Sales Cloud, drifting out of sync
// shop-to-ERP
~ 6 mo
// assessment → shipped pipelines, phased
// isolated, non-disruptive
≈ real-time
// latency on critical data flows, down from daily batches
// event-ready
0
// vendor lock-in — platform owned & operated by Canyon IT
// no new SaaS
// 01 / the situation

Legacy systems talking past each other. No in-house owner to fix it.

// diagnosed
2024
SAP core, Salesforce Sales Cloud, SAP Integration Suite

Canyon asked us in to bring an external perspective on their tech landscape. The symptom: data communication between their legacy systems was breaking — shop to ERP especially. The deeper issue: no experienced architects or engineers on hand to operate and fix the sync problems from the inside.

They had the platforms. SAP as the system of record. Salesforce as the commercial front. SAP Integration Suite in between. What they didn't have was someone who could read the integration layer end-to-end, diagnose why records were drifting, and make surgical fixes without stopping the business.

The ask we accepted: bring senior SAP and data-architecture capacity into the Canyon team, work shoulder-to-shoulder with their own SAP consultants and Salesforce specialist, and leave behind a data-sync setup Canyon could maintain themselves. No parallel programme, no external dependency afterwards.

  • #01 Shop-to-ERP data drift. Orders, product updates and customer records were not arriving in SAP in the shape the downstream processes expected. Errors compounded with volume. — priority 1
  • #02 No in-house architect for this. Canyon had operators for each system, but no one with the seniority to redesign the integration flows while keeping both sides live. — priority 1
  • #03 Batch-first integration layer. The existing flows were scheduled jobs. Business needed near-real-time — especially for anything customer-visible on the shop. — priority 2
  • #04 No appetite for a replatform. Canyon runs SAP & Salesforce for good reasons. The fix had to live inside the existing stack, not recommend its replacement. — constraint

The frame we agreed on: fast, isolated shipment. Fix the worst data flows first inside SAP Integration Suite, add script-based enhancement where the platform fell short, and lay out a strategy for a longer-horizon data hub — event-based and API-first — that Canyon could decide to build later, on their own timeline.

// 02 / approach

Ship the fixes. Then draw the strategy.

// phase 01

Isolated shipment on the Integration Suite.

We started in the SAP Integration Suite — inside the platform Canyon already owned. Flow by flow, we rebuilt the data processes that were failing. Each fix went live on its own, without waiting for a full cutover, and without touching flows that were healthy.

Start
Month 1
Data processes audited + first fixes shipped
// phase 02

Script-based data enhancement where the platform fell short.

Some flows needed logic the Integration Suite doesn't express natively — reshaping, enrichment, conditional routing. We added targeted scripts rather than bending the platform. Each script was code-reviewed with Canyon's SAP consultants so ownership could transfer on day one.

Month 2–4
Individual scripts for the hot flows; paired with Canyon SAP team
// phase 03

Near-real-time on the flows that matter.

Customer-visible flows moved off nightly batches toward event-driven synchronisation. Not everywhere — only where the business case was clear. Batches stayed where they were cheap and good enough.

Month 3–5
Latency cut from hours to minutes on priority flows
// phase 04

Strategy for a data hub. Event-based, API-first.

In parallel to the fixes, we wrote a strategy document for Canyon leadership: what a data hub on top of SAP + Salesforce should look like if they decide to build it — event-first, API-first, and explicit about what does and doesn't belong in SAP. No commitment to buy, no vendor recommendation. Their decision, informed.

Month 4–6
Strategy handed over; Canyon owns the roadmap
// 03 / what we built

Inside the stack they already own and run.

LAYERS →
// front
Salesforce Sales Cloud Shop front-of-house
// integration
SAP Integration Suite · reworked flows Script-based enhancement Event adapters (priority flows)
// mapping
Canonical data model · draft Field-level mapping Error + retry policy
// record
SAP core · system of record Master data owners per domain
// roadmap
Data-hub strategy · event-first API-first principles Decision memo for Canyon board

Fix the flows. Write the scripts. Leave a map.

The shipped work sits inside SAP Integration Suite — no new SaaS, no new vendor. The decisive additions are the individual enhancement scripts and the reshaped data flows, paired with a small set of rules about how SAP and Salesforce are allowed to speak to each other going forward.

On top of that: a strategy memo for an event-based, API-first data hub. Not something we built. Something Canyon can decide to build — on their terms, with a clear starting point. Their architects and SAP consultants were co-authors, not spectators.

// integration platform
SAP Integration Suite (existing)
// sync model
Near-real-time, priority flows
// data model
Canonical draft, field-mapped
// next step
Event-first data-hub (Canyon-led)
// 04 / handoff

What Canyon owns, as of engagement close.

// the checklist we signed off against

A practicable solution — no lock-in, no dependency.

Engagement close: end of 2024. Canyon's SAP consultants and Salesforce specialist kept operating the platform throughout. When we left, nothing on the critical path required prodct to stay.

Systems owned by Canyon. SAP, Salesforce and SAP Integration Suite remain fully in Canyon's operational control — no prodct-hosted middleware, no prodct-branded tooling.
Processes owned by Canyon. The reworked data flows, integration patterns and error/retry rules are maintained by the in-house SAP + Salesforce teams.
Scripts owned by Canyon. Every enhancement script is in the Canyon repo, written in the coding standard their own engineers use. Paired code reviews during the engagement, no black-box commits.
Strategy handed off. The event-first, API-first data-hub strategy sits with Canyon leadership. They decide if, when, and with whom to build it. No prodct retainer attached.
No vendor lock-in. No new SaaS introduced. The only thing Canyon is bound to is the stack they chose before we arrived.

SAP and Salesforce
not quite talking?

30 minutes with the partner leading [Elements]. We'll tell you within the call whether this shape fits yours.

Flagship case — access on request.

Canyon's engagement sits under client-grade access terms: architecture, decisions and outcomes shown to named readers only. One short form and the full dossier opens now — plus a signed PDF mirror in your inbox.

← Back to clients
~ 30 seconds · instant access + PDF mirror emailed · no marketing follow-up