More About the Product Version Upgrade Job
The Product Version Upgrade job automates the creation of upgrade line items. For eligible products and line items, it causes FlexNet Operations to create upgrade line items, to add them to existing entitlements, and to send an email message to end users to notify them about the upgrade.
Important:To avoid the creation of unexpected upgrade line items and unwanted email messages, be sure to review the guidance in Product Version Upgrade Use Guidelines and Product and Line Item Eligibility Rules before scheduling the Product Version Upgrade job.
Product Version Upgrade Use Guidelines
Due to the qualifications FlexNet Operations uses to determine which entitlements receive the automatic upgrade line items, the use of this feature is best suited for producers who structure their product upgrades in the following ways:
| • | Product upgrade relationships are relatively simple. Products upgrade in a direct line from one version to the next without branching into multiple upgrade paths. |
| • | Permanent entitlements, if offered, are sold with maintenance items. |
| • | All accounts are entitled to product upgrades. (No need to filter out specific accounts.) |
Producers who follow different product upgrade models may not benefit from using the Product Version Upgrade Job.
Note:To support the Product Version Upgrade job, products include product-upgrade-specific attributes: Start Date, End Date, and Email Template to Use for Product Upgrade. The dates play a role in determining which products are eligible to upgrade. The email template attribute specifies which variation to use for the email messages sent to end users as a result of this new job. See Creating a Product for more information.
Product and Line Item Eligibility Rules
The Product Version Upgrade job determines which entitlements receive upgrade line items based on associated product and line item attributes.
| • | Upgrade relationships must exist between the products (with only one possible upgrade-to path). |
| • | The license model to use for upgrade entitlements must be clearly determined due to some combination of the following conditions: |
| • | An upgrade product is linked to the same license model as the license model on the line item to be upgraded. |
| • | An upgrade product is linked to only one license model. |
| • | A default license model has been defined on an upgrade relationship. (See Relating Products to Other Products for instructions on setting the default license model in Upgrade Default Model for an upgrade relationship.) |
| • | Product start and end dates are either valid or unspecified. |
| • | Line items must be deployed. |
| • | Line items cannot include multiple products. |
| • | Permanent line items must be linked to a maintenance item that has not expired. |
| • | Non-permanent line items must not be expired (past a known end date). They are not required to be linked to a maintenance item. However, when a non-permanent line item is linked to a maintenance item, the maintenance item must not be expired. |
| • | If a line item is linked to a maintenance line item, the following conditions must be met: |
| • | Maintenance products must have Allow Upgrades set to Yes. |
| • | The upgrade-to product must be related to all the maintenance products to which the upgrade-from product is related. The Product Version Upgrade job does not create upgrade lines for a product if the upgrade-from product has relationships that the upgrade-to product does not have. |
| • | Line items must not already have been otherwise upgraded, upsold, or renewed. |
Entitlements that do not meet these qualifications are ignored by the upgrade job.
Avoiding the Creation of Upgrade Line Items with Incompatible License Models
Some license technology and license model conflicts can prevent the successful activation of upgrade line items. (FlexNet Operations does not prevent the creation of these upgrade line items, but the resulting line items cannot be successfully activated.) The following upgrade paths result in upgrade line items that cannot be activated:
|
Upgrading From |
Upgrading To |
Notes |
|
Custom licensing |
FlexNet Publisher Trusted Licensing |
Sharing counts between a license model from a custom license technology and retail activation license model is not supported. |
|
FlexNet Publisher Certificate Licensing |
FlexNet Publisher Trusted Licensing |
Sharing counts between a floating, counted license model and a retail activation license model is not supported. |
|
FlexNet Embedded Licensing |
FlexNet Publisher Certificate Licensing |
Sharing counts between an embedded counted license model and a node-locked, uncounted license model is not supported. |
|
FlexNet Embedded Licensing |
FlexNet Publisher Trusted Licensing |
Sharing counts between an embedded, counted license model and a retail activation license model is not supported. |
Information Copied During the Upgrade
During the upgrade job, the following information is copied from the line item to be upgraded to the upgrade line:
| • | License model (if possible) |
| • | Start date and license term settings |
| • | Number of copies |
| • | Custom line item attribute values |
| • | Entitlement-time license model attribute values. (This copying happens even if the license technologies are different as long as the license model attributes have the same name and data type.) |
Tip:To learn about how predefined and custom attribute values can be substituted into license strings, see Employing a Predefined Substitution Variable .
Running the Job
Producers can schedule the Product Version Upgrade job to run activating the Product Version Upgrade alert on its Configure Alert Definition page. By default, this alert is inactive and the Product Version Upgrade job does not run. (See Configuring Alert Behavior for instructions.)
When the Product Version Upgrade job is completed, customers can use the End-User Portal to view the new upgrade line items in their entitlements, then download and activate them.
See Also