Twenty beyond the CRM: a back office for your business data

If your properties, projects or equipment live in a spreadsheet, and your site’s requests in a mailbox, you are missing a place that is the single source of truth. Twenty, an open-source CRM with an open data model, can play that back-office role for your business data. We use it this way for Palmora Property, a property portal that we operate.

This guide says what this use allows, what it requires and where it stops, without repeating our account of running Twenty in production or our comparison of Twenty, Dolibarr and Odoo.

Why can a CRM serve as a back office?

This back office is often built with a shared spreadsheet, a custom database or a CMS. A CRM with an open data model has an advantage over them: contacts and business data live in the same place, linked to each other.

Twenty’s data model documentation starts from standard objects (people, companies, opportunities, notes, tasks) and provides custom objects for everything else, such as projects, subscriptions or events. Its features page adds what a spreadsheet does not give you: more than twenty field types, relations between objects, table, kanban or calendar views, import with duplicate detection and export at any time. Access rights are set by role; taking them down to the level of the individual record requires the paid Organization plan, according to Twenty’s pricing page.

Which objects can you put in Twenty besides contacts?

Anything your team names, tracks over time and links to people. A few examples:

The rule: one object for each thing the team names, and a relation whenever you say “this owner’s property” or “the interventions on this machine”. Twenty’s documentation recommends this for products that are sold: making them a separate object lets you manage one, two or a hundred without changing the model.

This is not just a vendor’s argument: several user reviews published on Product Hunt, viewed on 4 October 2026, praise the freedom to shape the tool around their team rather than the other way round. It is the first job of our CRM offer: a set-up in your own vocabulary, connected to your site.

How do your site and your tools read this data?

Through the API. According to Twenty’s API documentation, the REST and GraphQL APIs are generated from your workspace’s schema: a custom object gets its API access as soon as it is created. A second API, called the metadata API, changes the schema itself. Keys are displayed only once and are tied to a role, which makes it possible to limit the site to what it needs to read.

Querying Twenty on every visit would make the site depend on the CRM: if it slows down or stops, so does the site. The same documentation also states usage limits:

A scheduled sync is better: it reads the publishable records at a fixed time and updates the site.

To react without waiting, Twenty’s webhooks signal the creation, update or deletion of a record, custom objects included, with a signature to verify. According to that documentation, an error response is logged as a delivery failure, with no retry described: the webhook triggers, and a scheduled re-read catches whatever was missed.

How do visitors’ requests get back into Twenty?

Through the same API, in the other direction. The site’s form sends the request to a small server function, which creates the record in Twenty and links it to the person and to what they are interested in; the site side is detailed in our guide to forms and search on a static site.

Twenty’s workflows then take over. Triggered by a record change, a schedule, a manual action or an incoming webhook, they create or update records, send an email from a connected account or call another service. When the process crosses several tools, an automation tool such as n8n links them together. In both cases, an automation that fails silently is worse than a manual task, hence our method for monitoring n8n automations.

One rule is not negotiable: record the request before notifying anyone. If the email fails, the request is still there.

How does Palmora Property use Twenty?

Palmora Property is a property listings portal in Thailand, built and operated by us, from the site to the CRM that receives the requests. Its Astro site is served in six languages, across more than 3,000 URLs. Twenty is self-hosted there and connected to the site, and n8n workflows feed it every day.

Everything goes through Twenty’s GraphQL API. A callback request is saved before any email is sent, so that a failed email does not lose it, and the team receives an alert for each new request. The idea that holds it all together: record visitors’ interactions in the same tool as the properties, to handle them better.

We have been running Twenty in production since early 2025, notably for Palmora Property, and we contribute to the open-source project; the operating lessons are in our review of running Twenty in production.

How do you set up this back office, step by step?

1. 01List the objects and their links.

   Before entering anything, note down what the team names and the sentences that connect those things. A badly defined object can be corrected later, but every correction affects the records, the views and the integrations.

2. 02Set up the fields that decide from the start.

   Status, origin, owner: they say what gets published, where a record comes from and who handles it.

3. 03Decide who reads what.

   The site reads a synchronised copy of what is publishable, not the live database, with one API key per use and the narrowest possible role.

4. 04Bring requests back through the API.

   Each one is saved before any notification, and linked to the person and the object concerned.

5. 05Automate, then monitor.

   Twenty’s workflows for what stays inside Twenty, n8n for what crosses several tools, a scheduled re-read to catch a missed webhook.

6. 06Name someone who is accountable for the tool.

   They evolve the model, apply updates and check the backups.

Beyond configuration, Twenty also lets you write an application, which bundles its own objects, functions and interface components.

Where does this use stop?

It is not an ERP. The API documentation takes an invoice as an example of a custom object, but an object is not an invoicing module: numbering, taxes, legal requirements and accounting entries would still have to be built, then maintained. The same goes for stock. When quotes, invoices and stock need to live in the same tool as the customers, an ERP such as Dolibarr or Odoo is a better fit, as our guide to choosing between Twenty, Dolibarr and Odoo explains. Accounting stays in your accounting software.

Self-hosted, it is your responsibility. Twenty’s upgrade guide tells you to back up the database before starting; migrations then run at start-up. Backups, updates and server monitoring have to be planned for, by you or by a provider; our guide to backing up a server of your own says what really causes data loss.

The licence governs changes to the code. According to the project’s licence file, the core of Twenty is under AGPL v3, and the files marked “Enterprise” fall under a commercial licence. An exception covers applications that talk to Twenty through its published interfaces (API, webhooks, development kits) without incorporating or modifying its code: they do not fall under the AGPL for that reason alone. Modifying Twenty’s code and serving it over a network, on the other hand, requires you to offer the modified source code to its users.

The product is young in some respects. Several user reviews on Product Hunt consider some parts less polished than in older CRMs. List your must-haves and check them before committing.

Is Twenty the right back office for you?

Yes, if your business fits into objects linked to people, if your site needs to publish this data and if requests need to come back to the same place. Start with one object and one flow, for example the site’s requests, then expand. If you would rather not carry the installation yourself, our CRM offer installs Twenty in your vocabulary and connects it to your site: €4,500 for Twenty; backups, updates and monitoring can then be provided as a subscription. All our guides on the subject are gathered in the CRM and customer data section.

Frequently asked questions

Sources

1. Twenty’s data model documentation (new tab)docs.twenty.com
2. Features page (new tab)docs.twenty.com
3. Twenty’s pricing page (new tab)twenty.com
4. User reviews published on Product Hunt (new tab)producthunt.com
5. Twenty’s API documentation (new tab)docs.twenty.com
6. Twenty’s webhooks (new tab)docs.twenty.com
7. Twenty’s workflows (new tab)docs.twenty.com
8. Application (new tab)docs.twenty.com
9. Twenty’s upgrade guide (new tab)docs.twenty.com
10. Project’s licence file (new tab)github.com
11. Self-hosting documentation (new tab)docs.twenty.com