The Subscriptions Feature Service API is optimizing performance by aggregating entitlement data locally instead of querying dependent services in real time. Currently, the Feature Service also computes an isEval flag (trial entitlement indicator), which complicates these improvements and future onboarding to Management Fabric.

We’ll move the isEval determination logic back into Entitlements.

Keith wrote a great write-up summarizing our conversation with them that you can find here. 

Proposed Implementation

1. Split SKU-based Features into Paid vs Paid+Eval

• Keep existing feature bundles (e.g., ansible) as they are today; containing both paid and trial SKUs.

• Create new paid-only feature bundles (e.g., ansible-paid) that include only paid SKUs.

• In Entitlements, query both features and derive isEval locally based on the results:

• • entitled = true if either ansible or ansible-paid is entitled

• • isEval = true if ansible is entitled and ansible-paid is not

• • isEval = false if ansible-paid is entitled

2. Update Logic in Entitlements

• Ensure the Entitlements service can query multiple features in a single API call (e.g., ?features=ansible&features=ansible-paid).

• Add logic to calculate and return the isEval flag based on the results.

• Remove isEval dependency from the Feature Service side.

Developer Notes / Considerations

• We’ll need to communicate and document in the Feature Service config repo that we now have two distinct bundle types:

• • *-paid = paid SKUs only

• • existing bundle = paid + eval SKUs

• This distinction could be confusing to future maintainers, so clear naming and README updates are critical.

• When updating bundles:

• • Adding a paid SKU → update both the existing bundle and the new *-paid bundle.

• • Adding an eval SKU → update only the existing bundle.

• • Developers need to understand how to identify which SKUs are eval vs paid.

• Consider whether we could instead create separate paid and eval bundles instead of retaining the existing one (paid+eval). This might simplify maintenance but could be a breaking change for other consumers.

• Confirm whether any upstream consumers (other than Entitlements) depend on the current feature names before renaming or redefining bundles.