How They Work Together
The three levels form one simple hierarchy: a model contains entities, and each entity contains attributes.
A Customer Management model can hold a Customers entity with Customer Name, Registration Number and Industry, alongside a Contacts entity with Name, Email Address and Phone Number.
The structure grows with you:
- Need a new field? Add an attribute.
- Need a new type of record? Create an entity.
- A whole new business domain? Create a model.
Where each decision belongs
| Question | Level | Page |
|---|---|---|
| Which business domain is this? | Model | Models |
| Which type of record is this? | Entity | Entities |
| What do we capture per record? | Attribute | Attributes & Data Types |
| How do records relate to each other? | Domain attribute | Domain Attributes & Hierarchies |
Reference data that several models need — Country, Currency, status codes — is created once and shared. See Domain Attributes & Hierarchies.
Managing multiple countries
If your organization works across countries, you do not need a Primentra installation per country. Create a model per country — "Customers NL", "Customers DE", "Customers FR" — and use permissions to control who sees what.
Grant each country's users access only to their own model and they see only their own data. A user in Germany does not see the Dutch customers, and the reverse.
One thing to keep in mind: administrators who manage the overall setup normally need access across every model, including other countries. Think carefully about who you make an administrator, because they can view and edit data in all of them.
Permissions across the three levels
Primentra uses role-based permissions. Permissions are always granted through roles, never directly to a user. To understand what a user can do, you only have to look at their roles.
Permissions cascade. What is set at the model level applies to every entity and attribute inside it, unless a lower level overrides it.
So you can grant broad access at the model level and tune it where needed: give a role Read on a whole model, raise specific entities to Write, and restrict individual attributes to None.
- At model and entity scope, permissions are CRUD toggles: Create, Read, Update, Delete, plus a Moderator flag for configuration access.
- At attribute scope: None, Read, Write.
Related
- Models — the top level
- Entities — the middle level
- Attributes & Data Types — the bottom level
- Roles & Permissions — the permission model in full
- Best Practices — how to put it together