We are still starting up and 2700$ is a lot for us so we do not want to spend on listing an app which may not have enough potential.

We are thinking of listing an App with basic features, if it gets traction, we will add more features to the same app which will cost extra.

Can we list an ISV app as a 'Free' and then make it paid for additional features?

Additional details:

SFDCFox has detailed. There can be two packages(base and premium), 'base' package checks the existence of 'premium' package on the same org. 'base' can be free and 'premium' can be paid. https://salesforce.stackexchange.com/a/149360/3788

An App can be listed as free and then made paid(with payment of security review fees). However, it does not explain the impact on existing users of the app who downloaded it when it was listed as free. Convert a Free Listing to Paid, with Checkout

  • 1
    Is this what you are looking for? – Jayant Das Jul 5 '18 at 13:39
  • @JayantDas yes, this is what i am looking for. However how does that affect existing users? How do we minimize impact on existing user? Any other things that one must cosider before doing that change?...I am expecting these aspects to be answered. – Ganesh Bhosle Jul 6 '18 at 5:03

It probably depends on how you collect payment for those additional features. For paid apps there is also a revenue sharing component (currently 15%).

However, I did find this:

Does the revenue share apply to non-Checkout processed transactions?
The revenue share applies only to Checkout transactions, that is, any charges in your Recurly account linked to your AppExchange Publishing Organization (APO).

However, I'm not a lawyer and that isn't legal advice.

Based on the AppExchange Partner Program Policies (Currently linking to ProgramYear2019, which appeared to be current when this was posted). Interpret this section as you will:

As part of the ISVForce Partner Category, Partners may distribute free applications to existing SFDC customers. Partner’s distribution of free applications to existing SFDC customers does not require Partner to pay SFDC fees (other than Program Fees) for such distribution; provided, however, that an application is only a free application for the purposes of these Program Policies if the applicable customer can install and/or access and make full use of all of the features and capabilities of the application without paying Partner fees of any kind. A Partner application that integrates to or makes use of any application, service or other product for which Partner collects fees is not a free application. (For example, an application is not a free application if it is provided under a “freemium” payment model or if it requires purchase of another application from the applicable Partner.) SFDC reserves the right in its sole discretion and at any time to determine whether an application is a free application for the purposes of these Program Policies

From my, very non-lawyerly, reading it seems like it is only a free app if there aren't fees involved for using it. That middle section seems fairly clear that you aren't a free application when you start collecting fees.

With regards to what happens when an existing free listing is converted to a paid listing I've asked for further clarification via the Partner Q&A forum.

  • 1
    Based on the ISVForce Partner Program Policies listed above, you absolutely cannot make a free app that has paywalls or pay features behind it unless you want to risk a meeting with the Salesforce legal team. – Morgan Marchese Jul 5 '18 at 23:59

So, as Daniel Ballinger mentions in his post, the Partner Program Policies explicitly forbid you from making an app that is labeled 'Free' if there is intention of selling something to the Partner or the partner incurring additional fees after they've installed the app. Specifically this bit here:

(For example, an application is not a free application if it is provided under a “freemium” payment model or if it requires purchase of another application from the applicable Partner.)

However, that doesn't stop your company from making 2 versions of your app, one being a free version with a specific set of features, and another being a paid version (listed as such in the AppExchange) with extra features that aren't offered in the free app model. I've seen this done before without any issue. If you build it right, you should be able to maintain it from the same code-base also, but as two separate, distinct packages (free and paid versions).

If you want a real-world example of this, go to AppExchange and search for AddressTools, you will see that they have two listings: a free and a paid version.


On a similar note to Morgan's suggestion - you could create a free app, and then later on a paid extension package. The latter package will require you actually pay for the Security Review.

Also, if your customers are comfortable with the extension package temporarily being non-Security-Reviewed, then you could charge them for the extension services without AppExchange being involved. This may give you an opportunity to get some revenue with which to justify the fee.

And finally, if your package is quite elaborate and jam-packed with features, you might be able to earn some revenue by providing the customers paid consulting services on how to set up high-quality customizations using your package.


I agree with all comments above in terms of whether or not you can advertise as free.

In terms of how you implement ... there may be more elegant solutions leveraging 2nd generation packaging. You could have separate packages in same listing and also use features to unlock 'pro' features:


  • If the link answers the question, please include its relevant content here. – Adrian Larson Sep 21 '18 at 17:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.