How to Extend SAP Sales Cloud V2 with Custom Cloud Foundry Apps on SAP BTP

SAP Sales Cloud V2 is a capable CRM out of the box. Lead management, opportunity tracking, account hierarchies, activity logging — it’s all there. But if you’ve spent any time configuring SSCV2 for a real enterprise, you’ve hit the wall where standard configuration stops and custom requirements begin.

Maybe it’s a field sales team that needs an AI-powered visit planner. A food distributor whose billing address determines the sales organisation. A call centre that needs Twilio-based browser calling logged directly into SSCV2 interactions. These aren’t edge cases. They’re Tuesday.

This is where custom Cloud Foundry applications on SAP BTP come in — and where we’ve spent the last three years building production extensions across multiple tenants and industries.

TL;DR: 35% of SAP BTP users now use the platform to extend SAP applications while maintaining a clean core (ASUG, 2025). We’ve shipped SSCV2 extensions across 4 patterns — HTML mashups, custom OData services, event-driven webhooks, and API integration — using a three-app Cloud Foundry architecture that deploys in weeks. Here’s exactly how each pattern works, with gotchas from production.

Why Does Standard SSCV2 Configuration Hit a Wall?

An estimated 20-70% of CRM projects fall short of expectations, primarily due to poor user adoption and the gap between what a CRM ships with and what users actually need (CRM.org, 2026). SSCV2’s configuration toolkit — adaptation mode, autoflows, key user settings — covers the fundamentals well. But it has hard boundaries.

You can’t build a custom UI that pulls data from three systems simultaneously. You can’t run complex business logic that queries S/4HANA, applies scoring algorithms, and writes results back. You can’t embed a real-time telephony widget with WebSocket event streaming. And you can’t register entirely new business objects with their own list views and detail pages.

That’s not a criticism — it’s the nature of any SaaS product. Why does this matter? Because the question isn’t whether you’ll need extensions. It’s how you build them without creating a maintenance nightmare. This is exactly why SAP invested in the side-by-side extension model — to give you a clean way out when configuration reaches its limit.

What Is the Side-by-Side Extension Model on BTP?

55% of ASUG members now use SAP BTP, up from 40% in 2023 — and 35% of those users specifically use BTP to customise and extend SAP apps while keeping a clean core (ASUG Pulse of the SAP Customer, 2025). The adoption trend is clear: enterprises are moving away from in-app modifications toward independent, upgrade-safe extensions.

Instead of modifying SSCV2’s core (which SAP explicitly discourages under their Clean Core strategy), you deploy independent Cloud Foundry applications that communicate with SSCV2 through APIs, events, and UI embedding.

Every production extension we’ve built follows a three-app Cloud Foundry architecture:

All three deploy to the same CF space. The AppRouter authenticates the user via XSUAA JWT tokens and routes requests to the backend or UI server. SSCV2 API calls go through the BTP Destination Service — never direct HTTP. This handles OAuth2 token exchange, certificate management, and connection pooling automatically.

From our experience: This three-app pattern isn’t theoretical. It’s running in production across our Engage CTI system, customer portal, WhatsApp integration, field sales visit planner, and product tracking mashups — all deployed on BTP Cloud Foundry.

How Do HTML Mashups Extend SSCV2?

HTML mashups are the simplest extension pattern and the fastest path to production. You register a URL, SSCV2 loads it in an iframe on the page layout you choose, and you’re done. No metadata registration. No OData endpoints. Just a web page that appears inside your CRM.

But “simple” doesn’t mean “limited.” The real power comes from the context SSCV2 passes to your mashup via URL query parameters — accountId, contactId, opportunityId, and any custom parameter you configure. Your mashup receives these, calls whatever APIs it needs, and renders a UI that would be impossible with standard configuration.

Real example: For a Swiss food distributor, we built a mashup that shows S/4HANA business partner data alongside SSCV2 account details. The sales rep sees delivery addresses, payment terms, and open orders from S/4 — all inside the SSCV2 account page, without switching systems.

Another example: Our visit planner for OPO Oeschger embeds a full drag-and-drop weekly planning interface inside SSCV2. An AI scoring algorithm evaluates 100+ accounts per sales rep, weighting overdue visits (40%), ABC classification (30%), visit cadence (20%), and geographic clustering (10%). The rep drags suggested visits onto their calendar — all within a mashup.

One constraint worth knowing: SSCV2 caps mashup iframe height at roughly 800 pixels (SAP Note 0003704111). Plan your UI accordingly.

How Do Custom OData Services Enable Deep Integration?

When a mashup isn’t enough and you need SSCV2 to treat your data as a first-class citizen, you register a custom service. This gives you full OData V4 entities with CRUD operations, list views, detail pages, and quick views — all rendered by SSCV2’s native UI framework.

The registration flow has six steps:

1. POST your OData V4 metadata to SSCV2’s repository-service
2. Create a data connector in DIRECT mode pointing to your CF AppRouter URL
3. Configure UI views (work list, detail, quick view) in the SSCV2 UI designer
4. Assign the service to a role via the IAM service
5. Create extension fields on related entities if needed
6. Register the OData endpoint on your Express backend

Once registered, SSCV2 calls your CF app as if it were a native data source. Users see your custom entities in the navigation, search and filter them, and drill into detail pages — all within the standard SSCV2 experience.

We’ve used this pattern for payment gateway integration (Wallee) and product tracking services. The key advantage over mashups? Your data participates in SSCV2’s relationship model. You can link custom entities to accounts, contacts, and opportunities through extension fields.

How Do Webhooks Enable Event-Driven Extensions?

SSCV2 autoflows can trigger webhooks — HTTP POST calls to your CF app when specific events occur. This is how you build reactive extensions that respond to CRM activity in real time, without polling or user intervention.

From our production deployment: For Intelligentfood, we built a webhook handler that fires when a new account is created in SSCV2. The handler reads the billing address, determines the correct sales organisation (Switzerland, Austria, France, or Netherlands based on country code), and patches the account with the appropriate salesArrangements entry. What would require manual assignment by an admin happens automatically in under a second.

The webhook pattern uses Basic Auth rather than XSUAA — it’s server-to-server with no user context. SSCV2 retries failed webhooks with exponential backoff, so your handler needs to be idempotent.

One gotcha we learned early: SSCV2’s $batch API isn’t supported through the Destination Service (returns HTTP 405). If your webhook handler needs to update multiple entities, use concurrent individual calls — we’ve tested up to 30 parallel requests without issues using Promise.all().

What Are the Best Patterns for API Integration and Data Sync?

Companies using CRM effectively see a 29% increase in sales and a 34% improvement in sales productivity (CRM.org, 2026). But those gains depend on your CRM containing the right data. Many extensions are purely about bridging that gap — syncing SSCV2 with ERP systems, enriching records from external sources, or exposing CRM data to other platforms.

All SSCV2 REST API access from CF apps goes through the BTP Destination Service with one of two auth patterns:

Extension fields are how you store custom data on standard SSCV2 entities. Create them via the repository-service API and access them through the extensions object on every entity response. We use them extensively for visit blocking flags, customer group codes, and integration sync timestamps.

A word of caution: extension field deletion is permanent. It removes all stored values across all records with no rollback. Always test in your QAS tenant first.

For S/4HANA integration, SAP Integration Suite handles data replication through iFlows. Our Intelligentfood project uses this for bi-directional sync between S/4 business partners and SSCV2 accounts — a common pattern for companies running both systems.

How Does Authentication and Multi-Tenancy Work in Practice?

The biggest barrier to BTP adoption remains the skills gap — 46% of organisations cite it as their top challenge, followed by development complexity at 43% (Precisely 2026 SAP Trends Survey). Authentication and multi-tenancy are exactly where that complexity concentrates. Here’s what we’ve settled on after deploying across multiple tenants:

XSUAA is non-negotiable. Every CF app gets an XSUAA service instance. The AppRouter validates JWT tokens and forwards them to the backend. Your Express server uses @sap/xssec to extract user identity and check scopes.

Custom IDP for SSO. When your extension loads inside a SSCV2 mashup iframe, the user is already authenticated. Without a custom IDP, the iframe would prompt them to log in again. By configuring SAP IAS as a trusted identity provider and setting identityProvider: "sap.custom" in the AppRouter, you get seamless single sign-on.

Multi-tenancy via environment files. Each customer gets their own BTP subaccount with a dedicated XSUAA instance. We manage per-tenant configuration through .env.<tenantId> files that feed into manifest.yml variable substitution at deploy time. Same codebase, isolated infrastructure.

What Sets Spadoom Apart?

SAP’s partner ecosystem includes over 25,000 companies (SAP News Center, 2025). So why work with us? Because we don’t just advise on SSCV2 extensibility — we ship production code.

Engage is our flagship extension suite: CTI with Twilio browser calling, a self-service customer portal, WhatsApp messaging with interaction logging, SharePoint document integration, and a cross-product admin hub. Six separate applications deployed as multi-tenant SaaS on BTP.

MCP-SSCV2 wraps 65+ SSCV2 REST APIs as AI-accessible tools, letting Claude interact with Sales Cloud V2 programmatically. It’s how we automate tenant setup, test API behaviour, and prototype new extension ideas faster than anyone with a Postman collection.

Intelligentfood handles the full S/4HANA-to-SSCV2 integration for a Swiss food company — webhook-driven account assignment, visit planning, and bi-directional data sync across two BTP destinations.

OPO Oeschger’s visit planner uses AI scoring to prioritise 100+ accounts per sales rep per week, with drag-and-drop scheduling embedded directly in SSCV2.

These aren’t conference demos. They’re production systems handling real data for real sales teams, every day.

Frequently Asked Questions

Can you extend SAP Sales Cloud V2 without modifying the core?

Yes. SAP’s side-by-side model on BTP lets you deploy CF apps that integrate via APIs, mashups, and webhooks — without touching core SSCV2. 35% of BTP users now use this clean core extension approach (ASUG, 2025).

What’s the difference between an HTML mashup and a custom service?

Mashups embed your web app as an iframe — great for dashboards and quick integrations. Custom services register full OData V4 entities that SSCV2 treats as native data, with standard list views, detail pages, and CRUD operations. See our SAP BTP overview for how both fit into the platform’s architecture.

How does authentication work for extensions on BTP?

XSUAA handles JWT-based auth, with the Destination Service managing token exchange. For SSO in mashup iframes, configure SAP IAS as a custom identity provider so users authenticate once.

How long does it take to build a custom SSCV2 extension?

A basic HTML mashup: 1-2 weeks. Custom OData service with CRUD: 3-6 weeks. Complex multi-pattern extensions like CTI or visit planning: 2-4 months depending on scope.

Does Spadoom support multi-tenant deployments?

Every extension we build supports multi-tenant deployment with isolated BTP subaccounts per customer. Same codebase, environment-based configuration, independent infrastructure.

Start Building

If your SSCV2 instance is bumping against the limits of standard configuration, you don’t need to compromise. Custom Cloud Foundry applications on BTP give you the full power of a modern development platform while keeping your CRM core clean and upgrade-safe.

We’ve built these extensions across industries — food distribution, building materials, financial services — and we’ve distilled the patterns into a repeatable architecture that deploys in weeks, not months. Whether you’re migrating from C4C or extending a fresh SSCV2 instance, the approach is the same.

Ready to extend your SAP Sales Cloud V2? Talk to our SSCV2 extension team — we’ll scope what’s possible.