Software Model Condition Not Fully Reflected in Reconciliation Results

[David69]

I am trying to understand how conditions set at the Software Model level should be reflected in reporting.

• I configured a condition at the Software Model level to filter installations based on Install Status. 
• At the Software Model view, the results align exactly with expectations based on this filter.

However, when I move up to the Product and Company level I still see installations “requiring action.”

When I drill into those records they all match the condition applied at the Software model level.  

Is there a recommended solution for propagating the software model condition to the product and company level so that they do not show as non-compliant like the screenshot?

[Naveen20]

The root cause is that compliance conditions at the Software Model level don't automatically propagate upward to the Product and Company rollup levels. Each level in the hierarchy calculates compliance independently.

Here's what's happening: when you set a condition on the Software Model (e.g., filtering by Install Status), that model correctly excludes those installations from its own compliance calculation. But the Product-level and Company-level rollups still see the raw installation counts — including the ones your model-level condition excluded — and flag them as requiring action.

Recommended approaches:

1. Apply conditions at every level of the hierarchy. Set matching conditions on the Software Model, the Product result, and the Company result. This ensures each rollup level applies the same exclusion logic. It's the most straightforward fix but requires maintenance if you have many products.

2. Use Reconciliation Rules instead of (or alongside) Model-level conditions. Reconciliation rules can be scoped more broadly and tend to cascade more predictably through the hierarchy. Check if a rule-based approach at the Product level achieves the same filtering without the rollup disconnect.

3. Mark irrelevant installations as Excluded at the source. Rather than filtering them out via a condition, update the Install Status or set an exclusion flag on the cmdb_sam_sw_install records themselves. If the installations are genuinely out of scope (e.g., status = "Removed" or "Absent"), excluding them from the dataset entirely means they won't appear at any level.

4. Run a full reconciliation after applying changes. After adjusting conditions or exclusions, trigger a fresh reconciliation run — the compliance percentages at Product and Company level won't update until the next reconciliation cycle completes.

Option 3 is generally the cleanest long-term solution since it addresses the data at the source rather than layering conditions at multiple hierarchy levels. If that's not feasible because you need those installations visible elsewhere, option 1 (duplicating conditions across levels) is the most reliable workaround.