Liferay Objects: Technical Reference

Liferay Objects

Interview & Technical Reference Notes

Basic Concepts

Q1What are Liferay Objects?

Liferay Objects are a low-code/no-code feature for creating custom business entities and CRUD applications without having to deploy traditional application code. An Object Definition describes the structure and behavior of the business entity. Typical configuration includes:

Fields
Relationships
Layouts
Views
Validations
Actions
Permissions
REST APIs

For example, an organization could create objects such as:

Employee
Student
Course
Purchase Request
Asset Request
Customer Feedback

Q2What are the main Object scopes?

An object’s scope determines where its entries belong and how they are separated within Liferay.

Company Scope: Entries belong to the Liferay virtual instance.

Site Scope: Entries are associated with individual Liferay Sites.

Site scope is particularly useful when the same Object Definition is used by multiple sites while each site maintains its own entries.

Q3What are the core components of an Object?

Fields: Define the data stored by an Object.

Relationships: Connect one Object Definition with another.

Layouts: Define how fields and relationships appear when users add or edit entries.

Views: Configure how object entries are presented in supported user interfaces.

Actions: Execute additional behavior when configured triggers occur.

Validations: Enforce business rules before data is accepted.

Permissions: Determine which users or roles can perform operations on objects and their entries.

Q4What is the difference between System Objects and Custom Objects?

System Objects: Object definitions associated with functionality provided and managed by Liferay. Their lifecycle is controlled by the platform.

Custom Objects: Business entities created by administrators or developers for application-specific requirements.

A custom object can represent entities such as:

Employee, Student, Vendor, PurchaseRequest

Intermediate Concepts

Q5What relationship types are available?

Liferay Objects can model relationships between business entities. Two important relationship patterns are:

One-to-Many
Many-to-Many

For example:

Department −→ {Employee1 , Employee2 , . . .}

represents a one-to-many relationship. A Student–Course relationship can naturally be modeled as many-to-many:

Student ←→ Course

because one student may take several courses and one course may contain several students.

Q6How do validations work?

Validations ensure that object entries satisfy defined business rules.

Required values
Valid field formats
Appropriate numeric values
Length constraints where supported

More sophisticated validation rules can enforce relationships between multiple fields. For example, suppose an object contains:

Po = OriginalPrice

and

Pd = DiscountPrice.

The required business constraint may be written as:

Pd ≤ Po .

Conceptually, a validation rule checks:

Code

discountPrice <= originalPrice

If the condition fails, the entry should be rejected with an appropriate validation error.

Q7What are Object Actions?

Object Actions allow additional business behavior to be executed when specific events occur. Typical lifecycle events include operations around:

Add
Update
Delete

Depending on the Liferay version and configuration, an action can be used to invoke mechanisms such as:

Webhooks
Notifications
Supported scripting or custom execution mechanisms

A typical flow is:

ObjectEvent → Action → External/InternalOperation

For example:

EmployeeCreated → Webhook → HRIntegration

Q8Can Liferay Workflow be used with Objects?

Yes. Object entries can participate in Liferay’s workflow infrastructure when workflow is configured for the relevant object.

Draft → Submitted → ManagerReview → Approved/Rejected

This makes Objects useful for approval-driven applications without requiring a complete custom application to be developed from scratch.

Q9What is a Picklist?

A Picklist provides a predefined set of values that can be reused by object fields. For example:

Code

Employment Status

Active
Inactive
On Leave
Terminated

A field can reference the Picklist instead of allowing arbitrary text input. Conceptually:

ObjectField → Picklist → {Option1 , Option2 , . . .}

This improves consistency and prevents invalid or misspelled values.

Q10Do Objects provide REST APIs?

Yes. One of the major advantages of Liferay Objects is that REST APIs are generated for published custom objects. A common endpoint pattern is:

Code

/o/c/<pluralObjectName>

For an Employee object, an endpoint might resemble:

Code

/o/c/employees

The API can support CRUD-oriented operations together with features such as filtering, sorting, and pagination where applicable. For example:

HTTP

GET /o/c/employees
POST /o/c/employees
GET /o/c/employees/{id}
PUT /o/c/employees/{id}
DELETE /o/c/employees/{id}

Access remains subject to Liferay authentication and authorization.

Advanced Concepts

Q11How does permissioning work?

Liferay Objects integrate with Liferay’s role-based permission framework. Permissions can control operations such as:

Add
View
Update
Delete

Entry-level permissions can further restrict access to individual object entries. The overall authorization model can therefore be viewed as:

User → Role → ResourcePermission → Object/ObjectEntry

This is important when building applications where different users must have different levels of access to the same business entity.

Q12Can Objects be accessed from OSGi code?

Yes. Custom Java/OSGi modules can interact with Liferay Objects through Liferay’s Object APIs and services. A commonly used service is:

Code

ObjectEntryLocalService

Conceptually, adding an entry involves supplying the object definition, user/context information, and a map containing the object’s values. For example:

Code

Map<String, Serializable> values = new HashMap<>();

values.put("firstName", "John");
values.put("department", "Engineering");

// Use ObjectEntryLocalService with the parameters
// required by the target Liferay version.

Developers should use the exact ObjectEntryLocalService method signature available in their installed Liferay version, because service signatures can vary between releases. Model listeners and related extension mechanisms can also be used when custom Java behavior needs to respond to persistence lifecycle events.

Q13Can Object entries be imported and exported?

Liferay provides import/export capabilities for supported Object entry use cases. This is particularly useful for:

Initial data migration
Bulk entry creation
Data exchange
Administrative maintenance
Testing

CSV-based operations are especially useful for business users managing large numbers of entries.

Q14What is an Object Layout?

An Object Layout controls the organization and presentation of fields and relationships on an Object entry form. For example, an Employee object could organize fields as:

Code

Personal Information
   First Name
   Last Name
   Email

Code

   Employee ID
   Department
   Joining Date

Compensation
   Salary
   Bonus

Layouts improve usability by grouping related information and reducing the complexity of large forms. Sensitive-field visibility should ultimately be enforced through the appropriate Liferay permissions and application design rather than relying only on visual layout differences.

Q15What are the limitations of Liferay Objects?

Objects are highly effective for low-code business applications, but they are not intended to replace every custom persistence requirement. Potential considerations include:

Highly complex querying may require custom development.
Advanced cross-entity reporting may require external analytics or custom APIs.
Direct SQL access should not be treated as the normal Object programming model.
Very large datasets require appropriate performance testing, indexing strategy, API design, and infrastructure sizing.
Complex transactional business logic may be better implemented in Java services.
Specialized persistence requirements may be better suited to Service Builder or another dedicated backend.

There is no universal record-count threshold at which Objects suddenly become unsuitable. Performance depends on query patterns, indexing, relationships, infrastructure, Liferay version, and application design.

Objects vs. Service Builder

Q16When should Objects be used instead of Service Builder?

Feature	Liferay Objects		Service Builder
Development	Low-code / configuration	driven	Java / OSGi development
Style
CRUD	Generated automatically		Generated from service.xml with developer customization
REST APIs	Generated for published objects		Typically implemented/exposed through Liferay’s service/API mechanisms
Business Logic	Good for relatively straightforward business processes		Suitable for sophisticated custom business logic
Custom Queries	More constrained		Supports custom finders and persistence customization
Deployment	Many changes can be through Liferay	configured	Requires building and deploying modules
Typical Use	Requests, directories, forms, workflows, administrative applications		Complex enterprise applications and custom domain services

A useful architectural rule is:

Configuration − DrivenCRUD ⇒ LiferayObjects

whereas:

ComplexDomainLogic + SpecializedPersistence ⇒ ServiceBuilder

Objects and Service Builder can also coexist in the same solution.

Real-World Example: Student–Course Application

Q17How can a Student–Course application be created using Objects?

Consider a university portal where students can register for courses.

Step 1: Create the Student Object

Create an Object Definition:

Code

Student

Example fields:

Field Type
studentId Text
firstName Text
lastName Text
email Text
dateOfBirth Date
status Picklist

status Picklist

Step 2: Create the Course Object

Create another Object Definition:

Code

Course

Example fields:

Field	Type
courseCode	Text
courseName	Text
credits	Integer
department	Text/Picklist

Step 3: Create the Relationship

A student may register for several courses, and a course may contain many students. Therefore:

StudentM : N ←→Course

A many-to-many Object relationship can represent this association.

Step 4: Configure Layouts

Create logical sections for Student entries:

Code

Student Information

Personal Details
Academic Details
Course Registrations

This provides administrators with a cleaner entry-management experience.

Step 5: Manage Related Entries

Configure the user interface so that administrators or authorized users can associate Course entries with Student entries. Conceptually:

StudentEntry → Courses → AddRelatedEntry

Step 6: Add Automation

When a new student is created, an Object Action could trigger a notification or invoke an external service. For example:

StudentCreated → ObjectAction → WelcomeN otif ication

A webhook could instead invoke an external service:

LiferayObject → Webhook → ExternalStudentService

Step 7: Access Through REST

Once the objects are published, their generated APIs can be consumed by external applications. Conceptually:

HTTP

GET /o/c/students
POST /o/c/students

GET /o/c/courses
POST /o/c/courses

This makes it possible to connect:

React/Lif erayUI → Lif erayObjectRESTAPI → ObjectEntries

Architecture Summary

A typical Object-based application can be visualized as:

Lif erayUI/React/ExternalApplication
↓
RESTAPI − − − /o/c/ < object >
↓
ObjectDefinition
↓
ObjectEntries
↓
Lif erayP ersistenceLayer

The Object Definition additionally controls:


    Fields 
   
    
     
     
 Relationships     
     
     
     
  Validations   
   
Actions
  
   
  Layouts    
     
     
     
     
 Permissions     
     
    
   
Workflow

Liferay Objects

Basic Concepts

Intermediate Concepts

Advanced Concepts

Objects vs. Service Builder

Real-World Example: Student–Course Application

Architecture Summary

Interview Takeaway