How does subscription reconciliation work?

[Claire Ashdown1]

I am trying to understand how reconciliation to the License Workbench and more broadly when subscriptions come in works. For example, with installs, a discovery model is associated to the install, and that discovery model (assuming it is normalized correctly and completely), has publisher, product, and (optionally) version/edition information. Installs are dynamically reconciled to allocations and entitlement rights through the software model on those entitlement and that software model's publisher, product, and (optionally) version/edition information. If publisher, product, and version/edition information align (as can be checked through the "Show matching discovery model" UI action), then the installs reconcile correctly to the rights. I understand this install reconciliation piece, but please let me know if something in my understanding is incorrect.

Using subscriptions though, I can see that there is a subscription identifier, that this identifier is in the samp_sw_subscription_product_definition table, and that a DMAP is associated to it that way. Because of that, my understanding is that the subscriptions are essentially using the DMAP as the bridge between the software model and subscription, kind of like how installs use the publisher/product/version/edition information as the bridge. However, for a particular product we have and for data quality cleanup reasons, we updated the DMAP on software model A to be the DMAP that the samp_sw_subscription_product_definition for the product's subscription identifier uses and the DMAP on software model B (the software model the subscriptions for the product were originally tied to) to be a different DMAP. My assumption was that the subscriptions aren't hard-coded to a particular software, so they will be more dynamic and would grab software model A that now has their DMAP as defined by the samp_sw_subscription_product_definition table for their subscription identifier on the next subscription refresh/load. However, that has not been the case, the old software model B is still the on the subscription records despite the DMAP on software model B not actually matching the DMAP listed for the subscription identifier. Is it actually more hard-coded to be one and only one specific software model, or should the software model for subscription records be retrieved and set more dynamically based on software models that match the DMAP listed in the samp_sw_subscription_product_definition for the particular product's subscription identifier?

Many thanks for any clarification, ideas, and correction you can provide as I am trying to understand this process better.

[Taksh]

Hi,

Let's understand software model creation process for subscriptions.

While creating a software model, process looks for existing software model populated against pulled subscription identifier. If it finds the match, it populates the same software model, else it'll refer to samp_sw_subscription_product_definition table to determine the correct DMAP and create software model. This is done for performance reasons.

In your example, though SM-A is updated with correct DMAP, existing subscriptions are tagged to SM-B. In order to tag SM-A, please delete subscription records for the given subscription identifier and re-run the job.

[mikew_samexpert]

Hi Claire,

For subscriptions, the software model is automatically created once the subscription data is ingested from the SaaS vendor into SAM Pro. If the incorrect software model is being linked to the subscription during this process, then you will need to raise a HI ticket with ServiceNow to get their content team to update the samp_sw_subscription_product_definition table.

Also, in your first paragraph, the statement "installs are dynamically reconciled to allocations and entitlement rights through the software model on those entitlements" requires rewording to "Installs and allocations are dynamically reconciled to entitlement rights through the software model linked to those entitlements". 🙂

Cheers,  MIke.