# Feature Request ## Summary The rollout of Zuora Ramps (https://gitlab.com/groups/gitlab-com/business-technology/enterprise-apps/-/epics/85+) will result in a change to the current structure of a ramp deal. Instead of creating a separate opportunity, quote and subscription for each ramp interval, a single subscription will now include all intervals over multiple years. For MVC launch of Ramps, provisioning of each year (after the first) will be manual. However, given the ease of use of Zuora Ramps, there is expected to be a significant increase in the number of Ramp deals in FY23, will result in a burden on the Support team manually issuing licenses. This issue addresses the need to automate licensing for Self-Managed Ramp subscriptions. Discovery work being completed in [this issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3754) informed what data is received from a Zuora Ramp deal by CustomersDot which is required to know how provisioning could handled for each ramp interval. You can find the results of a 3 year Ramp test for SM [here in the issue](https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3754#note_807607785). As you can see, the resulting license was generated for the correct initial time period (the 1st year of the ramp), but the quantity was incorrect. The quantity was for the active/final ramp of the subscription (e.g. 30) instead of the initial ramp (e.g. 10). ### Problem Statement Only one callout goes out for the new subscription, and includes all of the subscription / ramp terms. The license is created for only 1 year. There are no callouts for successive intervals. ## Proposal ### Start of Subscription * At the current state, provisioning works partially for the first ramp year of a subscription. Provisioning will be adjusted in https://gitlab.com/gitlab-org/customers-gitlab-com/-/issues/3968+ to address the problems with determining quantity and end date correctly. We will assume this work is completed before starting this issue. ### Successive Subscription Intervals * Update the user's subscription license count to the correct value at the beginning of each ramp period * This will require a custom workflow in Zuora that will send a callout to CustomersDot to update the subscription's license in subsequent years when the ramp interval changes as this does not currently exist. EntApps work issue here: https://gitlab.com/gitlab-com/business-technology/enterprise-apps/financeops/finance-systems/-/issues/698 * The decision on whether a custom workflow callout can be used for this purpose was discussed in https://gitlab.com/gitlab-com/business-technology/enterprise-apps/bsa/business-systems-analysts/-/issues/145. It was decided we will use a Zuora custom workflow for this trigger. ### License End Date Logic Update Our logic for determining license end date ([defined here in CDot](https://gitlab.com/gitlab-org/customers-gitlab-com/blob/3e8889422f9bc05f57cb205fb025364b28ccdcef/app/models/concerns/license_creation.rb#L7)) is conditional. The license end date is set using subscription term end date if the subscription is a monthly sub OR is cloud licensing enabled (`TurnOnCloudLicensing__c` is `Yes` or `Offline`) and reconciliations are enabled (`TurnOnSeatReconciliation__c` is `Yes`). Otherwise, the license end date will be set to term start date + 1 year. Based on the default [defined in this issue](https://gitlab.com/gitlab-com/business-technology/enterprise-apps/intake/-/issues/527#super-sonics-fields-and-standard-exemptions), it looks like ramps subscriptions will not have `TurnOnSeatReconciliation__c` enabled, so the license start date will fallback to term start date + 1 year. **Requirement:** Add another condition to check if cloud licensing is enabled and subscription is ramp enabled, then use term end date. The logic might look like the below: ```ruby if monthly? || (cloud_license_enabled? && (perform_reconciliations? || ramp_enabled?)) term_end_date else term_start_date.advance(years: 1) end ```