What Can SaaS Products Do to Improve Extensibility via PaaS?

by

I’ve spent over 12 years working on extending SaaS solutions using PaaS, mainly with SAP SuccessFactors (SFSF) and SAP Business Technology Platform (BTP). Over the years, I’ve seen what works, what doesn’t, and what I wish SaaS products would do to make extensibility easier.

The reality is that no enterprise SaaS product can meet every customer’s needs out of the box. That’s why extensibility matters—businesses need to add custom functionality, automate processes, and integrate with other systems. But too often, extending a SaaS product feels like fighting the system rather than working with it.

Here are some key things SaaS vendors can do to improve extensibility via PaaS, based on my experience.

1. Provide a Well-Defined Extension Framework

One of the biggest challenges I’ve faced is figuring out how to extend a SaaS product without breaking its core functionality. A well-defined extension framework makes all the difference.

SuccessFactors, for example, doesn’t allow direct UX or code customizations, but customers still need to build complex custom UI, workflows, and integrations. SAP’s BTP (PaaS) provides various options for extensibility.

What SaaS vendors could do:

  • Provide a clear extension model (side-by-side or in-app).
  • Offer SDKs and APIs for seamless integration.
  • Ensure extensions inherit the SaaS UI/UX for a smooth user experience.
  • Easier ramp up and onboarding for developers to learn and start developing quickly

2. Expose APIs and Enable Event-Driven Architecture

APIs are the heart of extensibility. If a SaaS product lacks a comprehensive set of APIs, I know I’m in for a headache. But APIs alone aren’t enough—event-driven architecture is just as important.

SuccessFactors for instance provides OData APIs for reading/writing data across all the L2 processes as well as significant coverage for L3 processes.

The SuccessFactors Event based Intelligent Framework lets us build event-driven extensions where a change in SFSF (like a new hire) automatically triggers workflows in BTP. This is a game-changer compared to old-school batch jobs and constant and inefficient polling.

What SaaS vendors could do:

  • Provide robust APIs with good documentation (a missing API can kill an extension project).
  • Support event-driven triggers so extensions don’t have to keep polling for changes.
  • Let custom apps subscribe to key events like user creation, approvals, or role changes.

3. Store Extension Data in SaaS, Not Just PaaS

One mistake I’ve seen companies make (and I’ve been guilty of it too) is storing all extension data in PaaS instead of leveraging the SaaS product itself. This makes reporting, security, and role-based permissions more complicated than they need to be.

With SuccessFactors extensions, for example, instead of dumping everything into a HANA database on BTP, we use the Meta Data Framework (MDF) to store extension data. MDF lets the data stay inside SuccessFactors, meaning it can inherit SFSF security, permissions, and business rules without extra work.

What SaaS vendors could do:

  • Provide built-in extensibility models (like MDF) so customers don’t have to build custom databases.
  • Let PaaS extensions store data inside the SaaS product when possible.
  • Ensure extended data follows SaaS security and compliance rules.

4. Support Low-Code/No-Code for Business Users

Not every extension needs hardcore development. One thing I’ve learned is that business users often want to make small tweaks without waiting for IT. That’s where low-code/no-code tools come in.

SaaS products can provide built-in workflow and rules engines for non-technical users. They can also offer low-code/no-code tools for simple extensions and ensure no-code configurations integrate with PaaS-based extensions.

5. Ensure Seamless UX Between SaaS & PaaS Extensions

One of my biggest pet peeves is when users have to jump back and forth between a SaaS system and an external extension. It kills productivity and confuses users, and from what I’ve heard – most of the users absolutely despise it.

But one key lesson I’ve learned: extensions should feel like they belong inside the SaaS system. That means keeping the same theme, logo, and menu structure so users don’t feel like they are jumping between different apps.

SaaS products can allow embedding of PaaS apps inside SaaS UI, provide SSO and role-based access to avoid extra logins as well as ensure extensions inherit SaaS branding and navigation.

I’ve worked on countless SAP SuccessFactors + BTP extension projects, and the same lessons keep coming up. A SaaS product’s extensibility is only as good as:

  1. Its extension framework (clear models, SDKs, and UI consistency).
  2. Its APIs and event-driven capabilities (to avoid unnecessary workarounds).
  3. How well it supports storing extension data (without breaking security & reporting).
  4. Its low-code/no-code tools (so business users can handle simple extensions).
  5. The UX flow between SaaS and extensions (because users shouldn’t feel like they’re switching systems).

If SaaS vendors get these things right, extensibility becomes an advantage rather than a challenge. But too often, I see SaaS products making it unnecessarily hard for customers to extend their solutions in a clean, scalable way.

Are you looking to extend any SAP SaaS products such as SuccessFactors, Ariba or Concur? Talk to us to learn how we can leverage over a decade of experience in SAP extensibility space to support you.