Say your Store entity has a Country column. Somebody added it in the first month, because the regional managers wanted to see the country on the store grid, and Store only knew its Region. The country lives on Region. So somebody typed it in, store by store, and the VAT rate next to it.
A year later the Amsterdam store moves to a region across the border. The steward opens the row, changes Region to Germany West, writes a comment, and saves. Nobody touches Country. Why would they? The change request said Region.
The store now sits in a German region, with Netherlands in its Country column and 21% in its VAT column. No rule fails and no error appears. The first sign is a finance report that does not add up, weeks later, and an afternoon spent working out which of the two columns is lying.
Two copies of one fact will disagree
Database textbooks call this an update anomaly. You store the same fact in two places, you update one of them, and now the data contradicts itself. Normalization exists to stop it: keep the country on the region, once, and let every store point at its region.
Master data makes the damage worse, because the copy does not stay on your grid. It goes out to the ERP, the reporting warehouse, the price list. Every system downstream now holds the wrong country with a clean audit trail behind it. We wrote about why one fact needs one home before. A typed Country column on Store is the smallest possible example of breaking that rule.
So why does everybody do it anyway? Because the people who edit stores want to see the country while they work. That need is real. A typed copy answers it badly.
The usual repairs keep the copy
The first repair teams reach for is a sync job: a nightly SQL script, or a trigger, that copies Country from Region onto Store. Between the edit and the next run, the copy is wrong. When the job fails at 02:00, nobody notices, and the copy is wrong for as long as nobody looks.
The second is a rule that fills the column. Primentra has one, and it will not solve this. A rule that fills a blank writes the value once, while the column is empty, and never overwrites it after that. We built it that way on purpose, so a code or a name you depend on does not change under you. For a country that must follow the region, that promise is the problem.
Both repairs keep a second copy alive and then work to keep it honest. You can drop the copy instead.
Read the value where it lives
A derived column puts a parent value on the grid without copying it. You give it a path: start at a domain attribute on this entity, follow it to the next entity, and pick the attribute you want to show. Store → Region → Country is one hop. Store → Region → Country → VAT rate is two, and there is no fixed limit on how many hops a path takes.
You set it up in the entity editor, under the attribute table:
- Open the Store entity and click Edit.
- Under Derived Columns, click Add and pick Region.
- Pick Country under Use as display value, or drill one level deeper for the VAT rate.
- Keep the proposed name, such as
Region / Country, or type your own, and save.
The column shows up at the end of the grid with a padlock. There is no editor behind the cell, so nobody can type into it, and no import or API call can write to it. It holds no value at all. The grid reads it from Country every time it loads the rows.
Now move Amsterdam again. Change Region to Germany West and save. Both derived columns change: Netherlands becomes Germany, 21% becomes 19%. Nobody edited them. No job ran and no rule fired. The VAT rate sits two entities away, on a record nobody opened, and the store shows the right one anyway.
This is the other half of cascading domain filters. The filter narrows what a steward can pick in the dropdown. The derived column shows what comes with the pick.
Where it stops
A derived column lives in the grid. That decides most of its limits, and you should know them before you plan around it:
| You want to | What happens |
|---|---|
| Sort or filter stores by the derived country | You can't. The column has no sort and no filter. Filter on Region instead. |
| Read the country in SQL, from another system | It is not in the integration view. A Hierarchy view walks the same chain in SQL and brings the Region and Country columns with it. |
| Export the grid to Excel | Works. The file gets what the cell shows, and a date keeps the format of the attribute it came from. |
| Show the Name of the region | Code and Name are columns of the row, not attributes, so a path can't end on them. Keep the value in an attribute and point at that. |
| Add one to an entity with no domain attributes | Nothing to follow. Country, at the top of the chain, can't have one. |
One thing it does protect. If somebody tries to delete the Region entity while Store reads through it, the delete dialog stops and names the derived column. A column two entities away cannot vanish because a person tidied up a model they never use.
When a copy is the right call
Sometimes you want the value as it was, and a copy is correct. The VAT rate on the day a contract was signed belongs to the contract. It must not change when the country changes its rate next January. Store that one, on purpose, and let a fill rule write it once.
The test is one question. If the parent changes tomorrow, should this row change with it? If yes, read it with a derived column. If no, store it, and name the column so it says when it was taken: VAT rate at signing, not VAT rate.
A copy that exists only so people can see the parent value while they edit fails that test. The screen needed the value. The table never did.
Common questions
Can I sort or filter the grid on a derived column?
No. A derived column has no sort and no filter in the grid. To find the stores in one country, filter on Region, or query a Hierarchy integration view in SQL, where the parent columns sit next to the store columns.
Does a derived column appear in an Excel or CSV export?
Yes. The grid export writes the value the cell shows, and a date keeps the format of the attribute it came from. A derived column is not in the integration views, so a downstream system reads the value through a Hierarchy view.
Can an import or the REST API write to a derived column?
No. The column stores nothing, so there is nothing to write to. An import changes the Region, and the derived column follows it.
What if somebody deletes an entity the path runs through?
Primentra checks first. The delete dialog lists what reaches into that entity and names the derived column. Removing the derived column itself deletes no data, because it holds none.
Find the copies in your own model
Look for any column whose value also lives on a parent entity. Ask the one question above. Every copy that fails it can become a derived column in about a minute, and the typed values can go.