Liferay Objects Explained: Building Custom Data Models Without Code

The Problem It Solves

Most Liferay sites eventually need to store business data that doesn't fit neatly into pages or content types — customer applications, employee records, product specs, verification records. Historically that meant one of three compromises: hire developers to build custom database tables, bolt on an external database and manage the integration, or force the data into structures Liferay wasn't designed to hold.

Liferay Objects removes that trade-off. It's a low-code feature inside Liferay DXP that lets you define custom, database-backed data models through a visual interface — and Liferay automatically generates REST and GraphQL APIs, forms, permissions, and workflow hooks for whatever you build.

What Are Liferay Objects?

An Object is effectively a custom database table you design in Liferay's admin UI instead of via SQL migrations or Service Builder code. Per the official documentation, Objects provide "a convenient UI for creating custom applications that meet your business needs without writing code," including fields, relationships, actions, views, and validations.

Each Object you publish is:

• No-code — created and edited through a point-and-click interface
• Database-backed — data persists like any other Liferay entity
• API-first — every Object gets REST and GraphQL endpoints automatically
• Permission-controlled — role-based access applies across the UI, API, and workflows
• Relationship-aware — Objects can reference each other without hand-written joins

The practical difference from a traditional build: defining a data model, its UI, and its API used to be a multi-week development task. With Objects it's a same-day configuration exercise.

Creating Your First Object

The workflow is consistent regardless of what you're modeling:

1. Open Objects from the Control Panel and create a new Object definition, giving it a name, plural label, and description.
2. Add fields — text, number, date, picklist, toggle, decimal, or a relationship to another Object.
3. Define relationships (one-to-many or many-to-many) if the Object needs to connect to others, using the Model Builder, which visualizes every Object definition and its connections as cards.
4. Set permissions by role — who can view, create, edit, or delete entries.
5. Publish. REST endpoints, GraphQL schema entries, an admin UI, and auto-generated forms all go live immediately.

For a full walkthrough with real field values, see Creating Your First Liferay Object: A Step-by-Step Tutorial.

For example, a Contact Object publishes REST endpoints following the pattern documented in Liferay's Custom Object APIs reference:

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

Those endpoints — and the equivalent queries under c in Liferay's GraphQL schema — are ready to consume from React, a mobile app, or any third-party system without additional backend work. For a deeper look at filtering, sorting, authentication, and relationships, see REST APIs Auto-Generated by Liferay Objects.

A Practical Example: Application + Verification

A common pattern — used by fintech and compliance teams — pairs two related Objects:

DistributorApplication — business name, tax ID, applied date, and a status field that moves through Pending → Submitted → Approved/Rejected.

KYCVerification — linked back to the application via a relationship field, plus credit score, risk level, and verification status.

Once both are published, a workflow step can route any application flagged "High Risk" to a manager for approval, while every field on both Objects stays queryable through the auto-generated APIs — no custom database schema or endpoint code required.

Use External Reference Codes for readable APIs

Rather than relying on auto-generated numeric IDs, set a meaningful External Reference Code (ERC) on each entry:

GET /o/c/distributorapplications/12345                              # opaque
GET /o/c/distributorapplications/by-external-reference-code/APP_ACME_2026   # readable

ERCs are a first-class feature — see Liferay's guide to using external reference codes — and they make integrations with external systems (or content migrations) far easier to trace and debug.

Objects vs. a Traditional Database

Objects aren't a replacement for every data problem. They're the right tool when:

• The data belongs to a business process inside Liferay, not technical infrastructure
• You want automatic APIs and permissions rather than hand-building both
• Business or ops users — not just developers — need to evolve the model over time
• You need to ship in hours, not sprint cycles

Reach for a traditional database (or Service Builder, for a fully coded Liferay entity) instead when you need extreme query performance, specialized capabilities like geospatial indexing, or a single source of truth that lives outside Liferay entirely. For the bulk of internal business applications, though, Objects are the faster path to production.

Best Practices

Design relationships deliberately. One-to-many (a Company with many Contacts) is the common case; avoid deep chains of nested relationships that make queries and permissions harder to reason about.

Validate at the point of entry. Use Object actions to enforce rules — valid email formats, no duplicate records, required relationships — rather than cleaning up bad data after the fact.

Start minimal, then extend. Publish an Object with just the essential fields, get it in front of users, then add fields, relationships, and automation in later iterations. Objects are built to be changed incrementally.

Apply least-privilege permissions. Default to no access, then grant view/edit/delete per role deliberately — the same permission model applies across the admin UI, REST/GraphQL APIs, and workflows, so it only needs to be set once.

Final Thoughts

Liferay Objects turn Liferay from a content and portal platform into something closer to a low-code business application platform: you model data visually, and the API layer, forms, and access control come along for free. That matters most for the long tail of internal tools and process-tracking apps that are too small to justify a full development project but too important to run in a spreadsheet.

And because every Object is exposed through standard REST and GraphQL, you're never locked into Liferay's own UI — the data is just as usable from a custom React front end as it is from the built-in admin screens.

Start with the official Liferay Objects documentation, or the broader Low-Code overview for how Objects fit alongside Workflows and custom interfaces.

Related Reading

• Creating Your First Liferay Object: A Step-by-Step Tutorial — a hands-on walkthrough of everything in this article, field by field.
• REST APIs Auto-Generated by Liferay Objects — a practical reference for the CRUD endpoints, filtering, authentication, and batch operations Objects generate for you.
• Liferay Low-Code: Build Business Apps Without the Hand-Coding — how Objects fit alongside Workflows and interface design as the three building blocks of Liferay low-code.
• Liferay Commerce Explained: B2B and B2C — a platform-level feature that leans heavily on Objects under the hood.
• Liferay Hosting Explained: SaaS vs. PaaS vs. Self-Hosted — relevant if you're deciding where to run an Objects-based application.
• Liferay Service.xml Generator — for when you need a fully coded Service Builder entity instead of a no-code Object.
• Browse all Liferay tools — generators and reference utilities for Liferay developers.