Getting the extension story right is the difference between a neat prototype and a scalable, maintainable CRM solution. Before you write any line of code, invest time to clarify the requirements and pick the right Side-By-Side Extension pattern for each scenario. Get the architecture right at beginning. The right choice gives you a solid, future-proof architecture. The wrong one creates duplication, higher costs, and brittle integrations.
Before we continue, let’s be crisp on the “why”. In other words, why does the right pattern matters at all? Simply for following reasons:
- Improve reusability: Many customers reuse the same UI extension across contexts—e.g., an SSCv2 widget that also appears in an S/4HANA flow—when they pick a pattern that naturally composes and ports.
- Save costs: Reuse of application logic across scenarios reduces build effort, accelerates delivery, and lowers maintenance.
Start with the Fundamentals
In case you start tailoring SSCv2 to your needs, you’d have to decide for each requirement if one if these requirements is applicable:
- Basic customizing: Ideal for configuration-level tweaks that don’t require code.
- In-App Extensibility: Add fields and small logic where supported — fastest way to align the standard UI with business data. Definitely a helpful resource on that is the blog article Adding Extension Fields in SAP Sales & Service Cloud V2 Integrations Using Post Exit Mode.
The simple rule of thumb: If the requirement is “change a field, add a field, tweak a screen” and stays inside certain guardrails — start here.
Side-By-Side Extension: Comprehensive SSCv2 extension patterns on BTP
When you need to go beyond the boundaries of in-app options, SSCv2 offers Side-By-Side Extension patterns that run on SAP Business Technology Platform (BTP). Use the following decision lens:
- Is it UI-first? → Custom Frontends (Mashups)
- Is it process/logic-first? → Custom Logic via Autoflows (async) or External Hooks (sync)
- Is it event-driven integration? → Standard Events (Pub/Sub)
- Is it a brand-new business object? → Custom Objects / Custom Services
But let’s dive into details, as always, above list depends on certain criteria.
Custom Frontends (Mashups)
What: Embed external front-ends in SSCv2 via iframes. You can place them as whole work centers, tabs, areas on create screens, or launch them via a button/modal. Parameters can be handed over so the mashup filters to just the relevant data. Limited two-way interaction with SSCv2 is possible (e.g., deep links back to SSCv2 areas).
Best for:
- Rich custom User Interfaces that the standard SSCv2 UI can’t express and that uses it’s own back-end
- Visualizations (KPIs, dashboards) or specialized flows that reuse a single frontend across apps
Get started:
If you want to learn more on that, open the SSCv2 extension workshop from Jens Limbach. It’s a great start.
- First side-by-side app on BTP
- Custom key metrics
Pros: Maximum UX freedom, reusable across systems
Cons: iFrame boundary; not ideal for heavy synchronous, in-UI validations
Custom Logic
Autoflows (asynchronous)
What: Configure a condition in SSCv2 to trigger any kind of logic in the background—call a microservice, write to a target system, and optionally update SSCv2 later. No front-end; That type of extension runs entirely behind the scenes.
Best for:
- Non-blocking workflows (enrichments, notifications, integrations)
- Heavy or long-running tasks
Get started:
Jump straight to the part 2 “Deploying a Microservice with Cloud Functions”, see below:
Pros: Scalable, resilient, decoupled from user interactions
Cons: No immediate user feedback; design for eventual consistency
External Hooks (synchronous)
What: A defined hook point calls your external service in real time to extend/validate behaviour. The response returns to the user immediately, enabling in-UI validation and instant updates.
Best for:
- Must-block validations and calculations
- Inline decisions where users need to see results right away
Get started:
- Webhooks in SAP Sales & Service Cloud V2
- Validation using External Hooks (opportunity item checks)
- Testing webhooks with incoming payloads from SSCv2
- SAP Help – Create External Hooks
Pros: Immediate user feedback, perfect for hard business rules
Cons: Tight coupling and latency sensitivity—design for reliability and timeouts
Standard Events (Publish/Subscribe)
What: Emit standard events with the event ID and basic payload to an event broker; downstream apps subscribe and react. This is an integration-first pattern that enables clean event-driven architecture.
Best for:
- Loose coupling across landscapes
- Audit trails and reactive integrations
- Fan-out to multiple consumers
Pros: Scalable, decoupled, testable
Cons: Requires event design/governance and consumer management
Custom Objects (Custom Services)
What: Build a new business object with your own backend technology. SSCv2 generates a standard UI for the custom object, and you can also bring a custom frontend (including AI-assisted builds).
Best for:
- Net-new domain objects not covered by standard
- Complex data structures and lifecycles
Helpful resources:
- Building a Custom Object with Standard Frontend (~18 min | Hands-On)
- Building a Custom Frontend using AI (~15 min | Hands-On)
Pros: First-class citizen in the UI, tailored data model
Cons: Highest ownership—lifecycle, versioning, and SLAs are on you
A quick decision checklist
Since we know things are time-wise tight in a project, we came up with below decision checklist. It should help you, e.g. as a customer or project manage, to judge what is proposed to you.
- Is standard enough? Try customizing/In-App first.
- UI-heavy or analytics-rich? → Mashup.
- Background workflow? → Autoflow (async).
- Inline validation or calculation? → External Hook (sync).
- Cross-system fan-out? → Standard Events.
- New domain object? → Custom Object / Service.
What makes a Future-proof architecture
- Separate concerns: Keep UI (mashups) thin; put rules in services so you can reuse them from hooks, autoflows, and other channels.
- Prefer events for integration: Use Pub/Sub to avoid point-to-point sprawl.
- Build once, reuse everywhere: Wrap business logic as BTP services; call them from SSCv2, S/4HANA, and beyond.
- Plan for resilience: External hooks must be fast and reliable; heavy lifting belongs in async flows.
- Document the contract: For hooks and events, treat payloads as versioned APIs.
Extending SSCv2 the Right Way: A Quick Summary
Pick the simplest path first: use customizing/In-App for small, safe tweaks. When you need richer UX, complex logic, eventing, or net-new objects, step up to BTP patterns. Choose the right Side-By-Side Extension for the moment—mashups, autoflows, external hooks, standard events, or custom services—based on who needs the outcome and when (user vs background, sync vs async, integration vs object model). Design for reusability and cost from day one and you’ll compound gains across the entire landscape.
