Skip to Content

Extension Field Types: Adaption Mode / Page Layout / SAP SDK

Hi People,

In this blog post, I would like to clarify the question about which kind of custom fields we recommend to use.

In C4C, we support different kinds of extension fields which can be added to a standard business object screen.

  • Extension fields created in Silverlight (Adaption Mode)
  • Extension fields created in HTML5 via Page Layout
  • Extension fields created using the SAP Cloud Applications Studio (SAP SDK)

The good news is, the first two are the same type of fields created on different user interfaces. So we only have to differentiate between two types of extension fields:

  • Frontend generated extension fields via KUT or Page Layout
  • Extension fields created via Cloud Applications Studio

Both types of extension fields can be used in parallel, however there is best practice depending on the usecase.

Usecase 1: Cloud for Customer without any planned custom development

In this case, you do not have any SDK development. Therefore all extension fields should be created on the frontend.

Usecase 2: Cloud for Customer with (planned) custom development

If you already know that custom development via the SAP SDK is planned, you should think about creating all extension fields from the SAP SDK instead of mixing technology.


There are different aspects in a project that play a role in this decision.

  • Social aspect: If you have people creating fields on the frontend and developers enhancing the system, you never clearly know where to look first, when the system is not behaving correctly. If fields are behaving not as expected, you always need to find out what kind of field it is in order to find the responsible person to look at and correct the behavior. You can completely avoid this confusion by sticking to one technology.
  • Technical aspect: Frontend generated fields are not (easily) accessible with the SAP SDK. If you need business logic on frontend generated extension fields, that has to be programmed with the SAP SDK, the developer is very limited in accessing these fields. In early days, it was not possible to access these fields with SDK logic at all. Later we made this possible, but certain limitations apply.
    • The datatypes are limited, frontend fields cannot be defined as well as fields created with the SAP SDK.
    • They are not getting transported with the SDK deployment and must be created manually in all tenants. (Update: With Release 1511 the SDK deployment logic creates the fields automatically).
    • They can not be accessed from the SDK UI designer.
    • The SDK access to frontend extension fields was developed as “rescue” option, not as feature to use regularly.
    • Livecycle issues with frontend field access are a bit more likely.
  • Future aspect: In various projects it happened, that there was a clear differentiation between fields that will never need any logic and can be created on the frontend and some fields that must contain logic which were created via SDK. In most cases it happened that in a later stage of the project access to one or more frontend fields from the SDK was required.

Best Practice:

If you understood the details above, you can make a well informed decision about how you want to proceed in your project. The safest way is to stick to one technology, which is the reason why our best practice advice is to not mix up the extension field technologies and create all of them with the SAP SDK in case custom development is used or planned anyway.

I hope this blog post helps you to understand the motivation behind this best practice.

Best Regards,


You must be Logged on to comment or reply to a post.
  • Hi Stefan

    Very Useful info , I know many of us were struggling with this topic including me. I have following question  -

    What do you mean by Rescue option ?

    It would be good if you could provide a sample implementation for use of Frontend field via SDK.



    • Hi Swapnil,

      with "rescue" option, I mean the the object reference to frontend extension fields has been implemented not for daily use. It got implemented for customer implementations who made a wrong decision and were stuck in the project because of it.

      So if your idea is to create all fields on the frontend and write SDK logic with references to all of these fields, you may end up with an unreliable / unstable / unflexible solution.

      SDK access to frontend fields should remain an exception for situations were it is unavoidable.

      For the same reason, I'm not putting an implementation example in here. But I think it is documented in the SDK help.

      Best Regards,


  • Hello Stefan,

    Smal but important correction:

    With 1511 the defintion of frontend generated fields which are referenced in a SAP SDK are transported and generated in the very first step of the deployment.



      • Hi Stefan

        Does this mean from 1511  onwards the " rescue option " will no longer be needed and  field created in front end will be readily available to use in SDK  ?



        • No, it only means that the SDK creates key user fields automatically in case they are referenced in the solution and not present in the target tenant. So the deployment will not fail due to missing frontend fields.

          The fields are still two different persitancies with all the mentioned drawbacks. I've update the article.

  • Hi Stefan,

    thank you for clarification...I want to add one more thing that should to be taken into account as well: PDI created extension fields are (at least to my knowledge) not visible in iPad offline mode -> if the requirement is to use extension fields in offline mode you are forced to create them via KUT.


    • Hi Herbert,

      if you add PDI fields as extension fields to the header of a standard Business Object, they will be visible in offline mode. Without business logic (absl) of course.

      Best Regards,


  • Hi Stefan,

    I do also have a doubt here.How to include extensions fields added at SDK in web services. I can see only fields added at KUT level have an option to include in services.

    In this case which option will you suggest ?



    • Hello Naga, I am not sure of this statement but I believe you can first create your extension fields, then create a Process Extension Scenario on the corresponding BO. In the Process Extension Scenario list, you should see the web services available to be extended with your fields. Thank you for oyur attention. Best regards. Jacques-Antoine Ollier

      • Hello Naga, Jacques-Antoine,

        In the Process Extension Scenario you will see - amongst others - the WebServices which belong to the BO nodes you have selected.

        If you tick such an WebService all Extension Fields in the BO Extension with the annotation for this resp. Process Extension Scenario will become part of thei WebService.



          • Hello Naga,

            The annotation is "Scenario" like

            [Scenario ( SalesExtension, MaterialExtension )] element ExtendedId : ID;

            You just add the name of the Process Extension Scenario as parameter of the annotation.

            You can add more than one Process Extension Scenarios.

            For more details have a look into the docu:

            Scripting Languages -> Scripting Language for the Studio -> Business Object Extension Definition -> Scenario



  • Hello Stefan and all,

    I am using the demo system to validate an exercise in the learning hub flipbook (col. 92). It is to create a new extension field editing Master Layout, however when I try to add this new field the error message shown in the screenshot below pops us preventing me from proceeding. I am assuming that in the 1602 it is no longer possible to add new fields via KUT only via development using Cloud Application Studio. Is that assumption correct?

    In case it is still possible any clues on what is going on?

    Thanks a lot,


    José Anastácio


    • Hi Jose

      The error is because you are using the Business role or User  which has a Partner Development work center (which should be used for development users only) assigned. Remove this from your user and you should be able to add extension fields in master layout.

      Remember : For any configuration activities including layout changes and extension fields - do not use user who has authorization for development.



  • Hi , for  extension fields created in Silverlight (Adaption Mode), it is possible it be enable in "enhance enterprace Serarch in SDK " .

    I need to include this custom field in a SearchQuery


    Thanks and Regards,


  • Hi Stefan,

    Nice blog, one quick question on transporting extension fields created using Adapt option on HTML (KUT) from test to production? how do we move these fields from test to production? Does Export Layout carry these extensions from test to production or Project Merge or solution profile copy these to production?

    Thanks in Advance.



    • Hi Kumar,

      KUT changes are transported with the Master Layout download and upload.

      Since release 1508 also PDI takes care of fields that are referenced from PDI. They will be created automaticall when the solution is being uploaded.

      Best Regards,

  • Hi Stefan,

    I'm working with embedded components, I add this components to standard BO Service Request.

    Is posible to be able the page layout relevant configuration(Mandatory option) for the fields in the component?


    • Hi Sebastian,

      yes it is. You need to make sure that you set "Anchor"s in you embedded component. These anchors must be set on all Levels up to the root level of the EC.

      Best Regards,

  • Hi Stefan,

    I have created some extensions fields by using SDK. Now we want to display these fields in report. How can we do this?




  • Hi,

    We have extension fields created in the Cloud Application Studio and now we want to further extend services in those fields i.e. adding the service for ERPREPLICATIONOUT to include this field as part of the communication with an external system.

    However, I see that 'further usage' is only enabled with fields created using the front-end and not via the Application Studio. Is there a way we can enable services in these fields ?