Key User Extensibility enables business users to extend SAP systems without developer knowledge. This article explains the concept, shows practical examples, and differentiates Key User from Developer Extensibility.
Key User vs. Developer Extensibility
SAP distinguishes two extensibility models:
| Aspect | Key User Extensibility | Developer Extensibility |
|---|---|---|
| Target audience | Business users, consultants | ABAP developers |
| Tools | Fiori Apps, Browser | ADT/Eclipse, BAS |
| Programming | None (Low-Code/No-Code) | ABAP Cloud |
| Flexibility | Limited | Full control |
| Transport | Automatic | Manual/gCTS |
| Availability | Public Cloud, Private Cloud | All editions |
When to Use Key User Extensibility?
Key User Extensibility is suitable for:
- Simple field extensions without complex logic
- Quick adjustments during operations
- Prototyping before developer implementation
- Business-driven changes without IT bottleneck
When to Use Developer Extensibility?
Developer Extensibility is better for:
- Complex business logic with ABAP code
- Performance-critical extensions
- Integration with external systems
- Reusable components
Creating Custom Fields
Custom Fields are the most common scenario for Key User Extensibility.
Step-by-Step: Create Custom Field
- Open App: Fiori App “Custom Fields and Logic” (F1481)
- Choose Business Context: e.g., “Sales Order” or “Business Partner”
- Add Field: Click “New” button
Field Types
| Field Type | Example | Usage |
|---|---|---|
| Text | Remarks field | Free text up to 1333 characters |
| Number | Discount level | Integers or decimal |
| Amount | Bonus amount | With currency |
| Quantity | Additional quantity | With unit |
| Date | Review date | Calendar date |
| Time | Processing time | Time of day |
| Checkbox | Is reviewed | Yes/No |
| Code List | Priority | Dropdown with fixed values |
Example: Custom Field “Customer Priority”
Business Context: Business Partner - CustomerField Label: Customer PriorityTechnical Name: YY1_CUSTOMER_PRIORITYField Type: Code List
Values:- A = High Priority- B = Medium Priority- C = Low Priority- D = No ClassificationUsage in UIs
After creation, the field can be activated for:
- Fiori Elements Apps: Automatic integration
- Transactional Apps: In forms and lists
- Analytical Apps: In reports and dashboards
Technical Background
Custom Fields are technically implemented as:
- Extension Include: Embedded in the standard table
- CDS View Extension: Automatically available in views
- Service Extension: Exposed in OData services
-- Automatically generated CDS View Extensionextend view I_BusinessPartner with ZE_BusinessPartner_CF { YY1_CUSTOMER_PRIORITY as CustomerPriority}Custom Logic with BAdIs
For simple business logic, Key User Extensibility offers predefined BAdIs.
Available BAdI Triggers
| Trigger | Timing | Typical Usage |
|---|---|---|
| On Modify | On field change | Field validation, default values |
| On Save | Before saving | Complex validations |
| After Save | After saving | Follow-up actions |
| Determination | Automatic | Value derivation |
Example 1: Set Default Value
Scenario: For new customers, the field “Customer Priority” should automatically be set to “C”.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: DeterminationTrigger: On Create
Condition: Customer number is initial
Action: Set field "YY1_CUSTOMER_PRIORITY" = "C"The graphical interface generates:
" Generated code (not directly visible)IF customer-customer_id IS INITIAL. customer-yy1_customer_priority = 'C'.ENDIF.Example 2: Field Validation
Scenario: Customers with Priority “A” must have a contact person.
App: Custom Fields and LogicBusiness Context: Business Partner - CustomerLogic Type: ValidationTrigger: On Save
Condition: YY1_CUSTOMER_PRIORITY = "A" AND Contact person is empty
Action: Error: "High-priority customers require a contact person"Extended Expressions
Key User Logic supports:
// Comparison operatorsField1 = "Value"Field2 <> "Value"Field3 > 100Field4 >= 50
// Logical operatorsCondition1 AND Condition2Condition1 OR Condition2NOT Condition1
// Field operationsField1 + Field2Field1 * FactorLENGTH(TextField) > 10TODAY()Custom CDS Views
Key Users can also create their own analytical views.
Custom CDS Views App
The app “Custom CDS Views” (F2170) enables:
- New views based on existing views
- Add calculated fields
- Define filters and aggregations
Example: Customer Overview with Priority
Base View: I_BusinessPartner
Custom View: YY1_CustomerOverview
Fields:- BusinessPartner (from I_BusinessPartner)- BusinessPartnerName (from I_BusinessPartner)- CustomerPriority (Custom Field)- OrderCount (Calculated: Number of orders)- TotalRevenue (Calculated: Sum of revenue)
Filter:- BusinessPartnerCategory = '1' (customers only)
Aggregation:- Grouping by CustomerPriorityGenerated CDS View
@AbapCatalog.viewEnhancementCategory: [#NONE]@Analytics.query: true@VDM.viewType: #CONSUMPTIONdefine view entity YY1_CustomerOverview as select from I_BusinessPartner as BP association [1..*] to I_SalesOrder as _Orders on $projection.BusinessPartner = _Orders.SoldToParty{ key BusinessPartner, BusinessPartnerName, YY1_CUSTOMER_PRIORITY as CustomerPriority,
@Aggregation.default: #SUM count( distinct _Orders.SalesOrder ) as OrderCount,
@Aggregation.default: #SUM @Semantics.amount.currencyCode: 'Currency' sum( _Orders.TotalNetAmount ) as TotalRevenue,
_Orders.TransactionCurrency as Currency}where BP.BusinessPartnerCategory = '1'group by BusinessPartner, BusinessPartnerName, YY1_CUSTOMER_PRIORITY, _Orders.TransactionCurrencyLimitations and Constraints
Key User Extensibility has clear limitations:
Technical Constraints
| Constraint | Details |
|---|---|
| Number of fields | Max. ~200 Custom Fields per Business Context |
| Field length | Text max. 1333 characters |
| Complex logic | No loops, no external calls |
| Performance | Performance may suffer with many fields |
| Debugging | Limited error analysis |
Functional Constraints
- No table logic: No processing of internal tables
- No API calls: No RFC, HTTP or OData calls
- No workflows: Only predefined triggers
- No unit testing: No automated tests
Unsupported Scenarios
- Complex calculations across multiple objects- Integration with third-party systems- Mass processing- Custom UIs (only field integration)- Background jobs- Custom transactionsUpgrade Behavior
- Custom Fields are preserved during upgrades
- Custom Logic may be deactivated for breaking changes
- Regular review recommended
Governance and Best Practices
Naming Conventions
Prefix for Custom Objects: YY1_ or ZZ1_(automatically assigned by the system)
Recommendation for field names:- Descriptive: YY1_CUSTOMER_PRIORITY instead of YY1_FIELD01- Consistent: Same terms for same concepts- Documented: Maintain label and descriptionProcess for Key User Extensibility
1. Document requirement - What should be extended? - Why is the standard not sufficient?
2. Feasibility check - Is Key User Extensibility sufficient? - Or does it need Developer Extensibility?
3. Implementation - Create in development system - Test
4. Transport - Transport to quality system - Acceptance test
5. Go-Live - Activate in production - MonitoringDocumentation
Every extension should document:
| Aspect | Example |
|---|---|
| Purpose | ”Enables prioritization of customers for sales” |
| Business Owner | ”Sales Management” |
| Technical Name | ”YY1_CUSTOMER_PRIORITY” |
| Dependencies | ”Used in Report XY, Integration with CRM” |
| Test Cases | ”New customers: Default ‘C’, High Priority requires contact” |
Combining Key User & Developer Extensibility
Often both models are combined:
Step 1: Key User Extensibility├── Create Custom Field "Customer Priority"├── Simple default value logic└── Make available in UI
Step 2: Developer Extensibility (if needed)├── Complex calculation logic in ABAP├── Integration with external CRM└── Custom report with ALVMigration from Key User to Developer
When Key User Extensibility is no longer sufficient:
- Keep Custom Field: Data basis remains
- Replace Custom Logic: Create ABAP implementation
- Implement BAdI: Full ABAP functionality
- Deactivate Key User Logic: Avoid duplicates
Practical Example: Customer Rating
Requirement
A company wants to automatically rate customers based on:
- Revenue of the last 12 months
- Payment behavior
- Complaint rate
Implementation with Key User Extensibility
Step 1: Create Custom Fields
Business Context: Business Partner - Customer
Custom Fields:1. YY1_REVENUE_12M (Amount) - Revenue 12 months2. YY1_PAYMENT_SCORE (Number) - Payment score 1-53. YY1_COMPLAINT_RATE (Number) - Complaint rate %4. YY1_CUSTOMER_RATING (Code List) - Rating A/B/C/DStep 2: Custom Logic for Rating
Trigger: On Save
Rule 1:IF YY1_REVENUE_12M > 100,000 AND YY1_PAYMENT_SCORE >= 4 AND YY1_COMPLAINT_RATE < 2THEN YY1_CUSTOMER_RATING = "A"
Rule 2:IF YY1_REVENUE_12M > 50,000 AND YY1_PAYMENT_SCORE >= 3 AND YY1_COMPLAINT_RATE < 5THEN YY1_CUSTOMER_RATING = "B"
Rule 3:IF YY1_REVENUE_12M > 10,000 AND YY1_PAYMENT_SCORE >= 2THEN YY1_CUSTOMER_RATING = "C"
Rule 4: (Default)THEN YY1_CUSTOMER_RATING = "D"Step 3: Custom CDS View for Analysis
View: YY1_CustomerRatingAnalysis
Fields:- Number of customers per rating- Average revenue per rating- Trend vs. previous year
Grouping: YY1_CUSTOMER_RATINGLimitations of This Solution
This Key User solution has limitations:
- Revenue data must be maintained manually
- No automatic calculation from documents
- No historization of ratings
For a complete solution, Developer Extensibility would be needed:
- Automatic revenue determination via ABAP
- Background job for regular recalculation
- History table for rating trends
Further Reading
- Developer Extensibility - Extensions with ABAP Cloud
- Custom Fields Deep Dive - Technical details on Custom Fields
- Clean Core Strategy - Extensibility in the context of Clean Core