Ramp deals refer to multi-year deals that have an increase in user quantity with each ramp term. Generally ramp terms/intervals are a year long.
ex. Year 1: 20 seats, Year 2: 30 seats, Year 3: 40 seats
The rollout of Zuora Ramps will result in a change to the current structure of a ramp deal. A single subscription will now include all ramp intervals over multiple years, instead of today's current state, which involves having multiple unique 1 year subscriptions for each interval.
Problem
In testing provisioning for ramps with this new data structure, it was identified that there is no callout from Zuora sent at the start of a new ramp interval, only an initial callout at the start of the subscription. As a result, CDot is unaware of the changes in license quantity occurring each year. This means additional licenses are not provisioned when needed.
The solution selected was for the EntApps team to build a new Zuora workflow that will trigger a callout to Customers Dot to inform CDot of quantity changes. The logic for the workflow will check that the subscription is a ramp, and send a callout when today's date = the start of a new Ramp interval with a change in quantity.
Proposal
Test this new custom workflow to send subscription_update callout for ramp interval changes to validate all required information is received by CDot in order to properly provision a subscription.
@jesssalcido Any thoughts on my comment below? I know you are quite busy so this one might have slipped through.
Note: I'm moving the conversation to this issue from #3968 (comment 928242737) as it applies to automated provisioning rather than manual. Sorry for the confusion!
@jesssalcido I was troubleshooting the data query that's used in the ramps provisioning Zuora Workflow this morning. When we tested it yesterday, we hoped to get 2 subscriptions returned (referenced in the notes here), but we only saw 1.
I think there is a small bug in the query, particularly the outer query where the 2 ramps are compared. I made an adjustment to the query, which you can see here, so that r2 is used when filtering start date. I also changed startdate and enddate referenced in the select portion of the query to reference r2 as well. You can see that both subscriptions are returned with this change.
Should we get this cross-checked by Zuora? I'm not sure who developed the query originally.
Please provide a quick summary of the current status (one sentence)
I've been in contact with Jessica on this issue and she's planning on dedicating time to this issue this week. We may have more to report back next week.
How confident are you that this will make it to the current milestone?
Not confident
Slightly confident
Very confident
Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
Yes
No
Were expectations met from a previous update? If not, please explain why.
Yes
No, as Jessica has had other pressing matters to attend to, and this requires some collaboration between us. Hopefully we can make progress next week though.
Are the related issues up to date? Please link any missing issues in the epic that could be linked to this issue
Test this new custom workflow to send subscription_update callout for ramp interval changes to validate all required information is received by CDot in order to properly provision a subscription.
I'm not familiar with ramps yet so I might be missing some context. Wondering what this test should look like, is it supposed to be a manual test or something else?
cc @tyleramos as you already worked on it (but you are out this week).
hey @cwiesner - I updated the issue description to provide some more context. This will be a close partnership with @jesssalcido & team who will put together some test subscription data in Zuora, have the workflow they built send callouts to CDot, and then from our side we would need to validate the callouts are received and update the subscription to reflect the correct change in quantity.
@jesssalcido I'm moving this to %Backlog given the delay in the Ramps timeline for now - do you have an estimate as to when the workflow would be ready for testing by fulfillment so we can schedule appropriately?
@courtmeddaugh I finally had a chance to work through the updates to the query that Tyler proposed. Since the query is now working, we should be ready to test this Workflow next week. Thank you for your patience!
@cwiesner Let me know if you need any additional context but looks like @courtmeddaugh answered it nicely.
@jesssalcido and I had a call a while back where we tested the custom workflow together. She setup a couple of subscriptions that would be returned by the query and be included in the callout. Jess was able to trigger the query manually so that we could test the outcome in CDot. I think we could do a similar test this time around.
@cwiesner Happy to help with this! If we have a couple of subscriptions where the second ramp period is effective as of today, I can run the workflow manually to trigger callouts to CDot and we can observe. Let me know when you are looking to test. cc @tyleramos
@jesssalcido I'll take a look at the subscription created in this comment tomorrow and will try to create similar ones. From the quick look I just had at the creation form in Zuora, I think I know how to create them. But I'll find out more tomorrow. Is there anything of note to look out for though?
You mentioned in your previous comment this should be ready to be tested next week. With the comment above, it sounds like it's ready to test though, is that correct? If yes, we can set up some time this week or next week, whatever works best for you. It looks like we have a 9 hour difference (with me ahead) according to your Slack profile's time, so I'd prefer something at the start of your day
@jesssalcido I created one subscription (A-S00218073) as a test. Do you mind checking it if the way I set it up is correct?
Also do we have some kind of documentation how to set up those examples? It looks like the subscriptions in this comment were created for three different customers, is that a requirement?
cc @tyleramos in case you also know more about this
@cwiesner The intervals on the subscription you created look good I think. Looks like interval 2 starts today so I would expect the Data Query to include this, but when I ran just now the result set was empty. I must be missing something obvious.
@cwiesner@tyleramos I think it's because the ramp subscription was created with a charge that does not change during subsequent Ramp Interval Periods. The quantity is the same for each ramp interval period.
We would expect that the quantity (or price, or both) would most likely change when a new ramp interval begins. In that case, we would see a few order actions for each ramp Order: Create Subscription, Update Product (effective as of Ramp Interval 2), Update Product (Effective as of Ramp Interval 3). For this order, we only see one order action (create subscription).
Here is some Zuora documentation about creating ramp deals with product updates! I think the steps you'll need begin at Step 13. Please let me know if you need any additional help, happy to set some up for you as well.
@tyleramos Just to be completely clear, I want to ensure that we are only looking at capturing updates with the Zuora workflow, correct? If the quantity of a rate plan charge does not change as of a subsequent ramp period, the Workflow (and query) is not currently designed to send a callout. Let me know if this is ok, thank you!!
Thanks @jesssalcido and @tyleramos. I think I was able to create a proper subscription with A-S00218738 that was also found via the query Tyler used in his last comment.
I proceeded to create two more subscriptions (A-S00218739
and A-S00218740) aligned to the ones in this comment. When using the query again, only A-S00218738 and A-S00218739 were found but not A-S00218740 (same as in the mentioned comment).
@jesssalcido If this looks good to you we can see about triggering the callouts to CustomersDot. Let me know how and when you want to do that.
I want to ensure that we are only looking at capturing updates with the Zuora workflow, correct? If the quantity of a rate plan charge does not change as of a subsequent ramp period, the Workflow (and query) is not currently designed to send a callout
@jesssalcido If the quantity does not change between intervals, I don't think we'd necessarily need a callout. Given the license is generated for the full subscription term and doesn't end on the interval end date, the existing license should be sufficient. We should probably test this scenario out in UAT when the time comes but I believe we are fine here.
@jesssalcido I'll only be available this week and then I'll be out till mid August. In case testing can't happened this week maybe @a_luna can take over. She's even in a similar timezone as you.
Hi @courtmeddaugh, thank you for your patience with this! Since E-Disty UAT is now on hold, I can go ahead and focus on this. I should have this working enough to test mid-week next week.
Going to move to %Backlog for now. @jesssalcido no rush whatsoever, but once this is prioritized and ready on your end let us know and we'll re-schedule it!
Thank you @courtmeddaugh@cwiesner! For some additional context, because of the personnel changes we've had in our org, we are now working on re-mapping the Ramps / Quote Studio project timeline overall. Once we have that squared away, we should be able to move forward. Appreciate your understanding!
@courtmeddaugh I think we can begin testing either late this week or early next week. Would you like me to coordinate with @cwiesner on this, or someone else?
We can set aside a day to test, and I can create ramp deals where a new ramp period begins that day for testing. Let me know how you'd like to proceed.
@cwiesner For additional context, I'll be heading OOO this Friday 2022.11.04, back on 2022.11.13. Should we just plan to schedule for that week? cc @courtmeddaugh
@jesssalcido I was out for a while and am back starting today. The week of November 13th sounds good to me. I went ahead and put something in your calendar for the 16th. Feel free to modify that meeting.
Thank you! Just a head's up @cwiesner@jesssalcido that I'll be out that week and the following so I won't be able to answer questions (but I don't imagine you'll need me anyways)
@courtmeddaugh We'll post a summary of the meeting here to keep everyone in the loop and document any findings. If there's anything we need from you, you can follow-up on it async after you'll be back anyway.
@jesssalcido and I met up to test the Zuora workflow for ramp interval updates. We were able to run the workflow but we need to make a couple of changes:
The callout params will be modified to contain the order id along with the order number and the subscription name will be removed to align it a bit to the order_processed callout. @jesssalcido is looking into modifying this.
The callout will go to subscription_update which currently uses a different params set than order_processed. For example, it doesn't use any order params. This is something that the code needs to support for this workflow. Maybe it makes sense to keep the subscription_name in the params, but we can find it via the order info.
The query was modified to only return subscriptions with the status Active. The previous version returned Cancelled ones that we don't need. This is the new query that we have at the moment.
The workflow run resulted in a couple of callouts that we can see in the customer's account. These callouts did not make it into my local instance though. We usually see the Result column of the callout history to be FAIL(406). But we are seeing PASS for these callouts:
I'm checking with @aish.sub about a possible relation to the ZSim implementation that fetches the Zuora callouts (Slack thread (internal only)).
We also observed a similar behavior for the subscription that @jesssalcido created which should not have resulted in a callout. @jesssalcido will take another look at the data query.
@jesssalcido Can you add anything that might have slipped in this update? Also, let me know if I can help in any way with the modifications.
@mlunoe I think we can create a documentation later when we have more info about all of this and how it's supposed to work. At the moment we're still trying to sort a few things out.
Sorry, I'm not sure what you mean by QA test. We likely already have lower-level unit, integration and feature tests that cover creation, but perhaps not re-creation. @cwiesner might have a better idea of our coverage of this particular piece, but from first glance, we should be testing the subscription_update callout bit since that's on our side. Do we have sufficient coverage here?
was for the EntApps team to build a new Zuora workflow that will trigger a callout to Customers Dot
This bit is a bit more fuzzy. Are we mocking this "workflow" in our tests somewhere?
Sorry, I'm not sure what you mean by QA test. We likely already have lower-level unit, integration and feature tests that cover creation, but perhaps not re-creation.
@ddavison Pardon me, I did mean feature or integration tests.
@cwiesner Thank you so much for this write-up and the time spent testing yesterday. In regards to the query, Zuora has recently released a few objects which may help simplify the query:
rampintervalmetrics: Includes charge information, quantity, subscription name.
rampintervaldeltametrics: Includes delta metrics. Can help us exclude charges that do not change quantity.
I'll spend some time on this query next week to hopefully get us to where we need to be. Appreciate your help and collaboration !
@mlunoe@ddavison We don't have much logic for ramp deals in the code so far. I'm expecting additional changes to process the incoming data of a callout related to what we're testing here. We'll add sufficient test coverage at that point.
Perhaps it makes sense to set up a QA test to cover this?
@mlunoe@cwiesner Thanks a lot for bringing this up We do have e2e tests that covers the initial creation for ramp subscription creation, but not on update. I think this could be a good addition