Models, Entities & Attributes: How Primentra Organizes Your Master Data

One thing Microsoft got right with MDS was the conceptual model. Models, entities, attributes. Three levels. Clean hierarchy. If you understood databases, you understood the structure. The problem was never the concept. The problem was everything wrapped around it.

When I started building Primentra, keeping that same three-level structure was the easiest decision I made. It works. MDS users already think in these terms. Why reinvent a mental model that's already correct?

Models = business domains

A model is the top-level container. It groups related data together and acts as the first layer of access control. If you think in terms of database schemas, a model is like a schema. If you think in business terms, it's a domain.

Most organizations I've worked with end up with somewhere between 2 and 6 models. A typical setup:

• Organizational Structure — branches, regions, zones, cost centers
• Customer Management — customers, contacts, segments
• Product Management — product lines, categories, SKU reference data

Permissions work at the model level, so giving a team access to "Customer Management" automatically gives them access to all entities inside it. No need to configure every entity separately unless you want more granular control.

The multi-country trick

I've seen organizations get creative with models for multi-country setups. Create Customers NL, Customers DE, Customers FR, each with the same entity structure. Grant German users access only to the DE model. Dutch users see NL only. Administrators see everything. Instant multi-tenant isolation without any architectural gymnastics.

Entities = your actual data tables

Inside each model, you create entities. An entity is a type of record. If you're a database person: it's a table. Each entity gets its own grid view where data stewards work with the data.

For an "Organizational Structure" model, you might have:

• Zones — broad geographic groupings (Europe North, Europe South)
• Areas — regions within zones (Netherlands, Belgium)
• Branches — individual offices (Amsterdam Central, Rotterdam South)

These entities link together through domain attributes. A Branch has an Area field. An Area has a Zone field. The hierarchy builds itself: Zone → Area → Branch.

Cross-model sharing (the feature MDS never had)

This was one of the most requested features from MDS consultants I talked to, and Microsoft never delivered it. In MDS, a domain attribute could only reference entities within the same model. If you had a "Country" entity in Model A and needed it in Model B, you had to duplicate it. And then keep both copies in sync. Manually. Forever.

Primentra lets you mark an entity as "Shared across models." One checkbox. That entity becomes available as a domain reference in any model. Countries, currencies, tax codes, status values, any reference data that cuts across business domains. Define it once, reference it everywhere. No duplication, no sync headaches.

Attributes = columns on your data

Attributes define what fields each record in an entity has. Same concept as columns in a table. A "Branches" entity might have: Address (text), Employee Count (number), Opening Date (date), and Area (domain reference to the Areas entity).

Four types, same as MDS:

If you're coming from MDS: Text is Text, Number is Number, DateTime is DateTime, and Domain-Based Attribute is just called "Domain." We dropped the jargon, kept the concept.

Code and Name: the two fields you always get

Every entity automatically has Code (unique identifier, used for imports and domain dropdowns) and Name (human-readable label). Domain dropdowns show values in the {Code} Name format. If you're used to seeing {AMS} Amsterdam in the MDS Excel Add-in, same thing here.

A real example: branch network

I always explain this with the same example because it's the use case I've seen most often in MDS deployments. An organization manages branch offices across multiple regions. They need to track which branch belongs to which area, and which area belongs to which zone.

In Primentra, you create a Branch Network model. Inside it: three entities (Zones, Areas, Branches). Areas get a domain attribute pointing to Zones. Branches get a domain attribute pointing to Areas. The hierarchy builds itself.

Add whatever extra attributes you need on Branches: Address (text), Employee Count (number), Opening Date (datetime). Data stewards open the Branches entity, see a spreadsheet grid, double-click a cell to edit, select an Area from a dropdown showing {NL} Netherlands, and save. That's it. No MDS Configuration Manager. No staging tables.

Got data in Excel? Copy-paste it in. Domain references resolve automatically. Ctrl+Z if you mess up.

Permissions that cascade sensibly

Permissions follow the same model → entity → attribute hierarchy. Set Read at the model level, and everything inside inherits it. Override specific entities with Write. Hide individual attributes with None.

Practical example: "Branch Managers" group gets Read access to the whole Branch Network model. Write access on the Branches entity specifically, so they can update their data. But the Employee Count attribute is set to None, because headcount data is HR's business, not theirs. Three permission rules. Done. In MDS, getting this right involved a painful combination of model permissions, entity permissions, and leaf member security that most people gave up configuring correctly.

Adding and changing as you go

Data models aren't static. New fields get added. New entity types emerge. In MDS, adding an attribute often meant stored procedure calls or navigating the labyrinthine web UI. In Primentra, you open the admin panel, click "Add attribute," pick a type, and it shows up as a new column in the grid. The underlying SQL Server table is updated automatically.

Need to duplicate an entire entity with its data? Entity Clone. One click. Useful for creating quarterly snapshots or spinning up a test copy.

The MDS migration cheat sheet

If you're coming from MDS, here's the quick mapping:

Primentra's Migration Wizard imports your MDS models, entities, and attributes automatically, including domain references. Most migrations take minutes. The concepts are the same; the tooling is just better. The MDS migration guide covers the full process step by step, and how approval workflows work shows how the governance layer fits on top of this structure.

Want to see this in action? The demo shows the full model → entity → attribute flow with real data. Or start the 60-day free trial on your own SQL Server.

• No cloud migration — stays on your own SQL Server
• No professional services required — self-service from day one
• No credit card for the trial