Adding Custom Fields to Business Entities

In this lesson, you will learn how to design, create, and configure custom fields (also known as extension fields) for business entities in SAP Sales Cloud and SAP Service Cloud Version 2. You will also learn about data types, formats, and lengths; field attributes and query properties; and how to perform where-used analysis.

Custom fields are additional data fields that administrators can create in SAP Sales Cloud and SAP Service Cloud Version 2. These fields allow organizations to capture business-specific information that is not part of the standard data model.

For instance, NovaLink Industrial Solutions, a company specializing in smart industrial equipment for manufacturing plants, may need to track warranty classification codes on service tickets to ensure accurate support and compliance with customer agreements. Additionally, NovaLink’s sales team might need to record partner certification levels on sales opportunities to better manage strategic collaborations and market positioning.

In such cases, standard fields in SAP Sales Cloud and SAP Service Cloud Version 2 may not provide the flexibility to address these unique business needs. This is where custom fields become essential, enabling NovaLink to capture and utilize specific data tailored to its business operations. Through In-App Extensibility, NovaLink can create custom fields, optimizing its sales and service processes to deliver superior customer experiences.

In SAP Sales Cloud and SAP Service Cloud Version 2, custom fields are retained in the extensibility layer and become part of the target business entity’s runtime data model. They participate in standard CRUD (Create, Read, Update, and Delete) flows and can be exposed in the UI and APIs. They are exposed in the UI, analytics, Machine Learning, and integration APIs, providing a consistent approach to extensibility.

The foundation of any custom field is its definition. It determines how data is stored, which values are allowed, and which constraints apply. A poor choice in data type or length can affect data quality, reporting, and performance.

Understanding Data Types: The data type defines how the field can be used in logic, reporting, and integrations. It also determines how the system interprets and validates the stored values. Choosing the right type ensures correct processing and avoids limitations. For example, the Number type allows mathematical comparisons and calculations.

Defining Formats and Constraints: Formats and constraints refine the data type by enforcing valid input, such as Email, UUID (Universally Unique Identifier), and precision for numbers, helping maintain consistency. They check against incorrect or inconsistent data entry.

Specifying Field Length: Field length should align with the business purpose. It affects storage, performance, and usability, and should account for varying text lengths in multilingual scenarios. Fields that are too large increase database load, while fields that are too small can result in truncated or unusable data.

The following table provides a brief overview of the primary data types available for custom fields.

Once a custom field is created, its attributes and query properties determine how it behaves and integrates with the rest of the system. You need to configure these attributes and query properties to align the field's function with the user's workflow and the system's performance requirements.

Configuring Field Attributes: Field attributes define how a field behaves during data creation and maintenance. Key attributes specify whether a field is creatable, updatable, or required. These settings determine whether a value can be set during record creation, can be changed afterward, or must be provided at record creation.

For example, a field that is not updatable can only be set once during creation and remains unchanged afterward. Marking a field as required ensures that it must always contain a value, which is essential for maintaining data completeness and consistency. These rules are enforced system-wide, including in API interactions.

Setting Field Query Properties: Query properties define how a field can be used for search and data retrieval. The main properties are searchable, filterable, and sortable. When you mark a field as Searchable, its content is included in the full-text search index. This allows users to find records by entering values from that custom field in the global search bar.

Marking a field as Filterable makes it available as a criterion in the filter panel of list views and in the $filter clause of REST API calls. This is essential for any field that users need to use to narrow down lists of records, such as a custom Region or Product Category field.

Similarly, making a field Sortable allows users to sort list views using that field's column. It also allows the field to be used in the $orderBy clause of a REST API query.

It is important to perform a Where-Used analysis before modifying or deleting a custom field to check its usage across the system. Custom fields can be referenced in multiple parts of the system, and changes without impact analysis can lead to errors or broken processes.

You can use the View Usage function to see where a field is used. This includes UI components such as Page Layouts and UI views, as well as business logic like validations, determinations, and autoflows. It is not allowed to delete a custom field if it is still used in business processes; all usages must be removed first.

As shown in the image below, you can access the View Usage button on the Custom Fields tab of a business entity; it is in the Actions column on the far-right side of each custom field entry.

In the following video, you will learn how to introduce a custom field named Engagement Score Lead to the Lead entity, set its data type and attributes, and configure its query properties.

This field allows you to capture unique engagement metrics specific to your business, such as lead activity, responsiveness, or interaction quality. By incorporating this custom engagement score into your lead scoring model, the machine learning engine can provide you with more accurate predictions about the leads that are most likely to convert.

• Custom fields allow you to extend standard business entities with additional, business-specific data.
• Custom fields are fully integrated into the data model and behave like standard fields. They are available across UI and APIs.
• Choosing the correct data type is critical, as it defines how the field can be used.
• Field Length must be chosen carefully, considering business needs and technical impact, such as performance and storage.
• Field Attributes control whether a field is creatable, updatable, or required.
• Query Properties define whether a field is searchable, filterable, or sortable.
• Where-Used Analysis should be performed before changes or deletions. It shows dependencies in UI and logic, but not all usages (For example, reports or integrations).