BAdI vs User Exit for custom approval workflows in formula management

PLM SAP PLM
, , , , , , , ,
1

I’m designing custom approval workflows for our formula management implementation and trying to decide between using BAdI enhancement framework versus traditional user exits. We need to add custom validation logic and route approvals based on formula complexity scores and regulatory classification.

The BAdI approach seems cleaner and more maintainable, but I’m concerned about the learning curve for our team who are more familiar with user exits. On the other hand, user exits have that nagging upgrade impact concern - we’ve been burned before during SAP upgrades when our user exit code broke.

What’s the community consensus on workflow customization for formula management? Is BAdI extensibility worth the investment, or are user exits still viable for this use case? I’d love to hear from anyone who’s maintained these customizations through multiple upgrade cycles.

system 2

BAdI is the correct architectural choice here, and your upgrade concern about user exits is well-founded — this isn’t a close call.

Pre-Upgrade Checks (source system)

Before committing to either path, audit your current landscape:

  • Run SE18 / SE19 to inventory any existing BAdI implementations in PLM formula management objects (look for enhancement spots prefixed PLM_RCP*, DRF*, verify naming in your version)
  • Check SMOD/CMOD for active user exit projects touching recipe/formula objects — document every EXIT_* function module with custom code
  • Confirm your target release’s compatibility matrix for any user exits you currently rely on; user exits in QM and PP-PI adjacent areas have historically been deprecated or signature-changed across major releases
  • Validate that your approval workflow objects (formula status profiles, change documents) are compatible with the target BAdI enhancement framework version

Migration Sequence: User Exit → BAdI for Approval Workflow

  1. Map each user exit’s business logic to a corresponding BAdI definition — for complexity scoring and regulatory routing, target enhancement spots around formula release/status change events (verify exact spot names in your PLM recipe management IMG)
  2. In SE18, identify the appropriate BAdI definition; if none exists for your exact hook point, investigate BADI_ENHANCEMENT via implicit enhancement spots in SE24 on the relevant formula manager classes
  3. Create a BAdI implementation in SE19; encapsulate complexity scoring as a dedicated method — separating scoring logic from routing logic enables independent unit testing
  4. Implement filter-based BAdIs if your regulatory classification routing needs multi-instance behavior (different logic per classification type) — this replaces conditional branching that typically bloats user exit code
  5. Wrap the new BAdI implementation behind a feature-flag configuration (a custom Customizing table) so both old and new paths can run in parallel during parallel-run testing
  6. Execute regression tests against formula approval scenarios in a sandbox on the target release before decommissioning user exit code
  7. Remove user exit implementations from the CMOD project only after sign-off; inactive but registered exits can still cause transport conflicts

Rollback Procedure

  • The parallel-run flag (step 5) is your primary rollback mechanism — switching the Customizing table entry reverts to user exit execution without a transport
  • Keep the CMOD project and EXIT function module code inactive but not deleted until post-go-live stabilization (minimum one full approval cycle in production)
  • If BAdI implementation causes runtime errors, SE19 allows deactivating individual implementations without transport — use this for hotfix scenarios
  • Document the exact filter values and BAdI implementation names in your runbook so basis can deactivate without developer involvement during off-hours incidents

On team learning curve: the investment is real but bounded. BAdI development in SE18/SE19 follows consistent patterns once your team builds the first two implementations. The maintenance advantage through upgrades is substantial — SAP’s explicit contract is that BAdI definitions are upgrade-stable; user exit function module signatures carry no such guarantee. Teams familiar with ABAP OO adaptation handle BAdIs within a sprint or two (verify training availability for your specific PLM release).

For complexity scoring specifically, keep that logic in a standalone class testable via SE24 — don’t embed it directly in the BAdI method implementation.

This draft is based on general SAP PLM knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

Go with BAdIs, no question. We just completed an upgrade from SAP PLM 2020 to 2024 and our BAdI implementations required zero changes. Meanwhile, three out of five user exits needed rework. The upgrade impact difference is real and significant.

4

BAdIs are definitely more future-proof, but there’s a practical consideration here. If your team is experienced with user exits, the development velocity will be much faster initially. BAdIs require understanding the enhancement framework, filter concepts, and implementation classes. That said, once you’ve got one BAdI working, the pattern is reusable across all your customizations. We made the switch three years ago and haven’t looked back. The BAdI extensibility model is just superior - you get better separation of concerns, easier testing, and cleaner code organization. For formula management specifically, there are good BAdI hooks for approval workflow customization.

5

That’s helpful - what BAdIs are available specifically for formula approval workflows? I’ve looked at the enhancement spots but the documentation is sparse. Are there good examples of formula complexity validation implemented via BAdI?

6

Check BAdI PLM_FORMULA_APPROVAL for approval routing and PLM_FORMULA_CHECK for custom validation logic. The validation BAdI lets you inject your complexity scoring algorithm before the standard approval determination. We use it to calculate hazard scores based on ingredient combinations and route to different approval chains. Works beautifully and survived two upgrades without modification.

7

Playing devil’s advocate here - user exits still have a place. They’re simpler, more transparent, and easier to debug when things go wrong. Yes, upgrades can be problematic, but if you code defensively and document well, the rework isn’t that bad. We’ve maintained user exit-based approval logic for 8 years with manageable upgrade effort.

8

The upgrade impact argument is compelling, but there’s another angle: SAP is actively deprecating user exits in newer releases. Some exits that existed in 2020 are already gone in 2024. If you build on user exits now, you’re building technical debt. BAdI framework is the strategic direction SAP has committed to.

9

Having implemented both approaches across multiple SAP PLM installations, I can offer a comprehensive perspective on all three dimensions:

BAdI Extensibility Benefits: The BAdI framework provides significant architectural advantages for workflow customization. Key benefits include:

  • Object-oriented design with proper encapsulation - your custom logic lives in implementation classes that are cleanly separated from SAP standard code
  • Multiple implementations possible for the same BAdI definition, allowing different logic for different organizational units or formula types using filter values
  • Better testability through dependency injection and unit test frameworks
  • No direct modification of SAP code - you’re implementing interfaces, not changing delivered programs
  • Explicit contracts via interface definitions that make upgrade impacts immediately visible
  • Support for fallback classes and default implementations

For formula management approval workflows specifically, BAdIs give you hooks at the right granularity. You can customize approval determination, add validation steps, modify routing logic, and inject custom notifications all through well-defined interfaces.

User Exit Upgrade Impact Reality: The upgrade pain with user exits is well-documented but worth quantifying. In our experience across four major upgrades:

  • 60-70% of user exits required some rework during upgrades
  • Common issues: changed function module signatures, removed parameters, altered calling contexts
  • Debugging upgrade failures in user exits is time-consuming because you’re working in modified SAP code
  • Risk of subtle bugs introduced when SAP changes the logic surrounding the exit point
  • Increasing difficulty getting OSS notes for user exit issues as SAP phases them out

The technical debt compounds over time. Each upgrade cycle adds more risk and effort. BAdIs, by contrast, showed 90%+ survival rate across the same upgrades with clear interface change documentation when modifications were needed.

Workflow Customization Practical Considerations: For your specific use case (formula complexity scoring and regulatory routing), here’s my recommendation:

Use BAdI PLM_FORMULA_CHECK for validation logic:

  • Implement your complexity scoring algorithm in method CHECK_FORMULA
  • Access formula components, quantities, and properties through the interface parameters
  • Return validation messages and severity levels that integrate with standard workflow
  • Filter by formula type or plant if you need different scoring logic by context

Use BAdI PLM_FORMULA_APPROVAL for routing:

  • Implement method DETERMINE_APPROVERS to inject your custom approval chain
  • Base routing on the complexity score calculated in your check BAdI
  • Access regulatory classification from formula master data
  • Return approver user IDs and sequence numbers

Implementation approach to manage the learning curve:

  1. Start with one pilot BAdI implementation for a single formula type
  2. Create a reference implementation with comprehensive comments
  3. Build a reusable base class that handles common patterns (data access, logging, error handling)
  4. Train the team on the successful pilot before expanding
  5. Document the BAdI pattern as your standard approach for all future customizations

The initial velocity hit is real - expect 20-30% slower development for the first few BAdIs as the team learns. But this is a one-time investment that pays dividends. By the third or fourth BAdI, your team will be faster than they were with user exits due to the better structure and reusability.

Strategic Recommendation: Go with BAdIs. The workflow customization requirements you described are exactly the scenario where BAdI extensibility shines. The upgrade impact concern alone justifies the approach, but you also get better maintainability, testability, and alignment with SAP’s strategic direction. Accept the learning curve as an investment in technical capability that will benefit all your future PLM customizations.

If you absolutely must use a user exit for some edge case (rare, but it happens), isolate it, document extensively why BAdI wasn’t viable, and plan to refactor it to BAdI in your next enhancement window.