How Downgrade Rights Work in Software Asset Management (SAM) and How They Affect ReconciliationSummary<!-- /*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: ; } } Downgrade rights in Software Asset Management (SAM) allow rights owned for a later software version to license qualifying earlier versions. For example, an entitlement for Product 2025 can potentially license Product 2022 when an applicable downgrade relationship exists. Downgrade rights are not determined by comparing version numbers during reconciliation. SAM uses explicit software-model and entitlement downgrade relationships to determine which earlier software models an entitlement can cover. The high-level flow is: Content Service/manual configuration → Software-model downgrade relationships → Entitlement-specific downgrade rights → Reconciliation validates active/date-applicable rights → Downgrade models added to entitlement coverage → Applicable installations consume the entitlement → Downgrade usage appears in the License Metric Result. The most important principle is: Owning a newer software version does not by itself mean all older versions are licensed. A valid downgrade relationship must exist and the entitlement must still satisfy the normal reconciliation requirements. 1. What a downgrade right represents Assume an organization owns an entitlement for Product 2025 Enterprise but still runs Product 2022 Enterprise. Without downgrade rights, the 2025 entitlement represents Product 2025 Enterprise. With an applicable downgrade relationship, its licensing coverage can conceptually become: Product 2025 Enterprise entitlement → Product 2025 Enterprise + permitted earlier software models such as Product 2022 Enterprise. The purchased entitlement remains the 2025 entitlement in alm_license; SAM does not create a second purchased entitlement for Product 2022 merely because downgrade rights exist. 2. Downgrade rights are software-model based Software models are stored in cmdb_software_product_model. Downgrade relationships identify which other software models can be covered by the parent/newer software model or its entitlement. This is why reconciliation does not simply execute logic such as installed version < entitlement version → license it. The relationship between the software models must exist in SAM. For example, Product 2025 Enterprise and Product 2022 Enterprise are separate cmdb_software_product_model records. The downgrade relationship tells SAM whether rights associated with the 2025 model can extend to the 2022 model. 3. Three important downgrade-right data layers There are three important backend layers in the downgrade-right lifecycle. Content Service downgrade data is stored in samp_dmap_downgrade_model. Software-model downgrade relationships are stored in samp_sw_downgrade_model. Entitlement-specific downgrade rights are stored in samp_downgrade_model. A useful backend model is: Content downgrade definition samp_dmap_downgrade_model → Software-model relationship samp_sw_downgrade_model → Entitlement-specific right samp_downgrade_model → Reconciliation. These tables represent different stages and should not be treated as interchangeable. 4. How Content Service supplies downgrade rights SAM Content Service provides downgrade-right information associated with discovery-map content. The scheduled job Download software content: Downgrade Rights runs weekly and stores downloaded downgrade content in samp_dmap_downgrade_model. This table represents content-level downgrade information before it is propagated to the customer's software models and software entitlements. Therefore, if Content Service knows that a newer software version can downgrade to earlier versions, the initial backend path is: Content Service → samp_dmap_downgrade_model. 5. How content becomes software-model and entitlement downgrade rights The scheduled job SAM- Create downgrades/upgrades for a software entitlement processes the downgrade content in samp_dmap_downgrade_model. The process propagates applicable downgrade relationships to existing software models and their corresponding software entitlements. The resulting software-model relationship is represented in samp_sw_downgrade_model, while the entitlement-specific relationship used during reconciliation is represented in samp_downgrade_model. The automated lifecycle is therefore: samp_dmap_downgrade_model → samp_sw_downgrade_model → samp_downgrade_model. 6. Software models can be created while downgrade content is processed If downgrade content references a discovery map for which the required software model does not yet exist, SAM can automatically create the corresponding cmdb_software_product_model while populating samp_sw_downgrade_model. This is important when administrators see software models that they did not manually create. Software models can be generated because the Content Service hierarchy requires them for downgrade, next-version, or other software-model relationships. 7. Software-model downgrade rights Software-model downgrade relationships are stored in samp_sw_downgrade_model. Important fields used by the downgrade logic include parent_model, model, and active. The related list also exposes information such as Source. parent_model represents the software model from which downgrade coverage originates. model represents the software model that can be covered through the downgrade relationship. Conceptually: parent_model = Product 2025 Enterprise, model = Product 2022 Enterprise, active = true. The Source identifies how the relationship was created: manually created downgrade relationships use Internal, while automatically supplied relationships use ServiceNow. 8. Entitlement-specific downgrade rights Entitlement downgrade relationships are stored in samp_downgrade_model. Important fields are license, model, active, start_date, and end_date. The entitlement Downgrade Rights related list also exposes order. license references the software entitlement in alm_license. model references the downgraded software model in cmdb_software_product_model. Example: license = Product 2025 Enterprise entitlement, model = Product 2022 Enterprise software model, active = true. This is the relationship that tells reconciliation that this specific entitlement can potentially cover the older model. 9. Software-model downgrade rights and entitlement downgrade rights are different samp_sw_downgrade_model answers: Which earlier software models are related to this parent software model? samp_downgrade_model answers: Which earlier software models can this specific software entitlement cover? This distinction matters because reconciliation licenses usage using entitlements, not software-model relationships alone. A software-model relationship can exist in samp_sw_downgrade_model, but the entitlement's usable downgrade coverage is represented in samp_downgrade_model. 10. Reconciliation reads entitlement-specific downgrade rights When reconciliation builds the licensing position for an entitlement in alm_license, it queries samp_downgrade_model using the entitlement's sys_id. The base condition is: samp_downgrade_model.license = <current entitlement>. SAM then validates whether each downgrade relationship is active and valid for the current date before adding its model to that entitlement's downgrade coverage. Therefore, the existence of a software-model downgrade relationship alone does not prove that the current entitlement has usable downgrade coverage. 11. Active is mandatory for reconciliation downgrade coverage Reconciliation requires: samp_downgrade_model.active = true. An inactive entitlement downgrade relationship is not added to the entitlement's active downgrade-model list. This provides a direct way to retain historical/configuration information without making the downgrade right available during reconciliation. The functional condition is: relationship exists + active = true + date validity passes → downgrade model can participate. 12. Start date controls when the entitlement downgrade right becomes usable samp_downgrade_model.start_date can restrict when an entitlement downgrade relationship becomes effective. The reconciliation condition is: start_date is empty OR start_date <= today. Example: the downgrade relationship has start_date = 2026-10-01, but reconciliation runs on 2026-09-10. The relationship exists and may be active, but it is not yet included in the entitlement's active downgrade coverage. An empty start_date does not block the downgrade right. 13. End date controls when the entitlement downgrade right expires samp_downgrade_model.end_date can restrict how long an entitlement downgrade relationship remains effective. The reconciliation condition is: end_date is empty OR end_date >= today. Example: end_date = 2026-08-31, and reconciliation runs on 2026-09-10. The downgrade relationship is outside its validity period and is not included even if active = true. An empty end_date does not impose an expiration date. 14. Complete downgrade eligibility condition For an entitlement downgrade relationship to enter the reconciliation downgrade list, the important conditions are: license = current entitlement AND active = true AND (start_date is empty OR start_date <= today) AND (end_date is empty OR end_date >= today). Only the model values from qualifying records are added to the entitlement's downgrade coverage. This condition is one of the most important backend checks when a customer expects a newer entitlement to cover an older installation but reconciliation does not use it. 15. Deactivating a software-model downgrade right propagates to entitlement rights A software-model downgrade relationship can be deactivated instead of deleted. When an active software-model downgrade right is deactivated, the change propagates to related software-entitlement downgrade rights. The software-model downgrade relationship cannot be inactive while its dependent entitlement downgrade relationship remains active. Setting the model-level downgrade relationship back to active reactivates the corresponding downgrade relationship behavior. Therefore, when multiple entitlements unexpectedly lose downgrade coverage at the same time, inspect the parent software-model downgrade relationship in samp_sw_downgrade_model. 16. Downgrade rights normally remain as records and are deactivated instead of deleted Once downgrade rights have been created and saved in samp_sw_downgrade_model and samp_downgrade_model, they are normally managed through the active state rather than manual deletion. If a software model itself is deleted, the downgrade relationships associated with that software model in samp_sw_downgrade_model are also removed as part of software-model cleanup. This makes active an important field when investigating why a relationship that previously participated in reconciliation no longer does. 17. Changing the software model's discovery map can change downgrade relationships Software-model downgrade content can depend on the discovery map associated with the software model. If a software model is changed from one discovery map to another, SAM can remove downgrade relationships associated with the old discovery map and populate the relationships associated with the new discovery map. This can also affect corresponding entitlement downgrade rights. Generic software entitlements have special behavior: changing the software model's discovery map does not automatically change downgrade rights for an entitlement whose Agreement type is Generic. Therefore, a discovery-map change can explain why downgrade relationships changed even when nobody manually edited the Downgrade Rights related list. 18. Agreement type affects automatic entitlement downgrade-right population The Agreement type on a software entitlement can affect whether downgrade rights are automatically populated. For an entitlement with Agreement type Generic, downgrade rights are not automatically populated through this agreement-type behavior. For agreement types other than Generic, downgrade rights can be automatically populated. If an existing entitlement is changed from Generic to a supported non-Generic agreement type, applicable downgrade rights are populated. If an existing entitlement is changed from a non-Generic agreement type back to Generic, downgrade rights that were already populated are not automatically deleted or deactivated. Therefore, when two entitlements using the same software model have different downgrade-right records, compare their Agreement type as part of the investigation. 19. Downgrade rights can also be created manually Administrators can create downgrade relationships manually from the Software Model or Software Entitlement Downgrade Rights related list. A manually created software-model downgrade relationship is identified with Source = Internal, while content-provided relationships use Source = ServiceNow. Manual creation is useful for licensing rights that are contractually valid for the customer but are not represented by the standard Content Service relationship. The relationship still needs to meet normal active/date and reconciliation applicability requirements. 20. Duplicate downgrade relationships are prevented SAM prevents creation of duplicate downgrade rights through both automated and manual paths. For software-model downgrade definitions, duplicate detection considers values such as Publisher, Product, Version condition, Version, Edition condition, Edition, Platform, Language, Software install condition, and Named User Type for SAP products. If an equivalent downgrade relationship already exists, SAM prevents another duplicate from being created. If the matching relationship already exists but is inactive, the expected action is to reactivate the existing relationship rather than create another duplicate. 21. Older duplicate records are not automatically removed Instances upgraded from older SAM releases can already contain duplicate downgrade-right records. Existing historical duplicates are not automatically modified or deleted solely because newer versions prevent creation of additional duplicates. Therefore, when reviewing an upgraded environment, do not assume the database can never contain duplicate historical downgrade relationships just because current creation logic prevents new duplicates. 22. Downgrade rights can cross products for the same publisher Downgrade coverage is not limited to different versions having exactly the same product record. SAM supports cross-product downgrade relationships for software belonging to the same publisher. This supports situations where a publisher renames a product and the old and new product names are represented as separate samp_sw_product records. Example: if Publisher A renames Product Old to Product New, a downgrade relationship can be created from a Product New software model to the applicable Product Old software model. This allows reconciliation to use the newer-product entitlement against eligible usage represented under the previous product identity. 23. Cross-product downgrade rights affect product connectivity during reconciliation Reconciliation builds product connectivity from downgrade relationships when products can share licensing coverage. If Product A entitlement rights can downgrade to a model belonging to Product B, the products can become connected for the applicable license metric so the engine can evaluate their licensing demand together. This prevents reconciliation from treating two products as completely independent when the same entitlement can legally cover both. Only products participating in the current reconciliation product set are grouped through that connected downgrade relationship. 24. Downgrade breadth also participates in reconciliation processing order When reconciliation sorts connected product/license-metric groups, it considers suite hierarchy, number of connected products, number of downgrade targets, and license-metric rank. Where the earlier sort criteria are equal, fewer downgrade targets are processed before a group with broader downgrade coverage. The reason is that a more specific entitlement path has fewer alternative models it can cover, while a broader downgrade entitlement is more flexible. This ordering helps preserve flexible rights for software that may need them later in the calculation. 25. Downgrade relationships become part of the entitlement set When reconciliation processes an eligible entitlement in alm_license, it builds an entitlement-set representation containing the entitlement's primary software_model and its valid downgradeModels. Conceptually: Entitlement primary model = Product 2025 EnterpriseDowngrade models = Product 2022 Enterprise, Product 2019 Enterprise The entitlement can then become a candidate not only for its primary software model but also for software-model combinations that fall within its valid downgrade coverage. 26. The software-model tree and entitlement map use downgrade coverage Reconciliation constructs a software-model tree and an entitlement map before consuming rights. The entitlement map represents the relationship between software-model demand and entitlement sets. A downgrade-capable entitlement is represented with its primary software model as the parent and applicable downgrade software models as children. Conceptually: Entitlement E1 → Model 2025 → downgrade child Model 2022 → downgrade child Model 2019 This allows installations associated with an older software model to retrieve E1 as a potential licensing entitlement even though alm_license.software_model references the newer model. 27. The installation remains associated with its actual software model A Product 2022 installation does not become a Product 2025 installation because it consumes Product 2025 downgrade rights. The software installation remains associated with its actual licensable software model in cmdb_sam_sw_install.software_model. The entitlement can reference Product 2025 while the licensed installation's software_model remains Product 2022. Downgrade rights connect those different software models for licensing purposes; they do not rewrite the discovered software identity. 28. Downgrade rights expand applicability; they do not bypass other entitlement checks A downgrade relationship answers only the software-model coverage question. The entitlement must still pass normal reconciliation requirements such as valid status, applicable license metric, product type, consumption rules, allocations where applicable, grouping restrictions, and available rights. Therefore: Downgrade relationship exists ≠ installation automatically licensed. A more complete sequence is: Downgrade model covered → Entitlement otherwise applicable → Consumer eligible → Rights available → License metric requirement calculated → Rights consumed. 29. Consumption rules still apply to downgrade rights Assume a Product 2025 entitlement can downgrade to Product 2022 but has a consumption rule restricting it to Company A. A Product 2022 installation for Company B does not automatically receive the Product 2025 rights merely because samp_downgrade_model contains the Product 2022 model. The downgrade relationship makes the entitlement a software-model candidate. Consumption eligibility is evaluated separately. This is the same important SAM distinction used elsewhere: software applicability and consumer applicability are separate decisions. 30. Allocations still apply to downgrade-enabled entitlements User allocations are stored in alm_entitlement_user, and device allocations are stored in alm_entitlement_asset. If the license metric supports allocations, an allocation can influence consumption of an entitlement that also has downgrade rights. The downgrade relationship extends which software model can use the entitlement; the allocation identifies which consumer is explicitly associated with that entitlement. These are independent dimensions of the licensing calculation. 31. Available rights still limit downgrade consumption Suppose a Product 2025 entitlement has 10 rights and valid downgrade coverage for Product 2022. If all 10 rights have already been consumed, the existence of the downgrade relationship does not create additional rights. A Product 2022 installation can still remain unlicensed because the entitlement has no consumable rights remaining. Therefore: Downgrade rights extend coverage, not quantity. 32. One right is not always one installation Downgrade rights do not change how the license metric calculates consumption. If the entitlement uses Per Device, Per User, Per Core, Per Processor, or another metric, the corresponding license calculator still determines the required number of rights. Example: a Product 2025 Per Core entitlement can downgrade to Product 2022, but the Product 2022 server still consumes rights according to the Per Core calculation rather than consuming one right simply because downgrade coverage exists. Always identify alm_license.license_metric before evaluating the expected quantity. 33. Some license metrics do not support downgrade rights Downgrade rights are not supported for the User Subscription license metric regardless of metric group. They are also not available for these metric-group/license-metric combinations: SAP → Engine Measurement and Named User; Consumption → SaaS Consumption; Concurrent Licenses → Floating, Token, and Network. Therefore, adding or expecting downgrade relationships for these unsupported metrics does not provide the normal downgrade-right reconciliation behavior. When downgrade rights appear absent for an entitlement, validate the license metric before investigating the relationship tables. 34. Downgrade rights and Software Assurance are separate attributes Software Assurance/maintenance information and downgrade relationships are separate licensing attributes in reconciliation. When SAM builds an entitlement set, it evaluates maintenance/Software Assurance state separately from the valid downgrade-model list. The License Metric Result also stores these separately as maintenance and downgrade_rights. Do not interpret maintenance = true as proof that a particular downgraded software model is automatically covered. The actual applicable downgrade models are determined from the downgrade relationships. 35. Downgrade rights influence License Metric Result grouping Detailed reconciliation calculations are stored in samp_license_metric_result. When SAM creates entitlement sets for an LMR, the active/date-valid downgrade model list is one of the attributes used to group entitlements. Other grouping attributes include maintenance/SA state, unlimited licensing, consumption restrictions, legacy-license state, and reconciliation group/subgroup. This means two entitlements with the same primary software model and license metric are not necessarily treated as one identical entitlement set when their downgrade coverage differs. Their licensing flexibility is different, so the downgrade model set forms part of the calculation identity. 36. Downgrade rights are written to the License Metric Result The applicable downgrade list is written to samp_license_metric_result.downgrade_rights. Therefore, after reconciliation, the LMR provides a backend view of which previous software models/versions are available through that entitlement-set calculation. The entitlement itself is also associated to its generated LMR through alm_license.license_metric_result. A useful result trace is: alm_license → samp_license_metric_result → downgrade_rights. 37. LMR downgrade rights should reflect valid relationships for that run When the LMR attributes are built, SAM collects downgrade records that satisfy: license = entitlement, active = true, valid start_date, and valid end_date. The resulting model list becomes the downgrade coverage represented by that entitlement set. Therefore, a row in samp_downgrade_model that is inactive, not yet effective, or expired should not be expected in the active LMR downgrade-right list. 38. Reconciliation tracks how downgrade rights are used As rights are consumed, reconciliation tracks when the software model being licensed is one of the entitlement set's downgrade models. For each downgrade model, SAM tracks licensing usage such as allocated rights in use, allocated rights not in use, non-allocated rights in use, installation count, and allocations needed where applicable. This provides the basis for showing not only that an entitlement has downgrade rights, but also which older software models actually consumed those rights. 39. Downgrade usage remains tied to the LMR and older software model The downgrade usage calculation is keyed by the entitlement-set License Metric Result and the downgraded software model. Conceptually: LMR for Product 2025 entitlement→ Product 2022 model: rights used = X→ Product 2019 model: rights used = Y This allows the overall LMR to represent the purchased/newer licensing position while retaining visibility into which downgraded models used those rights. 40. Installation count for downgrade usage comes from actual licensed installations When calculating downgrade usage, SAM counts cmdb_sam_sw_install records associated with the applicable license_metric_result and the specific downgraded software_model. Therefore, the downgrade usage calculation is based on the installations actually licensed through that LMR/model combination rather than only on the existence of downgrade relationship records. 41. Editionless licensing is handled separately The reconciliation implementation distinguishes normal downgrade usage from certain editionless-rights scenarios. When rights have been applied through an editionless licensing path, SAM avoids automatically counting the same usage as ordinary downgrade-right usage. This prevents the same licensing event from being represented incorrectly as both an editionless-rights use and a downgrade-right use. When analyzing advanced cases involving an entitlement without a specific edition, review the actual LMR and software-model calculation rather than assuming every older-version installation is counted as downgrade usage. 42. Exact-model and downgrade-model entitlement paths can coexist An older installation may have both an exact-model entitlement and a newer entitlement that can downgrade to it. Example: Installation = Product 2022Entitlement A = Product 2022Entitlement B = Product 2025 with downgrade rights to Product 2022 Both can potentially be licensing candidates. SAM builds its entitlement map and applies entitlement preference/rights logic rather than assuming that the newer downgrade-enabled entitlement must always be consumed. This protects more flexible rights from being unnecessarily consumed when a more specific entitlement can license the software. 43. Downgrade rights can connect multiple versions and products Consider these models: Product 2025 EnterpriseProduct 2022 EnterpriseProduct 2019 Enterprise If the Product 2025 entitlement has valid downgrade relationships to 2022 and 2019, its entitlement set can potentially cover all three models. If Product 2022 also has a separate exact entitlement, SAM now has overlapping licensing options. Reconciliation considers those relationships as part of its entitlement-selection process. This is why downgrade rights affect more than the final display of "Downgrade rights"; they change the entitlement graph used to calculate compliance. 44. Example: newer entitlement successfully covers older software Installation: Product 2022 Enterprise in cmdb_sam_sw_install. Installation software model: Product 2022 Enterprise in cmdb_software_product_model. Entitlement: Product 2025 Enterprise in alm_license. Downgrade record: samp_downgrade_model.license = Product 2025 entitlement, model = Product 2022 Enterprise, active = true, with the current date within start_date/end_date when those values are populated. SAM adds Product 2022 to the entitlement's downgrade coverage. If the entitlement passes normal consumption restrictions and has sufficient rights, the Product 2022 installation can consume Product 2025 entitlement rights. 45. Example: relationship exists but is inactive Installation = Product 2022. Entitlement = Product 2025. A samp_downgrade_model record exists from the Product 2025 entitlement to Product 2022, but active = false. Reconciliation requires active = true, so Product 2022 is not added to this entitlement's active downgrade list. The existence of the relationship in the database does not make it usable. 46. Example: downgrade right has not started yet The samp_downgrade_model record contains start_date = 2026-10-01. Reconciliation runs on 2026-09-10. The condition start_date <= today fails. The downgrade right does not participate in this reconciliation even if active = true. 47. Example: downgrade right has expired The samp_downgrade_model record contains end_date = 2026-08-31. Reconciliation runs on 2026-09-10. The condition end_date >= today fails. The relationship remains in the database for history/configuration purposes but does not participate in the current downgrade coverage. 48. Example: software-model relationship exists but entitlement relationship does not samp_sw_downgrade_model shows Product 2025 → Product 2022, but the expected entitlement does not have a corresponding usable relationship in samp_downgrade_model. The software-model hierarchy demonstrates that downgrade content exists, but reconciliation still needs entitlement-specific coverage for the entitlement being evaluated. Check why the entitlement relationship was not propagated or created rather than assuming samp_sw_downgrade_model alone licenses the installation. 49. Example: entitlement has downgrade coverage but consumption rule fails Product 2025 entitlement can downgrade to Product 2022 and has 100 available rights. The entitlement consumption rule allows Company A. The Product 2022 installation belongs to Company B. The software-model downgrade applicability succeeds, but consumer eligibility fails. The 100 rights are therefore not automatically available to the Company B installation. 50. Example: downgrade relationship works but rights are exhausted Product 2025 entitlement can downgrade to Product 2022. The relationship is active and date-valid, and the consumer satisfies all restrictions. However, no consumable rights remain. The Product 2022 installation can still remain unlicensed because downgrade coverage does not create additional license quantity. 51. Example: cross-product downgrade Publisher A previously sold Product Old and now sells the equivalent licensing product as Product New. The two names exist as separate products/software models in SAM. A cross-product downgrade relationship can allow the Product New entitlement to cover an eligible Product Old software model when both products belong to the same publisher and the relationship is configured. This allows SAM to represent publisher product-name changes without requiring the older software usage to be artificially normalized to the new product name. 52. Backend investigation sequence Start with the installation in cmdb_sam_sw_install and identify its software_model, license_metric_result, is_reconciled, and unlicensed_install. Identify the installation software model in cmdb_software_product_model and confirm the expected product/version/edition. Identify the newer entitlement in alm_license and validate software_model, license_metric, install_status, product_type, available rights, and license_metric_result. Check the parent/software-model downgrade relationship in samp_sw_downgrade_model. Validate parent_model, model, active, and Source where applicable. Check the entitlement-specific relationship in samp_downgrade_model. Validate license, model, active, start_date, and end_date. Apply the exact reconciliation validity check: active = true AND (start_date empty OR start_date <= today) AND (end_date empty OR end_date >= today). Confirm that the entitlement's license metric supports downgrade rights. If the entitlement has consumption restrictions, validate whether the installation's consumer satisfies them. If allocation is relevant, inspect alm_entitlement_user or alm_entitlement_asset. Finally, inspect samp_license_metric_result.downgrade_rights and confirm whether the expected older software model appears in the LMR generated for the entitlement. This sequence distinguishes a downgrade-relationship problem from an entitlement-eligibility, consumption-rule, rights-quantity, or license-metric problem. 53. Important backend tables Content-level downgrade definitions are stored in samp_dmap_downgrade_model. Software-model downgrade relationships are stored in samp_sw_downgrade_model. Entitlement-specific downgrade relationships are stored in samp_downgrade_model. Software models are stored in cmdb_software_product_model. Software products are stored in samp_sw_product. Software entitlements are stored in alm_license. Software installations are stored in cmdb_sam_sw_install. License metrics are stored in samp_sw_license_metric. Detailed reconciliation calculations are stored in samp_license_metric_result. User allocations are stored in alm_entitlement_user, and device allocations are stored in alm_entitlement_asset. 54. Important backend fields On samp_sw_downgrade_model, important fields include parent_model, model, active, and Source. On samp_downgrade_model, important fields are license, model, active, start_date, end_date, and order. On alm_license, important fields include software_model, license_metric, install_status, product_type, rights, maintenance, agreement_type, and license_metric_result. On cmdb_sam_sw_install, useful fields are software_model, license_metric_result, software_model_result, is_reconciled, and unlicensed_install. On samp_license_metric_result, the important downgrade field is downgrade_rights; the LMR also contains the rights and consumption values produced by the applicable license metric calculation. 55. Important configuration and conditions There is no separate global downgrade-right switch required by the reconciliation logic described here. Downgrade participation is driven primarily by the software-model/entitlement relationships, their active/date validity, entitlement configuration, and supported license metric. The most important runtime condition is: samp_downgrade_model.active = true AND (start_date empty OR start_date <= today) AND (end_date empty OR end_date >= today). Agreement type can affect automatic generation of entitlement downgrade rights: Generic does not automatically populate them through the agreement-type behavior; supported non-Generic agreement types can. The entitlement's license metric must also support downgrade-right processing. 56. Compact backend flow SAM Content Service → samp_dmap_downgrade_model → software-model downgrade relationship samp_sw_downgrade_model → entitlement-specific relationship samp_downgrade_model → validate active + start_date + end_date → build entitlement downgrade-model list → include downgrade models in entitlement map → evaluate installation cmdb_sam_sw_install → apply entitlement/consumer/rights rules → consume newer entitlement against eligible older model → write samp_license_metric_result.downgrade_rights and downgrade usage → calculate final compliance. 57. Key points to remember Downgrade rights allow a newer entitlement to license eligible older software; they do not change the actual discovered software version. Downgrade coverage is relationship-driven, not based on a simple version-number comparison. Content downgrade data enters through samp_dmap_downgrade_model. Software-model downgrade relationships are stored in samp_sw_downgrade_model. Entitlement-specific downgrade rights used by reconciliation are stored in samp_downgrade_model. The key entitlement downgrade fields are license, model, active, start_date, and end_date. Reconciliation requires active = true, a valid start date, and a valid end date. Empty start/end dates do not block the relationship. Deactivating a software-model downgrade right propagates to related entitlement downgrade rights. Manual and Content Service downgrade relationships can both exist; software-model Source identifies Internal versus ServiceNow origin. Duplicate downgrade relationships are prevented, but historical duplicates from older releases can remain. Cross-product downgrade relationships are supported for products belonging to the same publisher. Downgrade rights expand entitlement applicability; they do not increase purchased rights. Consumption rules, allocations, grouping, available rights, and license-metric calculations still apply. Software Assurance/maintenance and downgrade rights are separate reconciliation attributes. Not every license metric supports downgrade rights. Active/date-valid downgrade models become part of the entitlement set used by the reconciliation entitlement map. The applicable downgrade model list is written to samp_license_metric_result.downgrade_rights. A newer entitlement and an exact older-version entitlement can both be candidates; SAM applies its entitlement preference logic rather than automatically spending the newer flexible entitlement. The correct investigation path is cmdb_sam_sw_install → cmdb_software_product_model → alm_license → samp_sw_downgrade_model → samp_downgrade_model → samp_license_metric_result. Summary Downgrade rights are not a simple rule that says a newer software license can always cover every older version. SAM represents downgrade coverage explicitly at the software-model and entitlement levels. Content Service downgrade information enters samp_dmap_downgrade_model, is propagated into software-model relationships in samp_sw_downgrade_model, and creates entitlement-specific downgrade coverage in samp_downgrade_model. During reconciliation, SAM reads the entitlement-specific relationships and includes only records where active = true, the start date is empty or effective, and the end date is empty or has not expired. The qualifying downgrade models become part of the entitlement set used by the reconciliation entitlement map. This allows an entitlement whose primary software_model is a newer version to become a candidate for installations associated with eligible older software models. Downgrade applicability is only one stage of licensing. The entitlement must still pass normal eligibility, consumption restrictions, allocations where applicable, available-rights checks, and the actual license-metric calculation. The calculated downgrade coverage is represented in samp_license_metric_result.downgrade_rights, and reconciliation tracks usage against the older software models licensed through those rights. The complete mental model is: Newer entitlement exists → Downgrade relationship exists → Entitlement-specific relationship is active and date-valid → Older software model enters entitlement coverage → Consumer is eligible → Sufficient rights exist → License metric calculates required rights → Rights are consumed → Downgrade usage contributes to the final compliance result.