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 are everyday requirements, not edge cases.

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

TL;DR: When SAP Sales Cloud V2 configuration reaches its limits, you extend it side by side on SAP BTP instead of modifying the core. We use four patterns: HTML mashups, custom OData services, event-driven webhooks and API integration, all on a three-app Cloud Foundry architecture (AppRouter, Node.js backend, static UI). This post explains how each pattern works and the production gotchas we ran into.

Why Does Standard SSCV2 Configuration Hit a Wall?

CRM projects often fall short when there is a gap between what the product ships with and what users actually need. 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 is not a criticism; it is the nature of any SaaS product. The question is not whether you will need extensions, but 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 its clean core guidance), 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:

Component	Technology	Purpose
AppRouter	@sap/approuter	XSUAA authentication, CORS, routing, iframe embedding; the single entry point SSCV2 calls
Express Backend	Node.js + Express	REST API, business logic, OData proxying, WebSocket support, external integrations
Static UI Server	HTML/CSS/JS	Mashup pages embedded in SSCV2 screens

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 model ranks the accounts in each rep’s territory by factors such as overdue visits, ABC classification, visit cadence and geography, as described in the OPO Oeschger success story. 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 is server-to-server with no user context. Make your handler idempotent, so that an event delivered more than once does no harm.

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?

A CRM is only as useful as the data it contains. 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:

Auth Pattern	Use Case	When to Use
OAuth2SAMLBearerAssertion	User-propagated identity	Operations that should respect SSCV2’s role-based access control
Basic Auth (technical user)	Server-to-server	Background jobs, integrations, webhooks with no user context

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?

Authentication and multi-tenancy are where most of the complexity of BTP extensions concentrates. This is what we have 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, the user signs in once and never sees a second login prompt.

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 SAP Sales Cloud V2 programmatically. It’s how we automate tenant setup, test API behaviour, and prototype new extension ideas much faster than by hand.

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 which customers each sales rep visits, 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. This is the clean core approach SAP recommends for new extensions.

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?

In our projects, a basic HTML mashup is typically live in one to two weeks and a custom OData service with full CRUD in three to six weeks. Extensions that combine several patterns, such as CTI integration or visit planning, take two to four months depending on scope.

Does Spadoom support multi-tenant deployments?

Yes. Our extensions are built for multi-tenant deployment with a separate BTP subaccount per customer. The same codebase serves all tenants through environment-based configuration, while each customer keeps isolated 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 have built these extensions across industries (food, building materials, packaging) and distilled the patterns into a repeatable architecture that deploys in weeks, not months. Whether you are migrating from C4C or extending a fresh SSCV2 instance, the approach is the same. The same side-by-side pattern extends S/4HANA Public Cloud, which is why we use one team for both, as explained in our guide to choosing an SAP partner for Cloud ERP and CRM in Switzerland. For a comparison of BTP development partners, see the best SAP BTP development partners in Switzerland.

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