Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Was able to confirm. Looks like this is just an error in the substitution through. The stored values all appear correct. Will look into this further. Probably just a caching bug.However, we run into trouble when users change their plans in CBSubs Options. If someone changes between subscription options, then the substitution you suggested gives the value of the previous plan's options.
These substitutions come strictly from within CBSubs so you must use a CBSubs integration for this. You won't be able to use CB Auto Actions here unless you directly access the stored params.I also tried it using Auto Actions on cPayIntegrationAction, in case that made a difference in the order of execution etc (second screenshot).
Both options worked for subscriptions and expiries - but failed on renewals with a different option.
The history looks correct. The new values are 1 for current and 2 for previous. The old values were 2 for current and 3 for previous. So that seams correct.Looking at the change log for the user subscriptions/renewals/upgrades, I see that values are saved for both the "planoptions" and the "previousplanoptions" - both with the same variable name. (Third screenshot). Is it possible that the wrong value of the variable is being used in the substitution? Or is there some way I can fix this problem?
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.