Custom Fields and Logic in S/4HANA

Custom Fields and Logic is a Fiori-based key-user tool that lets a business user or functional consultant add a new field to a standard SAP object and, optionally, attach a small rule that sets a default value or runs a validation. Under the surface it generates a database append or extension include, a CDS view extension, UI metadata, and, if logic is attached, a BAdI implementation using a restricted, non-Turing-complete expression language rather than full ABAP. The structural fact that explains most confusion: the object is not a shortcut around developer extensibility, it is a different ownership model. Everything the tool generates is tracked in an extensibility registry that SAP migrates automatically across upgrades, whereas a manually built append structure and a hand-written user exit are the customer's own responsibility to carry forward. The tool trades flexibility for that guarantee.

Use it when the requirement is a genuinely simple field: a free-text note, a flag, a date, a classification value, with at most a straightforward default-value or validation rule expressed as field comparisons and simple conditions. It is the right tool when the target object exposes a business context that covers the UI, API, or report where the field needs to appear. It is the wrong tool the moment the logic needs a loop, a function module call, a database read against a table outside the object's own structure, or coordination across multiple documents. It is also the wrong tool when the field needs to appear on a classic dynpro screen with no released business context, or when governance requires the change to go through a formal developer transport process rather than the extensibility registry. Reaching for it out of habit for anything beyond a flag or a simple derived value produces a rule that fails to activate, at which point the requirement ends up back in ABAP anyway, just later than it should have.

Below the tool sit the generated technical artifacts: an append structure or extension include on the database table, a CDS view extend, and a generated BAdI implementation if logic was attached. Above it sit the consumption layers: Fiori UIs, classic reports, OData and API exposure, and extraction to analytics, all of which only see the field if the relevant business context explicitly propagates it there. It supersedes the old pattern of a manual dictionary append plus a screen exit plus a customer-written include for simple field additions. It does not supersede BAdI-based developer extensibility for complex logic; the two sit side by side, with the key-user tool designed to hand off to a BAdI implementation when the simplified rule language cannot express what is needed.

A sales team needs a free-text 'delivery priority note' on the sales order header, defaulted from the customer's priority classification when the order is created. In the tool, the business context for sales orders is selected, a new field of type character string is defined, and it is added to the relevant sales order UI. A simple logic rule is attached: if the customer's classification field equals a given value, set the new field to a fixed default text; otherwise leave it blank. The rule is expressed through the tool's condition builder, not written as ABAP. On activation the tool generates the extension include on the sales order item or header table, extends the sales order CDS view, and generates a BAdI implementation that runs the condition at order creation. The field is then separately exposed on the CDS view used for sales reporting, since UI exposure and analytics exposure are configured independently; skipping that second step is the most common reason the field works in the order screen but never shows up in a report.

This tool is a central pillar of the clean core approach. In cloud editions it is often the only supported way to add a field to a standard object; on-premise systems still permit classic dictionary appends and developer-built enhancements, but the direction of travel is toward using the key-user tool wherever the requirement fits its capabilities, precisely because it is what SAP migrates automatically. Classic dictionary appends and free-standing user exits for simple field additions are increasingly discouraged, not because they stop working, but because they shift upgrade and migration effort back onto the customer that the key-user path avoids.

A functional consultant or trained key user typically creates and maintains fields and simple logic directly in the app; no developer involvement is required for that layer. A developer gets pulled in only when the logic exceeds what the simplified rule language can express, at which point the work moves to a BAdI implementation in developer extensibility. An architect should own the decision of which layer a given requirement belongs in, as part of the broader clean-core governance for the landscape.

Read key-user extensibility versus developer extensibility for the fuller decision framework this page only touches on in its guidance section. Read clean-core-explained-for-abap-developers to understand why the extensibility registry model matters for upgrades. Read badis-versus-user-exits-versus-enhancement-points for what happens once the simplified logic language runs out of capability. Read custom-code-migration-for-s-4hana for how legacy dictionary appends and exits compare on migration effort against key-user-generated fields.