A contract register starts with a document card, a counterparty and a few attachments. Six months later it holds contract revisions, access rights by department and an integration with the accounting system. Then the business asks to split amounts across budget lines and to open part of the documents to counterparties. At this stage the architecture is judged by how many layers of the system each change touches and how the team carries it over to data that users already work with.
UnityBase is an enterprise low-code platform with its own server-side JavaScript environment. At its core is a domain model that the platform uses to work with data and to generate APIs and administrative interfaces. Developers describe the standard structure declaratively and implement the rules of a specific product in code. This approach suits registers, document management systems, corporate portals and industry applications with linked data and complex access rights. UnityBase architecture
1. One model for several application layers
In UnityBase, entities, attributes and relations are described in .meta metadata files. This description is used by the ORM, the database schema tools, the API and the administrative interface. For example, a contract has an amount, a status and a reference to a counterparty. In UBQL queries the developer works with the contract entity and its attributes, and the platform builds the database query. UnityBase documentation · Domain model and UBQL
Imagine a new requirement. One contract can now be funded from several budget lines. The team adds a Budget allocation entity with relations to the contract and the budget line and a field for the amount. Platform tools help prepare the schema and the standard operations on the new entity. In application code the team decides who may change an allocation, how to check the amounts and what to do if a budget line was closed after the contract was approved.
The developer’s advantage: fewer separate descriptions of the same structure. A new relation appears in the model that the platform tools already rely on. The team spends its time on product behaviour and on checking how the change will affect the workflow.
2. Server-side JavaScript for the rules that define the product
UnityBase has an HTTP(S) server with the built-in SpiderMonkey JavaScript engine. A developer can add server methods to entities and connect external services through APIs. The UnityBase tutorial project includes examples of a custom server method, an exchange with an external API and a separate client interface. Server architecture overview · UnityBase tutorial project
In the contract register, the standard administrative interface can serve the counterparty and budget line directories. For the finance officer the team can build a separate screen showing the contract, the remaining budget and the allocation of amounts. A server method checks the allocation and saves it. The integration with the accounting system has its own rules for retries and exchange errors.
The developer’s advantage: ready-made mechanisms cover standard operations, and the team writes its own code where the system’s behaviour depends on it. This is what low-code looks like in enterprise product development.
3. Access rights at the level of operations and records
In an enterprise register, a lawyer sees the contracts of their own department, a line manager those of several departments, and a counterparty the documents shared with it. Each role also has its own set of permitted actions. For example, the right to read a contract and the right to change its status are checked separately.
UnityBase provides access control for entity methods and Row-Level Security, or RLS, which limits record visibility on the server. RLS adds conditions on the server whenever the application works with the entity. This lets data access rules apply regardless of which form a request came from. For custom methods and integrations the team defines and tests how these rules apply on every access path. The platform documentation also covers auditing and data change history. Row-Level Security in UnityBase · Tutorials on data history and audit
Lawyer, ManagerAgroserviceLegal₴120,000
ManagerWest LogisticsProcurement₴48,500
ContractorDigital SystemsFinance₴230,000
ManagerAgroserviceProcurement₴15,000
Lawyer, Manager, ContractorDigital SystemsLegal₴64,000
The developer’s advantage: a new interface does not need a new rights system. When adding a counterparty portal, the team reuses the same contract model and server-side access mechanisms. It designs separately only which records and attachments the counterparty sees and which actions it may take.
4. Migrations as part of the application’s evolution
After launch, a model change affects historical data. If a contract used to have one budget line and now has several allocations, a new table is not enough. Existing values have to be carried over, behaviour defined for contracts with incomplete data and a check made that adjacent systems can keep working during the transition.
For such changes UnityBase documents ubcli generateDDL for the database structure and ubcli migrate for running migrations, including custom scripts in JavaScript or SQL. DDL generation brings the schema in line with the metadata. The developer defines the logic for transforming existing records. For example, the documentation explains why renaming an entity may require an explicit migration step. UnityBase application lifecycle and migrations
For our register the acceptance criterion is concrete. After the transition, the amount of every active contract must equal the sum of its budget allocations, and access to the contract must match the previous rules or explicitly approved changes.
The developer’s advantage: the model change, the data migration and the new application behaviour can be prepared within a single release.
5. Reusable data model for new interfaces
A team can add a dedicated supplier portal alongside an internal register, reusing the same entities and server methods. Each interface has its own workflow, and the team defines and tests the access rules for each audience.
UnityBase in production
Megapolis.DocNet is a document management product that InBase and Softline develop on the platform. According to the InBase case study, at the Astarta agricultural holding the system covered 37 business units and around 2,000 users, who created 1,000–1,200 documents a day. New processes were first launched in one unit, refined based on how they worked and then rolled out further. InBase product portfolio · Full Astarta case study
For a developer, the interesting part of this case is the sequence. The product has to support different processes within one organisation, and the implementation team has to refine them gradually together with the users.
The developer’s advantage: application rules and integrations can be added as real requirements appear, rather than designed in full up front.
How to integrate an AI assistant
In a contract register, a finance officer may need to read a statement of work and identify which costs belong to each budget category. An assistant can suggest categories and point to the lines that support them. The application code validates amounts, budget status and limits. The finance officer chooses and confirms the allocation.
In this design, a server module selects documents and attachments that the user is allowed to read and that the organisation permits the model to process. It calls the model through a restricted interface and records the proposal and the user’s decision. UnityBase provides access controls, server methods and audit mechanisms that the team can use when implementing these checks. The workflow also supports manual review. Controlled artificial intelligence in corporate systems
How to evaluate UnityBase on your own project
Build a small but complete scenario:
- Take a contract, a counterparty and a department.
- Set up two roles with different record visibility.
- Add one server method and pass its result to a test accounting system.
- Change the requirement: add budget allocation and migrate the contracts already created.
- Check how the change affected the API, access and the interface.
- Connect an AI assistant through the API on behalf of one of the roles. Check that it sees only that role’s records and that its proposals pass the same server checks.
During the evaluation, record which parts you got from the model, what code the team wrote and what had to change in the second iteration. Check the edition and DBMS against the official matrix for your scenario. UnityBase publishes OpenUB under the Apache License 2.0, as well as the commercial Enterprise and Defence editions. UnityBase editions matrix · Starter project for developers
For a team choosing a platform in 2027, it is the second iteration that answers the main question. How easy is it to add a new requirement to a system that already has data, access rights and users? UnityBase has concrete mechanisms to test this on your own code.