How Software Asset Management (SAM) Reconciliation WorksSummary<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Software reconciliation in Software Asset Management (SAM) evaluates discovered software usage against available software entitlement rights and generates a compliance position. The simplest way to understand the process is: Discovery → Normalization → Software model → Eligible entitlements → Entitlement applicability → Consumption rules/allocations → License metric calculation → Rights consumption → Licensed/unlicensed result → Reconciliation results Reconciliation is not a simple comparison of installation count against purchased quantity. SAM must first identify what software is installed, determine which software model represents it, determine whether an entitlement is applicable, determine whether the affected user/device/server can consume that entitlement, calculate the rights required by the license metric, and then determine whether sufficient rights are available. 1. Discovered software enters reconciliation Discovered software installations are stored in cmdb_sam_sw_install. Important reconciliation fields include norm_publisher, norm_product, discovery_model, software_model, is_reconciled, unlicensed_install, is_allocated, allocation_needed, license_metric_result, software_model_result, inferred_suite, inferred_suite_product, cloud_provider, and cloud_license_type. The installation's discovery model is stored in cmdb_sam_sw_discovery_model. Important normalized values include norm_product, norm_version, and norm_edition. Normalized product information is associated with the software product stored in samp_sw_product. Normalization is important because reconciliation operates on normalized licensing identity rather than only the raw discovered display name. For example, an installation discovered as "Microsoft SQL Server Enterprise 16.x" may normalize to Product = SQL Server, Version = 2022, Edition = Enterprise. If normalized version or edition is missing or incorrect, the expected entitlement may never become applicable even when the customer owns sufficient rights. 2. Software model determines the licensable identity The licensable software definition is represented by the software product model in cmdb_software_product_model. The software model can represent publisher/product, version, edition, licensing relationships, suite relationships, and upgrade/downgrade relationships. The installation in cmdb_sam_sw_install can reference this model through software_model. The software model is the main bridge between discovered software and the software entitlement in alm_license. SAM therefore does not simply compare product names. Example: if the discovered installation resolves to Product X Enterprise but the entitlement references Product X Standard, the fact that both belong to Product X does not automatically make the Standard entitlement applicable to Enterprise. 3. SAM identifies products that need reconciliation Reconciliation works at publisher/product level rather than treating the entire software estate as one calculation. Software products are stored in samp_sw_product, and SAM builds reconciliation work for products that have relevant licensable usage or entitlements. For advanced execution troubleshooting, product work is represented internally through reconciliation tasks in samp_recon_task_queue. The task queue can contain tasks such as prepare publisher, reconcile product, prepare preference stage, preference stage wrap up, publisher wrap up, and reconciliation wrap-up tasks. The task queue is execution infrastructure. It is useful when reconciliation is stuck or incomplete, but it should not normally be the first place to investigate why a specific installation is unlicensed. 4. Software entitlements are evaluated Software entitlements are stored in alm_license. Important reconciliation-related fields include software_model, license_metric, install_status, product_type, metric_group, rights, unlimited_license, and the resulting license_metric_result. A record existing in alm_license does not mean that it automatically participates in reconciliation. SAM applies eligibility conditions before an entitlement becomes a licensing candidate. The OOB implementation checks conditions such as whether the entitlement relates to the relevant product/software model, whether install_status represents an active entitlement, whether license_metric is populated, whether the entitlement is not a maintenance-only entitlement for the licensing calculation, and whether custom metric processing permits the metric group. This gives the first important rule: Entitlement exists ≠ Entitlement is eligible for reconciliation 5. Custom license metrics can be included or excluded The property com.snc.samp.recon.enablecustommetrics controls whether custom license metrics participate in applicable reconciliation processing. The implementation treats custom metrics as enabled only when the property value is exactly true. When custom metrics are not enabled, relevant entitlement queries exclude the custom metric group. When a custom metric entitlement exists in alm_license but does not participate in reconciliation, validate com.snc.samp.recon.enablecustommetrics before investigating rights quantity. 6. Entitlement applicability is determined Once SAM has candidate entitlements, it determines whether those entitlements can actually cover the software being reconciled. Applicability can depend on product, software model, version, edition, license metric, downgrade/upgrade relationships, suite relationships, maintenance or Software Assurance, install conditions, cloud licensing rules, and publisher-specific licensing logic. This gives the second important rule: Eligible entitlement ≠ Applicable entitlement For example, a valid active entitlement with unused rights can still be unusable if its software model does not cover the installed edition. 7. Version and edition are important applicability inputs Normalized version and edition are stored on the discovery model cmdb_sam_sw_discovery_model, particularly norm_version and norm_edition. The entitlement normally points to a software model in cmdb_software_product_model, and that model can contain version and edition information. SAM can create specific unlicensed reasons when normalized version or edition is missing and the available licensing paths require those values. Therefore, when an installation unexpectedly reports no applicable entitlement, do not begin by counting alm_license.rights. First compare the discovery model's normalized version/edition with the entitlement's software model. 8. Downgrade relationships can extend entitlement coverage Downgrade relationships are represented in samp_downgrade_model. Reconciliation evaluates active downgrade relationships when determining whether rights associated with one software model can cover another model. Example: Installed software = Product 2019 Enterprise; Entitlement = Product 2022 Enterprise. If an active downgrade relationship allows the 2022 model to cover 2019, the 2022 entitlement can become applicable to the 2019 installation. Without a valid downgrade path, the newer entitlement should not be assumed to cover the older installation. This is especially important when a customer says, "We own a newer version, so the old version should automatically be licensed." Reconciliation relies on the configured licensing relationships rather than that assumption. 9. Suite relationships can change the licensing path SAM can evaluate suite relationships so that component installations may be licensed through a suite rather than independently. Suite-related information can be reflected on cmdb_sam_sw_install through inferred_suite and inferred_suite_product. Suite/product relationships influence how SAM groups connected products and evaluates licensing options. The property com.snc.sam.auto_suite_inference controls relevant automatic suite inference and suite-product connectivity behavior. When enabled, reconciliation can use suite relationships while constructing product groups; when disabled, that automatic suite connectivity path is not used. The presence of suite components alone does not guarantee that a suite entitlement will be consumed. SAM still needs a valid software-model relationship, applicable entitlement, satisfied conditions, eligible consumer, and sufficient rights. 10. Product/install conditions are separate from entitlement consumption rules A software-model or product licensing path can have installation conditions that determine whether a discovered installation qualifies for that path. These conditions operate against licensable entities such as records in cmdb_sam_sw_install. An install condition answers: "Does this installation qualify for this software/product licensing path?" A consumption rule answers: "Can this user/device/server consume rights from this entitlement?" These are different checks. An installation can therefore match the correct product and software model but remain unlicensed because an applicable install condition is not satisfied. 11. License metric determines how rights are calculated The entitlement in alm_license references a license metric in samp_sw_license_metric. The license metric determines how many rights are required. There is no universal reconciliation formula such as 1 installation = 1 right. Different metrics can calculate demand differently, including Per User, Per Device, Per Named User, Per Named Device, Per Core, Per Processor, User Subscription, Oracle metrics, IBM metrics, SAP metrics, resource-consumption metrics, and other publisher-specific metrics. The reconciliation framework selects the appropriate license calculator based on the metric and, in some cases, the publisher/product/plugin configuration. Therefore, when the number of consumed rights looks incorrect, identify the exact samp_sw_license_metric first. Do not troubleshoot a core-based metric using assumptions from a device-based metric. 12. Reconciliation builds software-model and entitlement relationships before consuming rights Internally, reconciliation does not immediately subtract rights when it finds an entitlement. It first builds software-model coverage and candidate entitlement relationships. Conceptually: Software models → software-model relationships → candidate entitlement sets → entitlement preference → consumer eligibility → rights consumption This is necessary because one entitlement can sometimes cover multiple software models through downgrade or suite relationships, while another entitlement may cover only one specific model. The engine must make an ordered licensing decision rather than simply selecting the first entitlement returned from alm_license. 13. Entitlement applicability and entitlement consumption are different decisions This distinction is one of the most important concepts in SAM reconciliation. Entitlement applicability asks: Can this entitlement cover this software? Typical inputs include product, software model, version, edition, downgrade/upgrade rights, suite relationships, maintenance/SA, license metric, and publisher-specific rules. Entitlement consumption asks: Can this specific consumer use this applicable entitlement? Typical inputs include consumption rules, license pools, explicit allocations, organizational data, and available rights. Therefore: Entitlement exists ≠ Entitlement eligible Entitlement eligible ≠ Entitlement applicable Entitlement applicable ≠ Consumer can consume it Consumer can consume it ≠ Sufficient rights remain These are separate gates in reconciliation. 14. Consumption rules restrict who can consume an entitlement Consumption rules can restrict entitlement usage to particular consumers or organizational groups. SAM evaluates applicable rules against consumer information. Depending on configuration, rules may involve company, department, cost center, country, region, group, or other organizational criteria. If no restrictive consumption rule exists for the entitlement path, the entitlement is not rejected merely because there is no rule. If rules exist, the affected consumer must satisfy an applicable rule unless another licensing path such as an explicit allocation applies. This means an entitlement can have 1,000 unused rights and still not license a device if the device does not satisfy the entitlement's consumption restrictions. 15. License pools reserve portions of entitlement rights Consumption rules can be associated with license pools. A pool effectively reserves a portion of entitlement rights for consumers matching the associated rule. Conceptually, the reconciliation implementation separates total available entitlement rights, rights reserved by pools, and non-pool rights. A useful simplified model is: nonPoolRights = max(availableRights - totalPoolRights, 0) The consumer can then use rights from its applicable pool plus eligible non-pool rights, constrained by the entitlement's total available quantity. Example: entitlement rights = 100, total rights reserved in pools = 40, and the consumer matches a pool with 20 rights. The non-pool quantity is 60, so this consumer may have access to its 20 pool rights plus the 60 non-pool rights, subject to the remaining reconciliation conditions. The support principle is simple: total rights owned are not necessarily rights available to every consumer. 16. Explicit user and device allocations influence reconciliation Device allocations are stored in alm_entitlement_asset, where licensed_by references the entitlement in alm_license and allocated_to references the device/CI. User allocations are stored in alm_entitlement_user, where licensed_by references the entitlement in alm_license and assigned_to references the user in sys_user. Allocations are not only informational records. They establish an explicit entitlement-to-consumer relationship and are considered before general unallocated rights are consumed. When an allocated user or device is unexpectedly unlicensed, verify both sides of the relationship: the expected consumer and the expected licensed_by entitlement. 17. Allocated rights are processed before general rights For on-premise reconciliation, the implementation processes licensing through ordered passes: Allocated → Priority → Unlimited → Unallocated. For supported cloud licensing, the implementation uses Allocated → Concurrent → Unallocated. Not every specialized license calculator implements every pass. The framework skips optional passes when the calculator does not implement them. For a public troubleshooting model, the important principle is that explicit allocations are evaluated before SAM spends flexible unallocated rights. 18. Unlimited rights do not necessarily mean unrestricted use An entitlement can be configured with alm_license.unlimited_license = true. For rights-quantity purposes, unlimited entitlements are treated differently from finite entitlements. However, unlimited quantity does not automatically bypass applicability or consumer restrictions. Example: an unlimited entitlement limited by a consumption rule to Company A does not automatically license a Company B device. The correct interpretation is: Unlimited quantity removes the finite-right limit; it does not automatically remove entitlement applicability or consumer eligibility requirements. 19. Entitlement preference affects which rights are consumed When multiple entitlements can cover the same software, reconciliation uses preference/order logic rather than simply selecting the first alm_license record. The internal entitlement map can return the first consumable entitlement from an already ordered candidate set. This means "preferred" or "cheapest" entitlement selection should not be interpreted as a simple cost ASC query. The selected entitlement is a result of software-model coverage, entitlement ordering, consumer eligibility, allocation state, rights type, and available rights. This is why two technically applicable entitlements may not be consumed equally. 20. Rights availability is evaluated after applicability and consumer eligibility Once SAM has an applicable entitlement and an eligible consumer, it determines whether enough consumable rights remain. Conceptually: Applicable entitlement → Consumer eligible → Rights available → Metric calculates requirement → Rights consumed Three common outcomes are: No applicable entitlement: Entitlements may exist, but none covers the required model/version/edition/licensing relationship. Applicable entitlement but consumer not eligible: The entitlement covers the software, but a consumption restriction prevents the user/device/server from consuming it. Applicable and consumable entitlement but insufficient rights: The entitlement applies and the consumer is eligible, but the metric requires more rights than remain available. These are different root causes and should be investigated separately. 21. Licensed and unlicensed state is written back to the licensable entity For software installations, reconciliation updates cmdb_sam_sw_install. is_reconciled indicates that reconciliation processed the installation. unlicensed_install indicates whether it remains unlicensed. license_metric_result links the installation to the detailed License Metric Result, while software_model_result links it to the Software Model Result. is_allocated and allocation_needed provide allocation-related state where applicable. The most important interpretation is: is_reconciled = true and unlicensed_install = false means the installation was processed and licensed. is_reconciled = true and unlicensed_install = true means the installation was processed but remains unlicensed. Therefore: is_reconciled = true does not mean "licensed." Always evaluate is_reconciled together with unlicensed_install. 22. allocation_needed does not mean the installation is unlicensed allocation_needed and unlicensed_install answer different questions. A calculator can determine that an installation is currently covered by available rights while also indicating that an allocation is required or should be created for that licensing model. Do not use allocation_needed = true as proof that the installation is unlicensed. 23. Reconciliation creates a hierarchy of result records The reconciliation run is represented in samp_reconciliation_result. Publisher-level results are stored in samp_publisher_result, product-level results in samp_product_result, software-model results in samp_software_model_result, and detailed license-metric calculations in samp_license_metric_result. The main troubleshooting hierarchy is: samp_reconciliation_result → samp_publisher_result → samp_product_result → samp_software_model_result → samp_license_metric_result Common abbreviations are SMR = Software Model Result and LMR = License Metric Result. 24. Reconciliation Result Each reconciliation run is represented by samp_reconciliation_result. The source shows the reconciliation result storing values such as status, mode, publisher, group, subgroup, and last_reconciled depending on the run. When troubleshooting a specific run, first identify the correct samp_reconciliation_result so that downstream Publisher, Product, SMR, and LMR records are correlated to the same reconciliation execution. A run can be for all publishers or a selected set of publishers. 25. Publisher Result Publisher-level reconciliation results are stored in samp_publisher_result. The publisher result is the parent licensing view for products processed under the same publisher. It is useful when determining whether a problem is isolated to one product or affects the publisher's reconciliation more broadly. A publisher can have more than one result in some scenarios, including grouping or published-product processing. 26. Product Result Product-level reconciliation results are stored in samp_product_result. A Product Result ties a product in samp_sw_product to a reconciliation result in samp_reconciliation_result. Product-level status represents the aggregate licensing position above the underlying software-model and license-metric calculations. When a product is non-compliant, drill down to its SMRs and LMRs rather than trying to determine the cause from the Product Result alone. 27. Software Model Result Software-model reconciliation results are stored in samp_software_model_result. An SMR represents the licensing position for a specific software model in cmdb_software_product_model within the reconciliation run. A software installation can reference the related SMR through cmdb_sam_sw_install.software_model_result. The SMR is the bridge between the product-level position and one or more metric-specific LMR calculations. 28. License Metric Result Detailed metric calculations are stored in samp_license_metric_result. Important relationships include software_model, software_model_result, license_metric, reconciliation_result, publisher, and product. LMR is normally the most important result table when investigating rights calculations. Depending on the metric, relevant values can include rights owned, rights used/consumed, unused rights, rights needed, unlicensed usage, downgrade rights, maintenance/SA information, allocation information, costs, and remediation calculations. Not every license metric populates every field identically because the metric-specific calculator determines the calculation. When the question is "Why did SAM consume this many rights?", start with the applicable samp_license_metric_result. 29. Reconciliation can generate specific unlicensed reasons SAM maintains unlicensed reason definitions in samp_unlicensed_reason. The relationship between a specific licensable entity and its reason is stored in samp_entity_unlicensed_reason. Important fields include publisher, product, entity, entity_table, reason, license_metric, actionable_entity, actionable_entity_table, and install. The reason field references samp_unlicensed_reason. entity identifies the affected licensable entity, while entity_table identifies its table. actionable_entity and actionable_entity_table can identify the record that should be corrected. For software installations, the affected entity is commonly a record in cmdb_sam_sw_install. 30. Missing version can produce a specific unlicensed reason If the discovery model does not have cmdb_sam_sw_discovery_model.norm_version and relevant entitlement paths require a version, SAM can create a "No version"/missing-version unlicensed reason. In this scenario, adding more entitlement quantity does not resolve the problem because reconciliation cannot establish the required model/version applicability. The correct troubleshooting target is the discovery model and normalization result. 31. Missing edition can produce a specific unlicensed reason If cmdb_sam_sw_discovery_model.norm_edition is empty and applicable entitlement paths require an edition, SAM can generate the corresponding missing-edition reason. Again, this is primarily a normalization/applicability issue rather than an entitlement-quantity issue. 32. Install conditions can produce an unlicensed reason When an installation fails required product/software-model conditions, reconciliation can generate an install-condition-related unlicensed reason. This is separate from a consumption-rule failure. Use the distinction: Install condition failure = installation does not qualify for the licensing path. Consumption-rule failure = entitlement applies to the software, but the consumer is not allowed to consume the entitlement. 33. "No entitlements" does not always mean there are zero alm_license records SAM can generate a no-entitlement result when no usable entitlement path remains after applicability checks. Possible causes include wrong software model, version mismatch, edition mismatch, missing downgrade relationship, inactive entitlement, maintenance-only entitlement, excluded custom metric, unsatisfied licensing conditions, or genuinely absent entitlement. Therefore, never close an investigation with: "An alm_license record exists, so reconciliation is wrong." The correct question is: "Did any entitlement survive all applicability conditions?" 34. No consumable entitlement is different from no applicable entitlement The reconciliation validator also distinguishes situations where no entitlement can actually be consumed. This occurs after candidate entitlement identification and can result from consumption restrictions or other consumer-level conditions. Conceptually: No applicable entitlement = software/model licensing path failed. No consumable entitlement = entitlement may be relevant, but the current consumer cannot use it. This distinction is important when troubleshooting company/department/group-specific results. 35. Metric-specific infrastructure data can also cause unlicensed results Specialized metrics may require infrastructure information beyond software installation data. For example, server/core licensing can require CPU count, core count, host/VM topology, virtualization information, vCenter information, or cloud licensing attributes. The source contains specific unlicensed-reason logic for conditions such as missing CPU count and missing CPU core count. Therefore, for core/processor/server metrics, do not limit troubleshooting to cmdb_sam_sw_install and alm_license; verify the related CI infrastructure required by the metric calculator. 36. Reconciliation grouping can change how results are separated The reconciliation engine supports grouping and subgrouping. When explicit reconciliation parameters are supplied, the engine uses those group/subgroup values. Otherwise it uses com.snc.samp.recon.group and com.snc.samp.recon.subgroup. The resulting group and subgroup are stored on samp_reconciliation_result. If the group is none, or if group and subgroup are the same, the implementation treats the subgroup as none. Grouping matters because multiple Product Results, Software Model Results, or other licensing results can exist for the same product/model when reconciliation is separated by organizational dimensions. 37. Reconciliation execution uses an internal task queue Internal reconciliation tasks are stored in samp_recon_task_queue. Useful fields include job, entity, entity_reference, task_type, priority, upstream, downstream, status, worker, reconciliation_result, run_id, and task_parameter. upstream and downstream represent task dependencies. priority influences which eligible work is selected first. reconciliation_result associates the task with the reconciliation run, and run_id identifies tasks belonging to the same execution. Typical task sequence is conceptually: Prepare reconciliation → Prepare publisher → Product/preference processing → Publisher wrap-up → Reconciliation wrap-up Use samp_recon_task_queue when reconciliation itself is stuck, incomplete, or failed. Do not use it as the first troubleshooting step for a normal entitlement-applicability issue. 38. Reconciliation prevents overlapping processing The reconciliation entry point checks existing activity before starting another reconciliation. The source checks unfinished records in samp_recon_task_queue together with active reconciliation workers to determine whether another reconciliation is already running. This matters when a manual reconciliation appears not to start. Before investigating entitlement configuration, confirm whether another reconciliation execution is already active. For a normal licensed/unlicensed discrepancy, this runtime check is not usually relevant. 39. Reconciliation can run across configured domains If explicit domains are supplied to the reconciliation run, those domains are used. Otherwise the reconciliation entry point reads alm_domain_asset_process_setting and selects records where run_asset_process = true, using the corresponding sys_domain. In domain-separated environments, an installation or entitlement may appear valid but not participate in the expected run if its domain is outside the reconciliation scope. 40. Functional reconciliation properties com.snc.samp.recon.enablecustommetrics — Controls participation of custom license metrics. Relevant custom metric-group entitlements are excluded when this is not exactly true. com.snc.sam.auto_suite_inference — Controls relevant automatic suite inference and suite-product connectivity behavior. com.snc.samp.unlicensed_smr_creation — Controls the unlicensed Software Model Result path. The related result table is samp_software_model_result. com.snc.samp.manage.published.products — Participates in published-product reconciliation/result behavior when the corresponding SAM Workspace capability is active. com.snc.samp.recon.group — Provides the default reconciliation group when explicit reconciliation group parameters are not available. com.snc.samp.recon.subgroup — Provides the default reconciliation subgroup when explicit subgroup parameters are not available. If group and subgroup are the same, the subgroup is treated as none by the implementation. These properties can influence reconciliation scope, result organization, or functional behavior and are more relevant to licensing investigations than worker-performance properties. 41. Runtime reconciliation properties glide.sys.schedulers — Used when calculating scheduler capacity for UI/manual reconciliation workers. The implementation fallback is 2. com.snc.samp.recon.max_workers — Caps the number of reconciliation workers considered for UI/manual reconciliation. The implementation fallback is 1. For UI/manual reconciliation, the effective worker count is constrained by com.snc.samp.recon.max_workers, glide.sys.schedulers, and currently active reconciliation worker activity. Non-UI execution uses one reconciliation worker in the implementation reviewed. These are runtime/performance properties. They normally do not explain why an individual entitlement is applicable or why a specific installation is unlicensed. 42. Backend troubleshooting path for an unexpectedly unlicensed installation Start with the installation in cmdb_sam_sw_install. Confirm the expected record exists and review norm_publisher, norm_product, discovery_model, software_model, is_reconciled, unlicensed_install, inferred_suite, license_metric_result, and software_model_result. Next inspect the discovery model in cmdb_sam_sw_discovery_model and validate norm_product, norm_version, and norm_edition. Then inspect the software model in cmdb_software_product_model and confirm the product, version, edition, suite, and licensing relationships are what the entitlement expects. Inspect the expected entitlement in alm_license and validate software_model, license_metric, install_status, product_type, metric_group, rights, and unlimited_license. If downgrade licensing is expected, validate the relevant active relationship in samp_downgrade_model. If the entitlement uses consumption restrictions or pools, validate whether the affected consumer satisfies the applicable rule. If an explicit allocation is expected, validate alm_entitlement_asset for device allocations or alm_entitlement_user for user allocations. Then inspect the related calculation in samp_license_metric_result. Confirm that the correct metric and software model were used and compare owned/used/remaining/required rights as appropriate for that metric. Trace upward through samp_software_model_result, samp_product_result, samp_publisher_result, and samp_reconciliation_result to understand the complete licensing position. Finally, if the installation remains unlicensed, inspect samp_entity_unlicensed_reason and the referenced definition in samp_unlicensed_reason. Use actionable_entity and actionable_entity_table when populated to identify the record SAM expects to be corrected. 43. Backend troubleshooting path when reconciliation itself is stuck If the issue is that reconciliation does not complete rather than a specific licensing result, identify the run in samp_reconciliation_result and then inspect samp_recon_task_queue. Review status, task_type, reconciliation_result, run_id, worker, upstream, and downstream. An unfinished upstream dependency can prevent a downstream task from becoming executable. Product tasks can also be processed according to priority and domain ordering where domain separation is enabled. This is an execution-path investigation and should be separated from normal entitlement troubleshooting. 44. Example: entitlement exists but edition does not match Installation: Product X Enterprise. Entitlement: Product X Standard with 500 unused rights. alm_license.rights = 500 does not matter if the Standard software model cannot cover Enterprise. The failure occurs at entitlement applicability before available quantity becomes relevant. Troubleshooting path: cmdb_sam_sw_install → cmdb_sam_sw_discovery_model.norm_edition → cmdb_software_product_model → alm_license.software_model. 45. Example: entitlement applies but consumption rule fails Installation/device belongs to Company B. Entitlement covers the correct product/version/edition and has 500 unused rights, but its consumption rule permits Company A only. Software applicability succeeds, but consumer applicability fails. Result: those 500 rights are not automatically available to the Company B device. This is a consumption-rule issue, not a software-model issue and not an insufficient-rights issue. 46. Example: entitlement applies and consumer is eligible but rights are insufficient Required rights = 16. Remaining consumable rights = 8. The entitlement is valid, the software model is covered, and the consumer satisfies the restriction, but the metric requires more rights than remain available. This is a rights-availability problem. The detailed calculation should be investigated in samp_license_metric_result. 47. Example: newer entitlement expected to cover an older version Installed software = Product 2019 Enterprise. Entitlement = Product 2022 Enterprise. Validate whether the relevant active downgrade relationship exists in samp_downgrade_model. If it does, the 2022 entitlement can become a candidate for the 2019 software. If it does not, the customer should not assume that the newer entitlement is automatically applicable. 48. Example: explicit allocation A user allocation in alm_entitlement_user contains assigned_to = user A and licensed_by = entitlement X. Reconciliation evaluates explicit allocation before general unallocated-right consumption. If user A is unexpectedly unlicensed, confirm that the allocation references the correct entitlement and that the entitlement itself represents the expected licensing model. For device licensing, perform the equivalent validation in alm_entitlement_asset using allocated_to and licensed_by. 49. Example: custom metric does not reconcile The entitlement exists in alm_license and references a custom metric, but no expected calculation is produced. Validate the metric and then check com.snc.samp.recon.enablecustommetrics. If custom metrics are disabled, relevant custom metric-group entitlements are excluded from reconciliation processing. 50. Example: suite entitlement is not selected Confirm the installations in cmdb_sam_sw_install, normalized products, software models in cmdb_software_product_model, inferred suite fields, suite relationships, applicable suite entitlement in alm_license, consumption restrictions, and remaining rights. Also verify com.snc.sam.auto_suite_inference when automatic suite inference is expected. Do not assume that discovering all suite components automatically forces SAM to use the suite entitlement. 51. Important backend tables Software installations are stored in cmdb_sam_sw_install. Discovery models are stored in cmdb_sam_sw_discovery_model. Software products are stored in samp_sw_product. Software product models are stored in cmdb_software_product_model. Software entitlements are stored in alm_license. License metrics are stored in samp_sw_license_metric. Device allocations are stored in alm_entitlement_asset. User allocations are stored in alm_entitlement_user. Downgrade relationships are stored in samp_downgrade_model. Reconciliation runs are stored in samp_reconciliation_result. Publisher results are stored in samp_publisher_result. Product results are stored in samp_product_result. Software Model Results are stored in samp_software_model_result. License Metric Results are stored in samp_license_metric_result. SAM maintains definitions for unlicensed reasons in samp_unlicensed_reason. Entity-to-reason relationships are stored in samp_entity_unlicensed_reason. Internal reconciliation execution tasks are stored in samp_recon_task_queue. Domain participation for the asset process can be derived from alm_domain_asset_process_setting when explicit domains are not supplied. 52. Important backend fields On cmdb_sam_sw_install, useful reconciliation fields include norm_publisher, norm_product, discovery_model, software_model, is_reconciled, unlicensed_install, is_allocated, allocation_needed, license_metric_result, software_model_result, inferred_suite, and inferred_suite_product. On cmdb_sam_sw_discovery_model, the most useful normalization fields are norm_product, norm_version, and norm_edition. On alm_license, important reconciliation fields include software_model, license_metric, install_status, product_type, metric_group, rights, unlimited_license, and license_metric_result. On alm_entitlement_asset, useful allocation fields are licensed_by and allocated_to. On alm_entitlement_user, useful allocation fields are licensed_by and assigned_to. On samp_entity_unlicensed_reason, useful fields include entity, entity_table, reason, license_metric, actionable_entity, actionable_entity_table, publisher, product, and install. On samp_recon_task_queue, useful execution fields include task_type, status, reconciliation_result, run_id, worker, priority, upstream, downstream, entity, and entity_reference. 53. Principal troubleshooting rule When someone says: "The customer owns licenses, but the installation is still unlicensed." Do not start with entitlement quantity. Use this sequence: Installation exists → Normalization correct → Correct software model → Eligible entitlement → Version/edition/downgrade/suite applicable → Install conditions satisfied → Consumer allowed by consumption rule/allocation → Consumable rights remain → Correct metric calculation → Correct LMR/SMR/result → Unlicensed reason That sequence mirrors the actual reconciliation problem space much better than starting with "How many rights did the customer buy?" 54. Summary Software reconciliation should be viewed as a series of licensing gates rather than a simple entitlement count. The complete functional model is: Discovered usage in cmdb_sam_sw_install → normalized identity through cmdb_sam_sw_discovery_model → licensable definition in cmdb_software_product_model → candidate rights in alm_license → version/edition/suite/downgrade applicability → product/install conditions → consumption rules/license pools → user/device allocations → license metric calculation from samp_sw_license_metric → rights consumption → LMR in samp_license_metric_result → SMR in samp_software_model_result → Product Result in samp_product_result → Publisher Result in samp_publisher_result → reconciliation run in samp_reconciliation_result. If licensing fails, investigate samp_entity_unlicensed_reason and its referenced reason in samp_unlicensed_reason. If reconciliation execution itself fails or stalls, investigate samp_recon_task_queue. The most important principle is: Entitlement existence, entitlement eligibility, software applicability, consumer eligibility, and sufficient rights are separate decisions. Reconciliation must successfully pass the applicable stages before software can be considered licensed.