The view says what a row holds. It never said whether the row is any good.

A warehouse load reads the supplier view every night. Say three of the suppliers in it break a business rule: one has no payment terms, two carry a VAT number in the wrong format. The load takes all three along with every clean row, and by morning they sit in a dimension table that finance reports from.

The load did nothing wrong. A view shows what a row holds. It says nothing about whether the row passed your rules, so a broken row and a clean one look the same on the way out. The people who wrote the rules see red markers in the grid, and the load sees three more suppliers.

How a failing row gets into a governed system

You could object that an enforced rule should never let a failing row be stored. In Primentra a failing row gets stored in four ways, and we built each of them on purpose.

The second one is the big one. Turn a sensible rule on against eleven years of suppliers and thousands of rows go red, which is the subject of your first business rule will fail on data you already have. Those rows stay red for weeks while a steward works through them. Every night of those weeks, the view hands them downstream.

MDS had a column for this

MDS stored a member that failed a business rule. Microsoft's documentation says so in a table: for business rule validation, the column "Is data saved to the MDS repository?" reads Yes. So a leaf subscription view carried a ValidationStatus column, and a careful ETL package filtered on it.

MDS knew five statuses: waiting to be validated, waiting to be revalidated, validation succeeded, validation failed, and waiting for dependent member revalidation. If your package kept only the rows that had succeeded, you know the catch. Members loaded through staging were not validated until somebody ran the validation procedure, and until then the package dropped them without a word.

When we wrote about MDS subscription views, we had to say that Primentra had nothing to map that column to. The only way to find the failing rows from outside was to join our internal failures table yourself. That stopped being true in August.

Two columns, off until you ask

Since version 1.2026.8.18 an integration view can carry the answer. Tick Include validation status on the view and it gains two columns:

Both read the same stored rule results the grid draws its red and amber markers from. There is one copy, so the view and the screen cannot disagree.

-- Only the rows that break nothing
SELECT *
FROM [mdm].[vw_Purchasing_Supplier_Flat]
WHERE Supplier_ValidationSeverity IS NULL;

-- The reject list, with the reasons
SELECT Supplier_Code,
       Supplier_Name,
       Supplier_ValidationMessages
FROM [mdm].[vw_Purchasing_Supplier_Flat]
WHERE Supplier_ValidationSeverity = 'error';

The option is off on every view, the ones you already have included. These views feed load packages that other people own, and a column that turns up unannounced is their outage. Turning it on regenerates the view, so tell whoever reads it before you tick the box.

In a hierarchy view the two columns describe the main row, and say nothing about the parent rows it points at. The setting travels with a model export, so a view you set up on test still has the columns in production.

What empty does not mean

An empty severity means no rule failure is stored for that row. It does not mean that anybody checked the row.

Rule results are written when the rules run: on a save, a file import, a staging batch, or Validate Now. A rule you saved this morning has not looked at the rows saved last year. Until it does, those rows read as empty and a filter on IS NULL lets them through. MDS gave that state a name, waiting to be revalidated. Primentra does not mark it per row.

So make it a habit. After you add or change a rule, run Validate Now on the entity before the next load. It runs every active rule against every row and stores the result, and the grid header shows how long ago the last run was.

Reject, or load and flag

The columns give the load a choice that SELECT * never had, and I have an opinion on it. Do not filter silently. A load that drops failing rows and tells nobody swaps one problem for another: the supplier is missing from the warehouse, its invoice lines point at nothing, and the person who notices has no idea why.

I would build it this way: load every row without an error, warnings included, and write the error rows to a reject table with their messages. The steward gets a list with the reason on every line, and the load report says how many rows stayed behind.

Warnings belong in the warehouse. A warning marks a row somebody should look at. Hold it back and you have turned it into an error without changing the rule.

Common questions

If you have a package that filters on ValidationStatus today, try it in the trial. Build the view, tick the box, point the query at it, and see what the WHERE clause has to become.