How Software Suite Inference Works in Software Asset Management (SAM)Summary<!-- /*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 suite inference in Software Asset Management (SAM) determines whether discovered software installations or software subscriptions should be treated as individual products or as components of a software suite. When multiple suites can cover the same software, SAM evaluates the suite structure, qualifying components, mandatory requirements, inference configuration, software-model conditions, entitlement context, downgrade relationships, allocations, and candidate preference before selecting the licensing option. Example: Word, Excel, PowerPoint, Outlook, and Access can exist as individual products but can also belong to Microsoft Office suites. SAM must determine whether those components should remain individually licensable or participate in an Office suite licensing path. The high-level flow is: Software models → Suite parent/child relationships → Entitlements → Installations/subscriptions grouped by consumer → Qualifying components → Mandatory requirements → Inference criteria → Candidate suites → Candidate preference → inferred_suite/licensing options → Reconciliation consumes applicable rights. Suite inference does not itself consume a license. It establishes which suite or component software-model options reconciliation can subsequently evaluate against entitlement rights. 1. How a software suite is represented Software models are stored in cmdb_software_product_model; suite parent-child relationships are stored in cmdb_m2m_suite_model. On cmdb_m2m_suite_model, suite_parent references the parent suite software model, suite_child references the component software model, and mandatory defines how that component participates in suite validation. Example: Office Professional → Word, Office Professional → Excel, and Office Professional → PowerPoint are separate cmdb_m2m_suite_model relationships. A component can belong to multiple parent suites. Word, for example, can participate in both Office Standard and Office Professional. SAM therefore evaluates all eligible suite candidates instead of simply using the first suite_parent. 2. Suites can contain other suites A suite_child can itself be a suite, allowing hierarchical structures such as Suite A → Suite B → Component C. SAM builds a graph/tree from cmdb_m2m_suite_model and recursively evaluates descendants. The suite engine also detects cycles so invalid relationships such as Suite A → Suite B → Suite A do not create an endless hierarchy. This hierarchy matters because qualifying software can exist several levels below the final candidate suite. 3. Suite inference configuration Inference configuration is stored on the parent software model in cmdb_software_product_model. Important fields are inference_option, inference_number, inference, product, and apply_to_subscriptions. inference_option determines whether Number or Percent logic is used. If inference_option is empty, the suite engine defaults it to number. inference_number stores the required component count for Number-based inference. inference stores the required percentage for Percent-based inference. apply_to_subscriptions controls whether the software model participates in applicable subscription-suite processing. The configuration model is therefore: suite settings on cmdb_software_product_model + parent/child definitions on cmdb_m2m_suite_model. 4. Mandatory component types The mandatory field on cmdb_m2m_suite_model supports three behaviors: 0 = Optional, 1 = Always Mandatory, and 2 = Mandatory Group. Optional means the component does not independently have to exist for the suite definition to remain valid. Always Mandatory means that component must be present for normal component-based inference. Mandatory Group means at least one component belonging to the Mandatory Group must be present. The Number/Percent threshold and mandatory validation are separate. A candidate can meet the required component count but still fail because an Always Mandatory component is missing. 5. Always Mandatory example Assume Office Professional contains Access, Word, Excel, PowerPoint, and Outlook, with inference_number = 3, and Access is Always Mandatory. Word + Excel + PowerPoint gives three components but does not satisfy the suite because Access is missing. Access + Word + Excel gives three components and satisfies the Always Mandatory requirement. The decision is therefore not only component count >= 3; mandatory requirements must also pass. 6. Mandatory Group example Assume Word and Excel participate in a Mandatory Group. If Word is present, the group requirement can be satisfied. If Excel is present, it can also be satisfied. If neither is present, the group requirement fails even when other optional components exist. The suite engine explicitly tracks whether a Mandatory Group exists and whether at least one valid child satisfies that group. 7. Number-based inference When cmdb_software_product_model.inference_option = number, SAM compares the number of qualifying components with inference_number. The effective condition is: qualifying component count >= inference_number. Example: a suite defines five components and inference_number = 3. If three qualifying components are available for the consumer and mandatory requirements are satisfied, the candidate meets the Number threshold. If inference_number is empty, the suite engine reads it as 0. 8. Percent-based inference When cmdb_software_product_model.inference_option = percent, SAM compares the percentage of qualifying components with the backend field inference. Conceptually: actual percentage = qualifying components / defined components × 100. The condition is: actual percentage >= inference. Example: four components are defined and three qualify. The actual percentage is 75%. If inference = 75, the candidate meets the percentage threshold. If inference is empty, the suite engine reads it as 0. 9. Automatic suite inference property The suite engine reads com.snc.sam.auto_suite_inference and enables automatic-inference behavior when the property value is exactly true. When this mode is enabled, the current suite engine does not use Number/Percent to reject a candidate on efficiency; the efficiency check returns true and candidate selection is driven by the broader suite candidate and preference logic. This property also affects candidate construction, ranking, subscription suite behavior, and subscription-to-install roll-up. Because it changes the inference path materially, com.snc.sam.auto_suite_inference is an important backend value to capture when comparing different suite-inference outcomes. 10. Number/Percent is not the complete decision Suite inference is not simply number of installed components >= inference_number. SAM also evaluates the suite hierarchy, mandatory components, discovery/software-model mapping, software-model and product conditions, entitlements, downgrade coverage, consumer eligibility, allocations, direct suite installations, and competing candidate suites. Changing inference_number or inference without understanding those additional conditions can therefore produce unexpected licensing results. 11. Direct installation of the suite If an installation maps directly to the suite software model itself, the install suite engine treats the candidate as directly installed. A directly installed suite is marked valid and efficient without requiring the normal component Number/Percent threshold. It also receives hasDirectInstall = true internally for candidate comparison. Therefore: component-inferred suite → normal component validation; directly discovered suite → direct-suite path. This explains why two devices with similar components can produce different suite results when one also has the suite product itself discovered. 12. Install and subscription suite inference are separate SAM has separate suite-processing paths for software installations and software subscriptions. Install suite inference operates on cmdb_sam_sw_install, uses installed_on as the consumer relationship, and evaluates software per device. Subscription suite inference operates on samp_sw_subscription, uses the user as the consumer, and evaluates subscription software per user. The reconciliation engine contains separate tasks for allocated subscription suite inference, unallocated subscription suite inference, allocated install suite inference, and unallocated install suite inference. 13. Install suite inference is device-centric For software installations, SAM groups qualifying cmdb_sam_sw_install records by installed_on. Example: Device A has Word, Excel, and PowerPoint. Device B has only Word. The components on Device A do not help Device B meet a suite threshold. The suite candidate is evaluated against the software found on the relevant device. 14. Installations eligible for suite inference The install suite engine filters cmdb_sam_sw_install using: is_reconciled = false, omit_from_suites = false, inferred_suite_level = 0, and norm_publisher = <publisher being processed>. Applicable install conditions are added to the same query when present. An installation can therefore exist in cmdb_sam_sw_install but never enter the suite candidate calculation because it fails one of these initial conditions. Useful fields for backend review are installed_on, discovery_model, norm_publisher, norm_product, is_reconciled, omit_from_suites, inferred_suite, inferred_suite_product, inferred_suite_level, and inference_calculated. 15. Omit from suites The Omit from suites field is stored in cmdb_sam_sw_install.omit_from_suites. When it is true, that software installation is excluded from component-based suite inference. The suite engine directly enforces this with: omit_from_suites = false. If a component is visible on a device but appears not to contribute to suite inference, omit_from_suites is one of the first backend fields to verify. 16. Discovery-model mapping determines which component the installation represents Install suite inference starts from cmdb_sam_sw_install.discovery_model. Suite relationships are defined between software models in cmdb_m2m_suite_model, so SAM maps the installation's discovery model to the software models that a suite node can cover. This makes normalization and discovery-model mapping prerequisites for correct suite inference. An application can physically exist on the device but fail to contribute to the expected suite if its discovery model does not map to the expected software model. 17. Software-model conditions can filter components Each suite node can have software-model conditions. The suite engine applies those conditions before deciding which installations/subscriptions match that node. For a suite node, conditions can also be applied to entities returned from child nodes before those entities contribute to the parent candidate. Therefore, a relationship in cmdb_m2m_suite_model does not guarantee that every installation mapped to that child contributes to the parent suite; the entity must also satisfy applicable software-model conditions. 18. Product conditions can also affect suite inference Product-level install or subscription conditions can further restrict which entities qualify for a suite licensing path. For software installations, applicable conditions are applied against cmdb_sam_sw_install. For subscriptions, equivalent subscription conditions can filter samp_sw_subscription. A useful distinction is: suite relationship identifies structural membership; conditions determine whether the actual entity participates in that licensing path. 19. Entitlements influence suite candidates Software entitlements are stored in alm_license, and suite candidate construction is entitlement-aware. For subscription suite inference, SAM queries alm_license with conditions including install_status = 1, product_type NOT IN <maintenance license types>, license_metric = User Subscription, software_model.manufacturer = <publisher>, and software_model IS NOT NULL. Software models from qualifying User Subscription entitlements can become subscription candidates. cmdb_software_product_model.apply_to_subscriptions further determines normal subscription-suite applicability. Therefore: suite relationship exists ≠ suite automatically becomes a licensable candidate. 20. Subscription suite candidates For the normal subscription-suite path, an entitlement-backed software model becomes a suite candidate when its software model is applicable to subscriptions through cmdb_software_product_model.apply_to_subscriptions. When com.snc.sam.auto_suite_inference = true, the engine can additionally consider suite children associated with entitlement-backed software models when building subscription candidates. This allows subscription inference to evaluate component and suite relationships using the entitlement-backed suite graph rather than only exact parent models. 21. Subscription records are evaluated per user Subscription records are stored in samp_sw_subscription. The unallocated subscription path groups records using user_principal_name, while the suite engine's consumer model uses user. Relevant subscription fields include publisher, product, software_model, user, user_principal_name, assigned_software, inferred_suite, inferred_suite_product, inferred_suite_level, licensable_software_model, and licensable_software_model_source. This means subscription suite inference is based on the subscription set associated with the relevant user rather than subscriptions globally across the organization. 22. Allocated subscription processing User entitlement allocations are stored in alm_entitlement_user, where licensed_by references the entitlement and assigned_to references the user. Allocated subscription suite processing occurs before general unallocated subscription suite inference. An explicit User Subscription allocation can therefore influence the software-model or suite licensing option selected for a user before the remaining subscriptions are processed. 23. Allocated install processing Install suite processing also has an allocated pass before the unallocated install path. This allows explicit licensing relationships to influence suite licensing before general candidate inference is applied to remaining installations. For user allocations inspect alm_entitlement_user; for device allocations inspect alm_entitlement_asset. 24. Downgrade relationships expand suite coverage Suite candidate coverage can be expanded through downgrade relationships. Entitlement-derived downgrade relationships are stored in samp_downgrade_model; software-model/content downgrade relationships are stored in samp_sw_downgrade_model. The suite engine considers active downgrade relationships when determining which software models a suite node can cover. Therefore, an installation does not always need to map to an exact suite-child software model if a valid downgrade relationship extends that candidate's coverage. 25. Suite relationship and downgrade relationship are different Suite membership is stored in cmdb_m2m_suite_model. Downgrade coverage is represented through samp_downgrade_model and samp_sw_downgrade_model. A suite relationship answers: Is this software model a component of this parent suite? A downgrade relationship answers: Can this software model or entitlement cover another version/model? Both can affect a suite candidate, but they solve different licensing questions. 26. How a candidate is validated For each consumer, SAM maps entities to possible suite candidates and recursively validates each candidate. A normal suite candidate becomes structurally valid when qualifying child components exist, all Always Mandatory requirements are satisfied, at least one Mandatory Group member is present when a Mandatory Group exists, and applicable conditions leave qualifying entities. The candidate's efficiency is then calculated using Number or Percent logic unless automatic suite inference is enabled. Conceptually: Entity maps to component → Child candidate valid → Mandatory requirements pass → Conditions pass → Number/Percent efficiency evaluated → Candidate available for preference. 27. Valid and efficient are separate states Internally, a candidate can be valid but not efficient. Example: a suite has valid qualifying components and satisfies mandatory requirements, but only 50% of its components are present while inference = 100. The candidate is structurally valid but isEfficient = false. This separation allows the engine to compare multiple possible licensing options instead of reducing every suite to a single yes/no flag. 28. Candidate preference When multiple valid candidates exist, SAM sorts them before selecting the top preference. The base candidate comparison considers whether the candidate comes from a subscription fallback, whether the software model has applicable conditions, whether the candidate is efficient, how many entities it covers, direct suite installation where applicable, downgrade breadth, suite hierarchy height, and the percentage of components present. For install inference, a candidate covering more qualifying installations is preferred over another candidate at the same earlier preference levels. When other relevant factors tie, fewer downgrade children and component coverage percentage are also used to differentiate candidates. When com.snc.sam.auto_suite_inference = true, additional preference behavior applies, including hierarchy considerations and Microsoft-specific metric/CI-class handling. The important result is: a component can belong to several suites, but SAM ranks the complete candidates and selects the highest-preference licensing option. 29. Microsoft-specific candidate handling When automatic suite inference is enabled for Microsoft install processing, the candidate comparison can consider whether the suite's active entitlement metrics match the consumer's CI class. The suite node obtains active entitlement metrics from alm_license using conditions including software_model = <candidate>, install_status = 1, metric_group != <custom metric group>, product_type NOT IN <maintenance license types>, and license_metric IS NOT NULL. This prevents an otherwise valid Microsoft suite option from automatically being preferred when its licensing metric is inappropriate for the type of CI being evaluated. 30. Install candidates can use subscription-backed options as fallback Install inference can encounter candidates sourced from subscription entitlement relationships. When install candidates are sorted, subscription-sourced candidates are placed after equivalent install-sourced candidates so they act as fallback options rather than overriding normal installation licensing options. This distinction is represented internally on the candidate and later through the licensing-option preference data. 31. Alternative installation licensing options When one installation can participate in multiple valid licensing options, alternatives are stored in samp_install_license_options. Important fields include install, software_model, product, preference_rank, and preference_source. These records are particularly useful when cmdb_sam_sw_install.inferred_suite shows the preferred suite but an administrator needs to understand which other software models were considered. 32. Alternative subscription licensing options Alternative subscription licensing options are stored in samp_saas_license_options. Important fields include subscription, software_model, product, preference_rank, and preference_source. The engine can use these preference records later when connected products and reconciliation options are evaluated. 33. Subscription candidate preference differs from install preference When automatic inference is enabled, subscription processing initially prefers lower-height component candidates and candidates covering fewer subscription entities before the common preference logic is applied. The subscription engine then performs a consumer roll-up. If a suite becomes the top licensing option for one of the user's subscriptions, that consumed suite can be promoted across the other subscriptions it covers for that same user. This allows a broader subscription suite, such as a suite-of-suites, to become the consistent licensing option across related component subscriptions for the same consumer. 34. Subscription-to-install synchronization Subscription suite processing can also associate the selected subscription software-model preference with matching software installations for the same user. The engine identifies the relevant software model, obtains its install conditions, finds matching users, and then queries cmdb_sam_sw_install using the normal inferrable-install conditions plus the relevant user and descendant discovery models. This prevents subsequent install-suite processing from treating subscription-covered software as an unrelated independent option. The installation still has to satisfy the suite engine's install eligibility and model conditions. 35. What is stamped on software installations Install inference updates cmdb_sam_sw_install. When a suite is selected, the engine can set inferred_suite = <suite software model> and inferred_suite_product = <suite product>. It also sets inferred_suite_level = <candidate hierarchy height> and inference_calculated = true. The engine avoids restamping inferred_suite when the installation's normalized product is already the same as the candidate product, but still updates inference level/state. Useful fields for backend analysis are discovery_model, installed_on, norm_product, omit_from_suites, inferred_suite, inferred_suite_product, inferred_suite_level, and inference_calculated. 36. What is stamped on subscriptions Subscription suite inference updates samp_sw_subscription. Important fields include inferred_suite, inferred_suite_product, inferred_suite_level, licensable_software_model, and licensable_software_model_source. When the suite engine determines the licensable software model, licensable_software_model_source can identify that suite inference supplied the model. 37. inferred_suite is not proof that rights were consumed inferred_suite identifies the suite software-model option selected for the software usage. It does not prove that an entitlement has already licensed that entity. After suite inference, reconciliation still has to evaluate the selected software model against applicable alm_license records, entitlement restrictions, allocations, license metric calculation, and available rights. The correct mental model is: suite inference selects the licensing option; reconciliation determines whether that option can actually be licensed. 38. Suite parent licensing versus component licensing When a suite parent becomes the selected licensing path and applicable suite rights are available, qualifying components can participate in the suite licensing position instead of independently consuming separate component rights. However, component entitlements can still remain valid alternative options. Explicit allocations and supported component-license optimization can also influence whether an individual component or suite entitlement is ultimately consumed. 39. Component-license optimization for Microsoft suites The setting Use component licenses to optimize compliance when suite licenses run out applies to supported Microsoft license metrics and is disabled by default. When enabled, component and suite rights can both participate in compliance optimization rather than treating the inferred suite as the only licensing option. This setting is separate from com.snc.sam.auto_suite_inference; the first controls supported Microsoft suite/component license optimization, while com.snc.sam.auto_suite_inference controls the suite engine's automatic inference path. 40. Suite-specific unlicensed reasons SAM stores unlicensed reason definitions in samp_unlicensed_reason and associates a reason with a licensable entity through samp_entity_unlicensed_reason. Suite inference can produce SUITE_DEFINITION_NOT_SATISFIED when a relevant suite relationship exists but the entity does not satisfy the suite definition. It can produce MISSING_SUITE_RELATIONSHIP when the affected product is suite-related but the installation's discovery/software-model relationship cannot be connected to an applicable suite candidate. The engine does not create these generic suite reasons for a suite-related product when that product already has an independent valid entitlement path. 41. Why an expected suite may not be inferred An expected suite can fail because the parent/child relationship is missing in cmdb_m2m_suite_model, an Always Mandatory component is missing, a Mandatory Group has no qualifying member, Number/Percent requirements are not met in the applicable inference mode, cmdb_sam_sw_install.omit_from_suites = true, the installation has already been reconciled, inferred_suite_level excludes it from the initial pass, the publisher does not match the publisher being processed, discovery-model mapping does not connect the installation to the expected suite component, software-model/product conditions reject the entity, entitlement context does not produce the expected candidate, downgrade coverage is missing, consumer eligibility rejects the licensing option, or another candidate ranks higher. The candidate path should be reconstructed in that order before changing suite configuration. 42. Backend investigation sequence Start with the expected suite in cmdb_software_product_model and validate product, inference_option, inference_number, inference, and apply_to_subscriptions where applicable. Then inspect cmdb_m2m_suite_model and validate every expected suite_parent, suite_child, and mandatory relationship. For install inference, collect cmdb_sam_sw_install records for the same installed_on device and validate discovery_model, norm_publisher, norm_product, is_reconciled, omit_from_suites, inferred_suite, inferred_suite_product, inferred_suite_level, and inference_calculated. Confirm that the discovery models map to the expected component software models and satisfy relevant software-model/product conditions. Validate relevant entitlements in alm_license, particularly software_model, license_metric, install_status, product_type, and publisher/manufacturer. If downgrade coverage is required, inspect active relationships in samp_downgrade_model and samp_sw_downgrade_model. If several install options exist, inspect samp_install_license_options and compare software_model, product, preference_rank, and preference_source. For subscription suite inference, inspect samp_sw_subscription, alm_entitlement_user, and alternative options in samp_saas_license_options. If suite inference ultimately leaves the entity unlicensed, inspect samp_entity_unlicensed_reason and its referenced definition in samp_unlicensed_reason. 43. Example: Number-based inference Office Professional contains five children in cmdb_m2m_suite_model: Word, Excel, PowerPoint, Outlook, and Access. Its parent software model has inference_option = number and inference_number = 3. Device A has qualifying Word, Excel, and PowerPoint installations in cmdb_sam_sw_install, all with omit_from_suites = false. If mandatory requirements and applicable conditions are satisfied, the candidate meets its Number threshold. If another suite also qualifies, candidate preference determines which licensing option becomes top priority. 44. Example: threshold passes but mandatory requirement fails A five-component suite has inference_number = 3, and Access is Always Mandatory. The device has Word, Excel, PowerPoint, and Outlook but no Access. Four components exceed the threshold, but the candidate fails its Always Mandatory requirement. The suite therefore cannot become structurally valid through the normal component-based path. 45. Example: component is omitted A device has Word, Excel, and PowerPoint, and the suite requires three components. The Excel record has cmdb_sam_sw_install.omit_from_suites = true. The install suite query requires omit_from_suites = false, so Excel is excluded before suite validation. The suite engine therefore sees only Word and PowerPoint as qualifying records even though all three applications appear in the raw installation list. 46. Example: suite installed directly A device has an installation that maps directly to the Office Professional suite software model. The candidate is marked as a direct installation and becomes valid and efficient without needing the normal component Number/Percent calculation. This path is different from inferring Office Professional solely from Word, Excel, PowerPoint, and other children. 47. Example: component belongs to multiple suites Word belongs to Office Standard and Office Professional. The device has Word and Excel. Office Standard covers both qualifying installations while Office Professional covers the same or a different set depending on its hierarchy and conditions. SAM constructs both candidates, validates them, and compares their efficiency, covered entities, downgrade breadth, hierarchy, percentage, and other applicable preference factors. The top candidate becomes the preferred suite/software-model option rather than whichever cmdb_m2m_suite_model relationship happens to be queried first. 48. Example: subscription suite A user has component subscription records in samp_sw_subscription. A qualifying User Subscription entitlement exists in alm_license, and its software model participates in subscription inference. SAM groups the subscriptions for the user, evaluates the suite hierarchy, creates candidate preferences, and stores alternatives in samp_saas_license_options. The selected suite can populate inferred_suite and licensable_software_model. Reconciliation still determines whether entitlement rights can actually license the subscription usage. 49. Important backend tables Software models are stored in cmdb_software_product_model; suite relationships in cmdb_m2m_suite_model; software installations in cmdb_sam_sw_install; subscriptions in samp_sw_subscription; software entitlements in alm_license; user allocations in alm_entitlement_user; device allocations in alm_entitlement_asset; entitlement-derived downgrade relationships in samp_downgrade_model; software-model/content downgrade relationships in samp_sw_downgrade_model; installation licensing alternatives in samp_install_license_options; subscription licensing alternatives in samp_saas_license_options; unlicensed reason definitions in samp_unlicensed_reason; entity-to-reason relationships in samp_entity_unlicensed_reason; and suite-inference execution tasks in samp_recon_task_queue. 50. Important backend fields On cmdb_software_product_model, review product, inference_option, inference_number, inference, and apply_to_subscriptions. On cmdb_m2m_suite_model, review suite_parent, suite_child, and mandatory. On cmdb_sam_sw_install, review installed_on, discovery_model, norm_publisher, norm_product, is_reconciled, omit_from_suites, inferred_suite, inferred_suite_product, inferred_suite_level, and inference_calculated. On samp_sw_subscription, review publisher, product, software_model, user, user_principal_name, assigned_software, inferred_suite, inferred_suite_product, inferred_suite_level, licensable_software_model, and licensable_software_model_source. On samp_install_license_options, review install, software_model, product, preference_rank, and preference_source. On samp_saas_license_options, review subscription, software_model, product, preference_rank, and preference_source. 51. Relevant system properties and settings com.snc.sam.auto_suite_inference — Enables the automatic suite-inference path when its value is exactly true. It changes candidate efficiency handling and participates in candidate construction, ranking, subscription inference, and roll-up behavior. com.snc.samp.recon.suite.min_batch_size — Controls the minimum workload size used when subscription suite inference is divided into processing ranges. The implementation fallback is 10000. This affects execution batching rather than whether an individual component qualifies for a suite. Use component licenses to optimize compliance when suite licenses run out — Applies to supported Microsoft license metrics and controls whether component licenses can be used together with suite licensing for compliance optimization. The default is false. 52. Compact backend flow Parent suite cmdb_software_product_model → child relationships cmdb_m2m_suite_model → entitlement-backed candidates alm_license → downgrade coverage samp_downgrade_model / samp_sw_downgrade_model → suite hierarchy → installations cmdb_sam_sw_install grouped by device or subscriptions samp_sw_subscription grouped by user → initial eligibility filters → software-model/product conditions → mandatory validation → Number/Percent efficiency where applicable → candidate preference → alternative options in samp_install_license_options / samp_saas_license_options → preferred inferred_suite stamped → reconciliation evaluates entitlement applicability and rights. 53. Key points to remember Suite membership is stored in cmdb_m2m_suite_model; SAM does not infer suites from product names alone. Inference configuration is stored on cmdb_software_product_model. mandatory supports Optional, Always Mandatory, and Mandatory Group. Number-based inference uses inference_number; Percent-based inference uses inference. com.snc.sam.auto_suite_inference = true changes the suite engine's inference and preference behavior. A directly discovered suite does not need to satisfy the normal component threshold. Install suite inference is device-centric through cmdb_sam_sw_install.installed_on. Subscription suite inference is user-centric through samp_sw_subscription. cmdb_sam_sw_install.omit_from_suites = true excludes the installation from component-based suite inference. Suite relationships, conditions, entitlements, downgrade relationships, allocations, and consumer eligibility can all affect candidate construction. Multiple candidates are ranked; the first parent relationship is not automatically selected. Alternative options can be stored in samp_install_license_options and samp_saas_license_options. inferred_suite represents the selected licensing option; it does not prove successful license consumption. Final compliance is determined later by reconciliation using the selected licensing option and available entitlement rights. Summary Software suite inference is a licensing-option selection process rather than a simple component-counting operation. SAM builds the suite hierarchy from cmdb_software_product_model and cmdb_m2m_suite_model, expands model coverage through applicable downgrade relationships, identifies entitlement-backed candidate models, groups installations by device or subscriptions by user, filters ineligible entities, applies software-model/product conditions, validates mandatory requirements, evaluates inference criteria, and ranks competing candidates. The selected suite is represented through inferred_suite, while alternative options can be preserved in samp_install_license_options or samp_saas_license_options. Reconciliation then determines whether the selected suite or component option can actually consume applicable entitlement rights. The complete mental model is: Suite relationship exists → Entity maps to a component → Entity passes suite eligibility → Conditions pass → Mandatory requirements pass → Inference criteria are evaluated → Candidate is ranked against alternatives → Preferred licensing option is selected → Reconciliation determines whether rights can be consumed.