Entitlement Management Enhancements in 2026.08

The following enhancement to entitlement management was added in the 2026.08 release.

• Configuring Multi-Access Licensing Logic at the License Model Level

Configuring Multi-Access Licensing Logic at the License Model Level

Software producers often need to support different licensing behaviors for different products or use cases within the same Cloud Licensing Server (CLS) instance or local license server. Prior to this enhancement, a CLS instance or server could use only a single licensing behavior: either conventional licensing logic or multi-access licensing logic. As a result, all features within the instance were forced to follow the same behavior, even when customer usage patterns differed. This limitation made it difficult to support mixed consumption models and often required workarounds such as separate licensing infrastructure, additional entitlements, or changes to application design.

With this release, you can now configure the licensing behavior at the license model level. Features associated with a license model configured for multi-access licensing can coexist alongside features that continue to use conventional licensing behavior within the same CLS instance or local license server. This provides greater flexibility when designing licensing strategies for products, modules, and customer-specific workflows.

Conventional Licensing Logic vs. Multi-Access Licensing Logic

This section recaps the key differences between conventional licensing logic and multi-access licensing logic.

• Conventional Licensing Logic—Under conventional licensing logic, the license server follows a return-and-reacquire model. When a subsequent license request is received for the same feature, the latest request determines the resulting usage. Previous usage is effectively replaced by the most recent request.
• Multi-Access Licensing Logic—Under multi-access licensing logic, the license server follows a retain-and-grow model. Multiple requests for the same feature can coexist, with the license server retaining the highest license count and the longest borrow period associated with those requests. This enables multiple processes, sessions, or applications to continue using the same entitlement without interfering with one another.

Tip:For detailed information about the differences between the two licensing logics, see the Appendix “Multi-Access Licensing Logic: Behavior and Limitations” in the FlexNet Embedded Producer Guide 2026.08.

Example Use Case

Consider an engineering organization running complex simulation software. A user needs to launch multiple simulations concurrently on the same machine using a single entitlement. Under conventional licensing logic, a subsequent license request may require an existing license usage record to be returned and then reacquired, potentially impacting running simulations. In some cases, customers addressed this limitation by issuing additional licenses.

With multi-access licensing logic enabled for the relevant license model, multiple simulations can run in parallel under the same entitlement. The license server retains usage based on the highest count and longest expiry period rather than replacing existing usage records. This allows different applications or processes to share licensing resources more effectively while reducing the need for licensing workarounds and additional administrative overhead.

Feature Allocation on a Single Device

Feature allocation is determined individually for each feature based on the licensing logic configured for the associated license model.

Therefore, a single device can simultaneously consume features that use different licensing logic. For example, within the same CLS or LLS instance, one feature can use conventional licensing logic while another uses multi-access licensing logic. Each feature's allocation is processed according to the configuration of the license model to which the feature belongs.

Multiple Features in a Single Request

When a capability request contains multiple features, the request is evaluated independently for each feature and can result in two distinct allocation paths:

• Multi-Access Allocation Path—The feature entitlement is allocated from the multi-access license pool, subject to available capacity.
• Conventional Allocation Path—If no eligible multi-access allocation is available, the feature is allocated from the conventional license pool based on applicable licensing model.

Allocation Priority For Multi-Access and Conventional Features

When the same feature and version are available under both multi-access and conventional license models, capability requests are fulfilled using the following precedence:

1. Licenses are allocated from the multi-access license pool first.
2. Once the multi-access allocation is exhausted, licenses are allocated from the conventional license pool.

Features configured for multi-access licensing are consumed first, allowing producers to take advantage of the retain-and-grow licensing model while continuing to support conventional licensing behavior where required.

Allocation Priority For Negative Requests

When the same feature and version are available under both multi-access and conventional license models, and the CLS instance or license server receive a negative capability request, features associated with a license model with conventional logic are returned first.

Features with multi-access licensing logic can only have their count reduced by a negative request, or when the feature expires.

Configuring the Licensing Logic

This release introduces a new Multi-Access Licensing: Allow duplicate client checkouts? option for embedded counted license models. Available on the Create a License Model page (Administer > License Models), this option enables producers to control licensing behavior at the license-model level.

The option appears only when Type of license model is set to Embedded and Counted is set to Yes.

• No—Uses conventional licensing logic (default).
• Yes—Uses multi-access licensing logic.

The licensing behavior applied to a feature is determined by both the instance-level licensing.allowDuplicateClients policy setting and the license-model-level Multi-Access Licensing: Allow duplicate client checkouts? option.

The following combinations of instance-level and license-model-level settings can be used to implement different licensing strategies.

Desired Outcome

licensing.allowDuplicateClients

Multi-Access Licensing: Allow duplicate client checkouts?

Use conventional licensing behavior for all features in the CLS instance or local license server

false (default)

No (default) for all license models

Use multi-access licensing behavior for all features in the CLS instance or local license server

true

Yes for all license models

Use multi-access licensing behavior for some features and conventional licensing behavior for others

true

Configure Yes for license models that should use multi-access licensing behavior and No for license models that should use conventional licensing behavior.

Note:The existing instance-level licensing.allowDuplicateClients policy acts as an enablement switch for the new license-model-level configuration. When licensing.allowDuplicateClients is set to false, all features use conventional licensing behavior regardless of the setting configured in individual license models. When licensing.allowDuplicateClients is set to true, the Multi-Access Licensing: Allow duplicate client checkouts? setting in each license model determines whether the associated features use conventional or multi-access licensing behavior.

To take advantage of the new license-model-level configuration, set licensing.allowDuplicateClients to true at the instance level and configure the desired licensing behavior in each license model.

Controlling Visibility of the Multi-Access Licensing Option

Visibility of the Multi-Access Licensing option on the Create a License Model page is controlled by the Enable multi-access licensing configuration option (under System > Configure > FlexNet Operations > Embedded Device Settings). By default, the configuration option is unselected, that is, the Multi-Access Licensing option is hidden.

Visibility Through the Features API

The /features API now includes an allowDuplicateClients field that identifies the licensing behavior associated with each feature:

• true—Indicates multi-access licensing behavior.
• false—Indicates conventional licensing behavior.

Implications of Updating This Option After Deployment

If the Multi-Access Licensing option is modified after a license model has been deployed, the updated configuration is propagated to downstream systems. The license server is notified of the change, and subsequent license and capability responses reflect the new behavior. Existing borrowed licenses are not modified; they continue to operate under the original settings until they are returned or expire. Over time, as active sessions end or borrowed licenses expire, the system gradually transitions to the updated configuration, ensuring that all future requests follow the revised licensing behavior.

Summary and Key Benefits

• Configure licensing behavior at the license-model level, allowing conventional licensing logic and multi-access licensing logic to coexist within the same CLS instance or local license server.
• Use the new Multi-Access Licensing option when creating an embedded counted license model to select the desired licensing behavior.
• Support mixed licensing strategies within a single CLS instance or local license server, allowing some features to use conventional licensing logic and others to use multi-access licensing logic.
• Enable concurrent usage scenarios where multiple processes or applications need to consume licenses under the same entitlement.
• Reduce the need for separate infrastructure, additional entitlements, or client-side changes to support different customer consumption models.
• Continue using existing capability request formats without application changes.
• Identify the licensing behavior associated with a feature through the new allowDuplicateClients field returned by the /features API.