Managing multiple versions when changing the price

I’m about to release a new version of my add-on with a price change but am unsure about how a few things will play out. I’d rather not find out in production if possible.

I understand users will have to manually opt-in to the new version when the price is changed but:

  1. Will users who aren’t affected by the price change still need to approve the upgrade? (ie user is on 10 user instance and pricing for that tier hasn’t changed).

  2. Will users who don’t upgrade stay on the old version of the add-on indefinitely?

  3. Can you force upgrade users who don’t upgrade after a period of time without applying the price change?

  4. Is there a way for users to go back to the previous version of the add-on if they prefer it?

  5. Is there a reliable way to test older versions of the add-on using a token as I notice that I can only generate a private token for the last 2 versions.

Thanks in advance.



1 Like

Hi @RhysDiab ,
You didn’t specify whether it’s a server, DC or Cloud app, but since you mentioned approving the upgrade, I assume it’s Cloud.
In that case, the price change is applied automatically to all customers, they don’t have to approve anything. And even if you add new scopes to your app descriptor, which will force customers to manually accept the upgrade, the new price will still be applied to customers who refused the upgrade.

1 Like

Thank @david2 ,
Yes this is for Cloud.

So if I want users to manually approve the upgrade, I should add new scopes (ie EMAIL)?

I guess I’m still a little unsure if:

  1. There’s a way for users to go back to the previous version of the add-on if they prefer it.
  2. There’s a way to test the old version of the descriptor using a private token. It seems only the previous 2 versions can use a private token and any version older than that can no longer be tested. I’m thinking this might be necessary if there are breaking changes to ACE ect…

Thanks again.