How They Work Together
How They Work Together
The three levels form a simple hierarchy: a Model contains one or more Entities, and each Entity contains one or more Attributes.
For example, a "Customer Management" model could have a "Customers" entity with attributes like Customer Name, Registration Number, and Industry — alongside a "Contacts" entity with Name, Email Address, and Phone Number.
This structure gives you flexibility as your needs grow. Need a new field? Add an attribute. Want to track a new type of data? Create a new entity. An entirely new business domain? Create a new model.
Shared Entities Across Models
By default, a domain attribute can only reference entities within the same model. However, Primentra supports sharing an entity across models — making it available as a domain reference in any model.
When to use it: Shared entities are useful for reference data that applies across your entire organization. For example, a "Country" entity or "Currency" entity might be needed in multiple models — Customer Management, Product Management, and Supplier Management all need to reference the same list of countries.
How to enable it:
- Go to Settings → Models and select the entity you want to share
- Check the Shared across models option in the entity form
- Save the entity
Once enabled, the entity will appear as a domain reference option when configuring attributes in any model — not just the model it belongs to. In the attribute configuration dropdown, shared entities from other models show the source model name for clarity.
Important notes:
- The entity data itself lives in its original model — sharing does not duplicate the data
- Permission settings on the shared entity still apply; users need at least Read access to see the dropdown values
- This is a Primentra-exclusive feature — Microsoft MDS does not support cross-model references
Managing Multiple Countries
If your organization operates across multiple countries, you don't need a separate Primentra installation for each one. Instead, you can create a model per country — for example "Customers NL," "Customers DE," and "Customers FR" — and use permissions to control who sees what.
By granting each country's users access only to their own model, they will only see the data that's relevant to them. A user in Germany won't see the Dutch customer data, and vice versa.
One thing to keep in mind: administrators who need to manage the overall setup will typically need access across all models — including those of other countries. Think carefully about who you assign admin permissions to, as they will be able to view and edit data across all countries.
Permissions
Primentra uses a role-based permission system. Permissions are always granted through roles — never directly to individual users. This keeps access control transparent and auditable: to understand what a user can do, you only need to look at their role memberships.
Permissions cascade across three levels. Permissions set at the model level apply to all entities and attributes within it, unless overridden at a lower level.
This means you can grant broad access at the model level and fine-tune it where needed. For example, you can give a role Read access to an entire model, then upgrade specific entities to Write access, or restrict individual attributes to None.
At model/entity scope, permissions use granular CRUD toggles: Create, Read, Update, Delete, plus a Moderator flag for configuration access. At attribute scope: None, Read, Write. See Access Management → Roles & Permissions for full details.