After connecting a database, if the pages you see are packed with fields and complex relations, and it's unclear where business users should even start, don't rush to treat them as your final business system.
Data list pages are, first and foremost, general-purpose pages for managing data. They quickly turn database records into entry points you can query, view, and maintain — but they won't reconstruct a finance or operations role's complete workflow from database structure alone.
TIP
In one sentence: data list pages manage data; business models help Agents and dev tools understand the business; Skills organize reusable task paths; function services execute complex business rules reliably; and role-specific business pages still need to be designed around roles and processes.
Why generated pages look complex
Databases are organized around data storage and system implementation, so they mix business fields, relation fields, status fields, technical fields, and legacy-compatibility fields. Data list pages present all of this from a management perspective — which is why the initial page looks more like a "data workbench" than the task-driven interface a finance person works through every day.
| Page type | The question it answers | Typical form |
|---|---|---|
| Data list page | What data exists, and how do I find, check, and maintain it? | Fuller field set; emphasizes filters, table, detail view, create, and edit |
| Business page | What task does this role need to complete right now? | Shows only the information, steps, results, and exception handling that role needs |
So "looking complex" doesn't necessarily mean the business analysis was wrong — it more likely means a management page got mistaken for the final business page. Start by confirming the use case: is it about checking and maintaining data, or about walking a specific role through a concrete process?
What data list pages are actually for
Data list pages fit high-frequency, standard data management needs, such as:
- Quickly seeing what customers, contracts, orders, expense reports, or other business records are in the database
- Filtering, checking, backfilling, or updating data by condition
- Verifying that field meanings and data relations in the business model are correct
- Providing implementation, operations, and management staff with a general-purpose data management entry point
- Establishing a usable, verifiable base entry point before full business pages are developed
Their value is cutting the repetitive work of building lists, filters, and basic forms, so teams start managing and validating data sooner. They're not meant to replace role workbenches, approval flows, management dashboards, complex settlement, or industry-specific interactions.
The main output of database analysis is the business model
Database analysis isn't "read the table structures, then auto-generate a complete business system." The more important output is the business model: it helps the system understand which business objects exist, how they relate, what fields mean, and which capabilities can be queried and invoked.
| Output or capability | What it does |
|---|---|
| Business model | Provides business objects, relations, and semantic context for Agents, Skills, and dev tools |
| Data list page | Fast viewing, checking, and maintaining of data — also an entry point for validating the model |
| Instant API / SDK | Lets developers query and operate on data through a unified model and keep building business code |
| Skill | Turns task steps, usage know-how, and organizational experience into reusable execution paths for Agents |
| Function services | Carry complex rules — settlement, filtering, state transitions — that need determinism and engineering guarantees |
| Custom business pages | Deliver the final experience around specific roles, tasks, and processes |
INFO
Pages still matter — they're just not the only output. Data list pages are the standard entry point for managing data; the business model, APIs, Skills, and function services are what make the same business capabilities reusable by Agents, dev tools, and other pages.
How business users, implementation staff, and developers each use it
| Role | Main entry point | Best suited for |
|---|---|---|
| Business users | Agents, Skills, business pages | Setting goals, querying and analyzing, running standard tasks, confirming key results |
| Implementation and operations staff | Data list pages, configuration tools | Checking data, maintaining master data, validating models, handling general management tasks |
| Technical staff | The AI coding tools and dev environments they already prefer | Using the business model as context to build complex pages and business logic through the Rabetbase CLI, Instant APIs, SDKs, and function services |
Technical staff don't have to abandon their existing habits. Lovrabet provides the business model, data interfaces, and execution capabilities; developers still do their custom work in familiar AI coding tools like Codex.
Why a complete business system can't be built from the database alone
A database tells AI how data is stored, but usually can't fully tell it how the business should run. This information rarely lives in table relations:
- What each role sees and may do
- Where a task starts, and which reviews and exception branches it passes through
- Which business definitions reports, settlement, and statistics follow
- Which statuses can be changed, and which actions need permissions, previews, or human confirmation
- What a page should highlight, and which technical fields should stay hidden from business users
These semantics need confirmation from business people, and implementation and technical teams need to distill the stable rules into models, Skills, functions, and pages. AI can speed up analysis and development, but it can't decide a company's complete process from database relations alone, without business semantics as input.
Example: how many expense reports does the company have
This question looks like simple counting, but it can carry precise financial definitions: should rejected, voided, or test records be counted? Do you count submitted claims, or completed reimbursements?
| Relying only on… | What you may get | |-|-|-| | Querying the database directly | Every record may get counted — you get a number, but not one that matches the financial definition | | Describing rules only in prompts | Fine for ad-hoc analysis, but rules get missed easily and execution isn't consistent every time | | Locking the definition into a function service | Explicitly excludes statuses and picks the time and organization scope, then gets called by a Skill — results are repeatable, testable, and auditable |
That's the value of function services: the Skill tells the Agent what task to complete and the path to take; the function service guarantees complex business rules execute exactly. Combined, you keep the Agent's flexibility and the engineering system's determinism.
How to decide what to do next
| Your goal | Suggested entry point | |-|-|-| | See the data clearly, validate the model, maintain master data | Data list page | | Let business users query, analyze, or run a standard task | Agent + Skill | | Lock in complex filtering, settlement, approval, or state rules | Function services / SQL / BFF | | Give a role a dedicated workbench or a complete business process | Custom business pages + business logic development |
FAQ
The page looks complex — does that mean the earlier business analysis was wrong?
Not necessarily. First tell apart a genuinely wrong model from an initial page that simply exposes too many management fields. Use the data list page to check objects, fields, and relations, then trim information for the specific role, add business semantics, or move to a custom page.
A data list page was generated — is the complete business system done?
No. It only completes the general-purpose data management entry point. A complete business system may also include role workbenches, processes, permissions, metric definitions, system integration, and industry-specific logic.
Is Lovrabet only good for generating list pages?
No. List pages are just one of its page capabilities. Lovrabet's more important role is turning databases and legacy systems into business models and invocable capabilities, which Agents, Skills, function services, APIs, and custom pages all draw on.
Can an Agent handle all the business logic by itself?
Leaving every rule to the Agent's judgment in the moment isn't recommended. Agents handle exploratory analysis and long-tail tasks flexibly; critical rules — financial definitions, settlement, permissions, transactions, state transitions — should get their determinism from functions, SQL, BFFs, or existing services.
Keep going
If your goal right now is to generate and validate a data management entry point, see <cite doc-id="JMOcdHAwSoklYUxS3K0ceGOfnDd" file-type="docx" title="Creating and modifying data list pages | Platform operations" type="doc"></cite>.
To adjust fields, filters, forms, and tables, see <cite doc-id="SpbSdmFlFo5TWTxw5pCcbjKYn5b" file-type="docx" title="Data list page editor" type="doc"></cite>.
To keep developing complex interactions and custom modules in an AI coding tool, see <cite doc-id="DlzOdMHmxoRGYQxbtekc6t7tnbf" file-type="docx" title="Creating and extending data list pages | AI Coding" type="doc"></cite>.
To understand Lovrabet's overall positioning and capability boundaries, see <cite doc-id="XlrdwUYgwi3leEkKXHlcOLkrneb" file-type="wiki" title="Lovrabet positioning, enterprise problems, and core value summary" type="doc"></cite>.