Introduction – how nexxcite is built¶
This chapter explains the ideas behind nexxcite: what an application in nexxcite consists of, where it is configured and how changes reach the users. All other chapters build on these terms.
It is intended for administrators who configure nexxcite and for operators of an installation.
1. nexxcite at a glance¶
nexxcite is a low-code platform. The application your users work with – its data, screens, processes and permissions – is not programmed but configured. Administrators describe it in visual editors, and nexxcite runs it.
| Term | Meaning |
|---|---|
| Definition | One piece of configuration: an entity, a form, a query, an action, a role. Everything an administrator configures is a definition. |
| Entity | A kind of business object, for example "Ticket", "Customer" or "Invoice". An entity has fields and is stored as a table in the database. |
| Record | One business object of an entity, for example one ticket. Records are the data your users create and edit. |
| Application | What your users see and work with: forms, lists, dashboards, buttons. |
| Admin Studio | The workspace in which administrators create and change definitions. |
| Sketch | A collection of definition changes that have not been published yet. |
2. Definitions¶
Every part of an application is a definition of a certain type. The types are grouped here the same way the chapters of this documentation group them. The Admin Studio uses a slightly different grouping, described in Admin Studio:
| Area | Definition types |
|---|---|
| Data model | Entities and their fields, relationships between entities, counters, global values |
| User interface | Forms, grids, lists, app bars, dashboards and widgets, themes, images, icon fonts |
| Logic | Expressions, filters, queries, business rules, actions, business hours |
| Automation | Scheduled actions, mailbox listeners |
| AI | AI assistants |
| Access | Users, roles, authentication providers, API access, credentials |
| System | Sketches, global settings, license |
Each definition type is described in its own chapter of this documentation.
Definitions belong to an entity¶
Most definitions are created in the context of an entity: a form shows records of one entity, a query returns records of one entity, a business rule reacts to changes of records of one entity. This context decides which fields a definition can use and which records it applies to.
Some definitions are not bound to an entity: themes, roles, global values, counters, business hours and similar definitions apply to the whole installation. Expressions are not bound to an entity either, but they are always evaluated for a record – an expression that reads fields of "Ticket" is only useful where a ticket is at hand.
Example: "The total of an order is recalculated when an order line changes" is a business rule on the entity Order, because the order carries the total – even though the order line is what changes. The rule reads the lines through the relationship between the two entities.
Definitions refer to each other¶
Definitions are building blocks that are combined: a form contains a button, the button starts an action, the action runs a query and changes records, a business rule reacts to the change. Before a definition is deleted, the Admin Studio shows where it is used, so that no reference is broken unnoticed.
3. Where definitions are changed¶
Definitions are edited in editors. The same editors are reached in two ways:
- In the Admin Studio – the administration workspace with a navigation over all areas and several editors open side by side. See Admin Studio.
- From the running application – for example with Alt+E on a form, a dashboard or a list of search results, which opens the editor of what is shown. The editor opens as a panel from the bottom of the screen.
Both ways need the corresponding permissions. Which permissions exist and how they are assigned is described in the chapter on roles and permissions.
4. How changes reach the users¶
A change to a definition does not take effect immediately by default. It is collected in a sketch first. Only when the sketch is published do the changes become effective for all users – together, in one step.
This has three advantages:
- Several related changes (a new field, the form that shows it, the rule that fills it) go live at the same time and never half-finished.
- The changes can be reviewed before they are published.
- A published sketch can be rolled back.
The details are described in Sketches and publishing.
5. The AI assistant¶
nexxcite contains an AI assistant that can read and change the configuration on behalf of an administrator. It works within the same rules as an administrator:
- It only does what the permissions of the signed-in user allow.
- Its changes go into the open sketch and take effect only when a person publishes the sketch.
- It answers questions about nexxcite based on this documentation, in the version that is installed.
How AI assistants are set up is described in AI assistants.
6. Frequently asked questions¶
Do we need programming knowledge to configure nexxcite? No. Definitions are created in visual editors. Some editors – expressions, for example – offer formulas for calculations and conditions, comparable to formulas in a spreadsheet.
Do changes in the Admin Studio affect users immediately? No, as long as changes are made in a sketch. They take effect when the sketch is published. An installation can be configured to allow changes without a sketch; see Sketches and publishing.
Where can I see which version of nexxcite is installed? With "About nexxcite" in the user menu (your name or picture at the top right).