We’re having heated debates in our architecture team about how far to customize SAP CX workflow automation. We have complex approval workflows, multi-stage lead nurturing processes, and automated escalations that don’t quite fit standard workflow templates. The business wants deep customization to match their exact processes, but I’m concerned about maintaining clean core principles and the upgrade pain we’ll face. Every SAP presentation talks about clean core and side-by-side extensions, but the reality is that meaningful workflow automation often requires touching core objects and processes. How do others balance business requirements for customized workflows against the principle of maintaining upgradability? Is clean core realistic for complex enterprise implementations, or is it more of an aspirational goal?
SAP’s workflow engine in CX actually has good extension capabilities that people underutilize. You can create custom workflow steps that hook into standard workflows without modifying the core workflow definitions. This gives you customization flexibility while maintaining upgradability. The key is understanding the workflow framework’s extension points and using them properly instead of directly modifying delivered workflows.
The clean core conversation often misses a critical point - it’s not binary. You can have varying degrees of customization depth. Some workflows might be 90% standard with 10% custom steps. Others might be 50-50. The goal should be minimizing the customization footprint, not eliminating it entirely. Track your customization depth metrics - what percentage of workflow steps are custom versus standard? This gives you concrete data for upgrade planning.
Consider the strategic direction of SAP CX development. SAP is moving toward more composable architecture with BTP extensions. If you build deep customizations now in the traditional way, you might be building technical debt. Better to invest in learning BTP extension patterns and building workflow customizations as side-by-side extensions that communicate via APIs. It’s more work upfront but pays off in upgrade flexibility.
Clean core is definitely aspirational for most enterprises. The reality is that business processes are unique and competitive differentiators often come from how you automate workflows. That said, you can be smart about where you customize. We follow a rule: if it’s a workflow that’s likely to change frequently based on business conditions, build it as an extension. If it’s core to how the business operates and relatively stable, deeper customization is justified.
We took a phased approach - started with standard workflows even though they weren’t perfect, then added customizations incrementally based on actual pain points rather than perceived requirements. This prevented over-customization. Many workflows that business initially said needed customization ended up working fine with standard functionality once users adapted their processes slightly. Sometimes the business process should change to fit the system rather than always bending the system to fit the process.
After leading SAP CX implementations for enterprise customers over the past decade, here’s my perspective on all three dimensions:
Clean Core Principles in Practice:
Clean core is achievable but requires discipline and trade-offs. The principle isn’t about zero customization - it’s about strategic customization that maintains upgradability. For workflow automation specifically:
Adhere to clean core by:
- Using workflow extension framework rather than modifying delivered workflows
- Building custom workflow steps as separate components that plug into standard workflow engine
- Leveraging workflow templates and creating instances rather than changing templates
- Using workflow variables and dynamic routing instead of hardcoded logic
- Implementing custom business logic in separate services called by workflows, not embedded in workflow definitions
Accept necessary deviation when:
- Standard workflow engine limitations prevent critical business requirements
- Regulatory compliance requires specific audit trails or approval sequences not supported by standard workflows
- Performance requirements demand optimization of core workflow processing
- Integration with legacy systems requires workflow modifications that can’t be achieved through standard extension points
Deep Customization Reality:
Deep customization is sometimes necessary, but manage it strategically:
Categorize your customizations:
- Critical differentiators (15-20% of customizations): These provide competitive advantage and justify deep customization even with upgrade costs
- Process adaptations (50-60%): Business process variations that could potentially be achieved with configuration or light customization
- Convenience features (20-30%): Nice-to-have customizations that should be eliminated if they impact upgradability
For your specific scenarios:
- Complex approval workflows: Usually achievable with workflow templates + custom approval steps (medium depth)
- Multi-stage lead nurturing: Good candidate for BTP side-by-side extension calling CX APIs (low depth)
- Automated escalations: Can use standard workflow time-based triggers + custom notification logic (medium depth)
Implement governance for customization decisions:
- Require business case justification for any customization deeper than using standard extension points
- Estimate upgrade impact cost upfront and include in business case
- Mandate that all deep customizations have documented rollback/simplification plans
- Review customization inventory quarterly and identify candidates for simplification
Upgrade Challenges Management:
Upgrade pain is proportional to customization depth and documentation quality. Minimize upgrade challenges:
Before customizing:
- Create customization impact assessment: For each customization, document which standard objects/processes are affected
- Establish testing baseline: Automated tests for all custom workflows that can be run against new versions
- Version control everything: All custom workflow definitions, scripts, and configurations in version control with change tracking
During implementation:
- Isolate custom code: Use clear naming conventions (ZCUSTOM_ prefix for custom objects)
- Abstract integration points: Create wrapper services for any custom code that interacts with standard workflows
- Document business logic separately from technical implementation: When upgrade requires technical changes, business logic documentation helps rebuild
Upgrade preparation:
- Run custom workflows in sandbox against new version 3-4 months before production upgrade
- Identify breaking changes early and assess: fix customization, adapt business process, or adopt new standard feature
- Budget realistic upgrade effort: For heavily customized workflow implementations, plan for 40-60 hours per major release for testing and adjustments
- Maintain upgrade journal: Document what broke, how it was fixed, and lessons learned for next upgrade
For your architecture team’s debate, here’s my recommendation:
Establish a customization framework with clear boundaries:
- Tier 1 (Preferred): Use standard workflows with configuration only - no custom code (target: 60% of workflows)
- Tier 2 (Acceptable): Standard workflows with custom steps using extension framework (target: 30% of workflows)
- Tier 3 (Justified exception): Deep customization with modified core workflows (limit to 10% of workflows, require executive approval)
For each proposed workflow customization, force the decision through this framework. Business must justify why Tier 1 or Tier 2 approaches won’t work before approving Tier 3 customization. This makes the trade-offs explicit and creates accountability for upgrade costs.
Clean core is realistic for 80-90% of enterprise requirements if you’re willing to adapt business processes and use extension frameworks properly. The remaining 10-20% of deep customizations should be strategic choices, not defaults. The key is making these decisions consciously with full understanding of long-term implications rather than customizing reactively to every business request.
Having gone through three major upgrades with heavily customized workflow implementations, I can tell you the pain is real. We spent 6 months on our last upgrade, with most time spent on workflow compatibility testing and rework. The issue isn’t just the technical work - it’s the business disruption when workflows behave differently after upgrade. Document everything meticulously if you go the deep customization route.