Key User Extensibility: Extensions Without Developer Access

Category
ABAP Cloud
Published
Author
Johannes

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:

AspectKey User ExtensibilityDeveloper Extensibility
Target audienceBusiness users, consultantsABAP developers
ToolsFiori Apps, BrowserADT/Eclipse, BAS
ProgrammingNone (Low-Code/No-Code)ABAP Cloud
FlexibilityLimitedFull control
TransportAutomaticManual/gCTS
AvailabilityPublic Cloud, Private CloudAll 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

  1. Open App: Fiori App “Custom Fields and Logic” (F1481)
  2. Choose Business Context: e.g., “Sales Order” or “Business Partner”
  3. Add Field: Click “New” button

Field Types

Field TypeExampleUsage
TextRemarks fieldFree text up to 1333 characters
NumberDiscount levelIntegers or decimal
AmountBonus amountWith currency
QuantityAdditional quantityWith unit
DateReview dateCalendar date
TimeProcessing timeTime of day
CheckboxIs reviewedYes/No
Code ListPriorityDropdown with fixed values

Example: Custom Field “Customer Priority”

Business Context: Business Partner - Customer
Field Label: Customer Priority
Technical Name: YY1_CUSTOMER_PRIORITY
Field Type: Code List
Values:
- A = High Priority
- B = Medium Priority
- C = Low Priority
- D = No Classification

Usage 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 Extension
extend 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

TriggerTimingTypical Usage
On ModifyOn field changeField validation, default values
On SaveBefore savingComplex validations
After SaveAfter savingFollow-up actions
DeterminationAutomaticValue derivation

Example 1: Set Default Value

Scenario: For new customers, the field “Customer Priority” should automatically be set to “C”.

App: Custom Fields and Logic
Business Context: Business Partner - Customer
Logic Type: Determination
Trigger: 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 Logic
Business Context: Business Partner - Customer
Logic Type: Validation
Trigger: 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 operators
Field1 = "Value"
Field2 <> "Value"
Field3 > 100
Field4 >= 50
// Logical operators
Condition1 AND Condition2
Condition1 OR Condition2
NOT Condition1
// Field operations
Field1 + Field2
Field1 * Factor
LENGTH(TextField) > 10
TODAY()

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 CustomerPriority

Generated CDS View

@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.query: true
@VDM.viewType: #CONSUMPTION
define 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.TransactionCurrency

Limitations and Constraints

Key User Extensibility has clear limitations:

Technical Constraints

ConstraintDetails
Number of fieldsMax. ~200 Custom Fields per Business Context
Field lengthText max. 1333 characters
Complex logicNo loops, no external calls
PerformancePerformance may suffer with many fields
DebuggingLimited 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 transactions

Upgrade 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 description

Process 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
- Monitoring

Documentation

Every extension should document:

AspectExample
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 ALV

Migration from Key User to Developer

When Key User Extensibility is no longer sufficient:

  1. Keep Custom Field: Data basis remains
  2. Replace Custom Logic: Create ABAP implementation
  3. Implement BAdI: Full ABAP functionality
  4. 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 months
2. YY1_PAYMENT_SCORE (Number) - Payment score 1-5
3. YY1_COMPLAINT_RATE (Number) - Complaint rate %
4. YY1_CUSTOMER_RATING (Code List) - Rating A/B/C/D

Step 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 < 2
THEN YY1_CUSTOMER_RATING = "A"
Rule 2:
IF YY1_REVENUE_12M > 50,000
AND YY1_PAYMENT_SCORE >= 3
AND YY1_COMPLAINT_RATE < 5
THEN YY1_CUSTOMER_RATING = "B"
Rule 3:
IF YY1_REVENUE_12M > 10,000
AND YY1_PAYMENT_SCORE >= 2
THEN 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_RATING

Limitations 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