One model, many screens
xMatix is metadata-driven. Every business object — an order, an account, an item, a journal — is an entity whose definition lives in the tenant's metadata: its fields, relations, record types, views, layouts, validations and actions. The list you scroll, the form you fill in and the mobile screen a technician taps are all rendered from that definition. Two organizations running the same entity can see quite different screens because their metadata differs, not because their software does.
Metadata supplies the common model; it does not mean every behavior is generated. Standard entities are also compiled types with first-party handlers that implement feature-specific validation and side effects (an order posting stock, an invoice creating ledger entries). Custom entities use the platform's dynamic storage and get the shared list, form, view, relation and access framework, but not those compiled handlers.
Entities are definitions; records are the rows
An entity defines a type of record: which fields it has, how it relates to other entities and what users may do with it. A record is one instance of that type. The Order entity says what every order carries — customer, dates, status, amounts — and each order your team creates is one Order record.
Relations are what make navigation work: an order references its account, an invoice references the order it bills, so related records are always one click apart. Document-style entities pair a header with lines — an order and its order lines are two entities joined by a relation — so one business transaction is stored as one header record plus its line records.
Where the definition lives: Design Studio → Entities
- 1
The breadcrumb places you inside one entity's definition (Order → Schema → Fields), not inside a list of order records.
- 2
Schema, Logic and Experience group the parts of an entity: fields, relations and record types; validations, actions and approvals; views, layouts and email templates.
- 3
System marks fields that shipped with the platform; fields your organization adds carry a Custom badge, so you can always tell which attributes are yours.
- 4
Type is what the user sees (Lookup, Text, Currency, Calculated, PickList); Data Type is how the value is stored.
- 5
Required and Filterable are field switches; together with sorting and grouping flags they decide how the field behaves in forms and lists everywhere.
- 6
New adds a custom field to this entity — every existing and future Order record gains it at once.
Administrators manage definitions in Setup → Design Studio → Entities. The registry lists every entity with its label and a System or Custom badge; opening one shows an Overview (label, collection label, icon and color, and the behavior switches: Create, Edit, Delete, Merge, Search, Audited, Notes, Activities, duplicate detection, recently-viewed tracking, list/form/query support) and three groups of sub-pages:
- Schema — Fields, Record Types, Field Mappings, Lookup Filters, Relations and Field Dependencies.
- Logic — Validations, Actions, Approval Processes, Document Settings and the Execution Plan.
- Experience — Views, Layouts and Email Templates.
New on the registry starts a custom entity definition; it never creates an ordinary business record. Records are created inside the business apps.
The registry's Fields / Relations / Views / Record Types count columns are recalculated when an entity definition is saved. Entities that arrived through a platform seed and have never been re-saved can show 0 there even though they have many fields — open the entity and read the Schema pages rather than trusting the registry counts.
Fields
A field is one attribute of a record. Each field has a Type (Text, Number, Currency, Date, PickList, Lookup, Calculated and so on), an underlying Data Type, and behavior switches: Required, Hidden, Filterable, plus whether the field allows sorting and grouping in lists. Lookups reference a record of another entity and are created through a relation, not directly. Fields on a standard entity carry the same System / Custom badge as entities, so you can always tell which attributes your organization added.
Adding a field to an entity changes every existing and future record of that entity at once — there is no per-record schema.
Record types
A record type is a named variant of one entity: a Service Order and a Sales Order can be two record types of Order, each with its own label, default flag and active flag. Layouts, views and validations can be scoped to a record type, and an app's navigation entry can point at one record type, so users who only handle one variant see only its list, form and rules. Unscoped metadata keeps applying to every record type, so adding a record type is additive.
Views
A view is a saved way of looking at a list. Two kinds exist and they answer different needs:
- Shared (administrator) views are metadata on the entity: a label, a filter condition, a sort order, its columns, optional summary cards, and a View Type (a plain list, a grouped list on a group field, or a tree on a parent field). One view per entity is the Default; Hidden and inactive views stay out of the picker. Because they are metadata, they are the same for everybody who can see the entity and are the right place for team-wide definitions such as My Open Orders or Overdue Invoices.
- Personal views are saved by a user from the list itself. They layer runtime state — search text, sort, column visibility and column order — on top of the shared view they were saved from, and are stored in that user's own preferences. Only their owner sees them, they never change what colleagues see, and each user can keep up to 20 per entity. Filter conditions set in the filter drawer are not captured by a personal view in the current release.
Layouts
A layout defines how a single record is arranged on screen: which fields appear, in which sections and order, and which related lists and widgets accompany them. Each layout has a Type — Create, View, Preview (the side-panel preview of a record) or Action (the form an action pops up) — and a Platform: Web, Mobile, or Both, where one layout record carries a web arrangement and a mobile arrangement side by side. A layout can be scoped to a record type and one layout per type is the default. Layouts are authored in the layout designer; see Design a form layout.
Apps group entities into workspaces
An app is a workspace for one area of the business. Its definition holds:
- Entities — which entities appear in the app's navigation, with an optional display label, group title, order, a default entity that opens first, and optionally a record type so the entry lists only that variant.
- Navigation items — built-in feature routes (Reports, Dashboards, Analytics, Recycle Bin), custom App Pages designed for that app, and grouped entries backed by a list app.
- Web and Mobile switches, an icon and color, an active flag, a hidden flag and a display order.
- An optional product license, so the app is only offered to tenants licensed for that module.
The App Launcher in the top bar lists the apps that support the client you are on (web or mobile), lets you search by app name or by the name of an entity inside an app, and lets you pin favorites. Which apps a user sees is also governed by their security profile: an app must be granted to the profile before it appears, and the entities inside it still require entity permissions. Administrators manage apps under Setup → Design Studio → Apps.
Standard and custom entities
xMatix ships standard entities across its modules — accounts, orders, invoices and payments; items, stock and transfers; purchase orders and goods receipts; journals; leads, opportunities and cases; visits, service orders and assets. Your organization is not limited to these:
- Extend a standard entity by adding custom fields, relations, record types, views, layouts, validations and actions. Custom fields on a standard entity are provisioned by a background schema step after you save them; give it a moment before you expect the field in lists and forms.
- Define a custom entity for data the standard set does not cover. It is stored in the platform's shared dynamic storage, participates in apps, lists, views, layouts, relations, security profiles and record security exactly like a standard entity, and is ready to hold records as soon as it is saved. It does not inherit the compiled handlers or specialized widgets of a standard entity — add validations, business rules or automation scripts explicitly for any behavior you need.
Confirm required behavior — not only fields — before replacing a standard process with a custom entity. The step-by-step guide is Create a custom entity.
One definition drives web and mobile
Web and mobile read the same entity, field, view and access metadata, so a new field, a governed picklist or a custom entity is recognized by both. Their renderers are not identical: a layout can target Web, Mobile or Both, some widgets exist on one surface only, and a compiled feature can add behavior on one client. Validate the target layout and workflow on each client your users rely on before announcing a change.
Common questions
What is the difference between an entity and a record?
An entity is the definition; a record is the data. The Order entity says what an order is — its fields, relations and behavior — while each actual order in your organization is one Order record. Users spend their day with records; administrators spend theirs with entities. When someone says "we added a field to Orders", that is a change to the entity, and every existing and future order record gains that field.
Can we add our own entities and fields?
Yes. Administrators can add fields to standard entities and define new custom entities in Design Studio → Entities without any code. Custom entities get the shared list, view, layout, relation and access infrastructure. They do not automatically inherit the feature-specific handlers of a standard entity, so add and test any required automation explicitly.
Why does a list look different for me than for a colleague?
Three layers can differ. You may be on a different shared view (check the view picker), you may have a personal view or column arrangement applied on top of it, or your security profile may grant you fewer fields or a narrower set of records. Shared views and field permissions are administrator settings; personal views and column order are yours to change from the list toolbar — see Personalizing lists and views.
Why do web and mobile show the same field?
Because they share the same entity, field and access model. The presentation and supported layout behavior can still differ, and some features use client-specific widgets. Treat shared metadata as the common contract, then test the configured list, form and action on both clients that will use it.