Skip navigation

In response to some folks’ questions, I thought I’d write up a very brief summary of the “right” way to go about diving into the Salesforce.com Partner world, whether as an ISV / OEM. There’s an order to this madness that can help prevent “wow, wish I’d done it that way from the beginning” moments later on, plus, there’s a whole alphabet soup thrown around related to Salesforce environments / orgs of different types, and their roles in the partner lifecycle.

A quick check to see whether this article will be helpful. If you can identify the meaning and role of each of the following Salesforce-related abbreviations, you can get on with your day. Otherwise, keep reading!

  • APO
  • LMO
  • PDE
  • TMO
  • ISV
  • DE
  • OEM
  • LMA

What I’ll do in this article is to walk through a “recommended” process for getting started developing Salesforce.com applications, along the way highlighting different Salesforce.com Organization / Environment types, and at the end, I’ll briefly summarize. Here we go!

1. Register as a Salesforce.com Partner.

To do this, go to http://www.salesforce.com/partners/join/ and fill out the form. You’ll receive by email a login to the Salesforce.com Partner Portal, which allows you to do all sorts of necessary things in the Partner lifecycle, like creating special orgs, logging partner support cases, and getting access to special training materials, etc.

2. Start building your Application!

For native Force.com applications, this should take place in your managed-package development org. You will have one, and only one, of these for each Managed Package / App you are building on Salesforce.com. This org must, as the name suggests, be some sort of Developer Edition (DE) org. However, you have choices as to which type of Developer Edition org you can do this in, and one is better than the other:

  • Regular DE Orgs: (totally fine, but not ideal) A regular 2-user DE org such as can be acquired by going to developer.force.com
  • “Partner Developer Edition” (PDE) orgs (ideal, available to registered partners only: see step 1) A “Super-Sized” Developer Edition org, which can be obtained by registered Salesforce.com Partners by logging in to the Partner Portal, clicking “Create a Test Org”, and selecting, as the org type, “Partner Developer Edition”. This is the ideal place to develop a Managed Application for the AppExchange, as you can have up to 20 full Salesforce user licenses, and your data limits are higher than regular DE orgs’ limits, among other advantages.

Whichever of the two org types you go with, for each AppExchange Application that you would like to build, you must choose one org to be where you create your app’s corresponding “Managed Package” – the Salesforce.com application distribution mechanism. You can create a Package in Salesforce by going to Create > Packages. However, you cannot make a package “Managed” – the requirement for an AppExchange org – until you have chosen a Salesforce-unique namespace for the package, e.g. ‘acme’. Once you’ve chosen this, you’ll be able to convert your package, which contains all of your app’s custom objects, fields, Apex code, Visualforce pages/components, and many other possible metadata types, into a Managed package. Each Developer Edition org can only have one Managed Package, and namespaces cannot be migrated between orgs.

For those of you who did not know about the PDE org option, it is important to note that it is perfectly fine to have your managed-package development org be a regular DE org — there is no need for it to be a full PDE for it to be capable of publishing AppExchange apps. It just makes the development lifecycle a lot easier if you develop in a PDE.

3. Get an ISV / OEM Contract to legitimize your Salesforce.com Partnership

*WARNING*: This step takes a LONG TIME (read: MONTHS).

For those of you who are wondering why this is even necessary — why can’t I just build a managed package and then require that someone writes me a check before I give them an install link? — there are many reasons to go through the hassle. For one, the Salesforce.com Partner Program is pretty rocking — they have killer tools that you’re not going to get going with other partners like Zoho, who haven’t had the time to build up their Partner Programs as well as Salesforce.com has.  Second, you’ll find that unless you’re just writing a few apps for your company or small group of clients, the whole hand-out-install-links method just doesn’t work. At a base level, there’s no way to manage licenses, see who’s using your app, or distribute using Salesforce’s public channels (e.g. AppExchange). Basically: you NEED to go through this process, even though it’s painful. There’s some serious awesomeness at the end of the tunnel: dive in, and be patient. You’ll get through it.

Salesforce really has two Partner models, or ways you can sell your apps, described very well here: AppExchange Partner Programs and Models.

  • ISVForce (the ISV program) – you sell apps meant to be installable into most any Salesforce org. Often these are general purposes utility apps, like data cleansing apps, integration tools, user interface development tools (like Skuid!), mapping apps, etc. Under this model, existing Salesforce users can be licensed to use your ISV app in addition to whatever other apps they currently have and in addition to their existing Salesforce CRM license.
  • Force.com Embedded Edition (the OEM model) – this is for Partners who want to leverage the Force.com platform – e.g. the cloud platform, logins / roles / profiles / security, object building – everything BUT CRM Objects and Service Cloud, pretty much – as a base for an industry-specific offering, e.g. a student information system. Under this model, users come to YOU for a Salesforce license, and you give them a Platform License + your Application. They can’t access CRM Objects (e.g. Opportunities, Products) but they can access Accounts, Contacts, and the Force.com platform.

Basically, once you’re officially “in” to the Partner Program, you get all kind of power to develop killer apps, sell and manage licenses, and support your customers once they’ve subscribed.

But, getting back to the process, the first HUGE thing you get by finishing out your ISV / OEM contract is an Enterprise Edition CRM org with 2 free licenses (you can pay for more as your company grows). This is referred to variously as your CRM for Partners org, your  License Management Organization (LMO), your partner Business Org, and, as we’ll see later, it is recommended that this be your AppExchange Publishing Org (APO) as well, but it does not have to be — from here on out, I’ll refer to it as either your CRM org or your LMO, as well as your APO. In almost all cases, each company will only have one CRM/LMO org, which will be the place where you manage, for all of your company’s AppExchange applications/packages (some partners sell many different apps!), package versions, licenses, and customer relationships (e.g. Leads, Accounts, Contacts, Opportunities, etc.). Note: you MUST have an ISV / OEM Contract in place with Salesforce.com for them to provide you with this org with its two free licenses.

Once you have this org — note, you do NOT have to request this free org, you can pay full price for all of your users, but why not start with it?), immediately log a case in the Partner Portal to “Request the LMA” — this case asks Salesforce to install a special “License Management Application” (LMA), a managed package, into your CRM org. Once this is installed, congratulations, your CRM org has now also become your License Management Organization (LMO). This org will now be the place where all information about customer interactions with your apps/packages is sent, and where you should manage it. WITHOUT this app, you will be unable to use Salesforce’s license-management tools to keep track of who is doing trials of your apps, activating them once they’ve paid, adding additional licenses to orgs, using the Partner Black Tab / Subscriber Support functionality, etc.

The benefits of having this org are huge: all activity related to client interaction with the AppExchange are tracked in this org — if a client does a demo of your product, a new Lead is generated with Lead Source appropriately set to indicate that a Demo was done. If they do “Get it Now”, another Lead is generated with Lead Source set to “Package Installation”, and a new License record is created in this organization, TIED to the Lead. Once this Lead can be converted, the License records move right along into the Account and Contact, and you can do workflows on the Expiration Date / Install Date, etc.

So, for those of you stuck in Step 3, pulling your hair out, waiting for it to get finished, here are some ideas:

  1. Keep developing your app! Make it super-rocking.
  2. Along the way, get your app prepped for Security Review — put it through the the Checkmarx Security Scanner (for native apps), and all of the other security guidelines available over at security.force.com.
  3. Get involved with the Salesforce Community, whether on the LinkedIn groups, Twitter, User Groups, Developer Boards, Salesforce StackExchange, etc. — build up your non-AppExchange distribution channels.
  4. Make some help files. A great way to do this is to leverage BlueMango’s ScreenSteps technology.
  5. Take your release notes training to stay current and take advantage of upcoming features.
  6. Test your app (see Step 7) in different Salesforce.com editions, pushing out beta packages to make sure you don’t include any features that disqualify your app for inclusion in Group / Professional Edition. This can be a real lifesaver later on if you were hoping for your app to be available to these Edition types! Basically, any references to features / API objects not available to GE/PE subscribers will disquality your app from being installed into GE/PE orgs. You can often avoid these disqualifications through use of dynamic SOQL and DML, but always push out Managed Beta versions of your app and try to install them into test GE/PE orgs to make sure you didn’t miss something!

4. Link your orgs together via AppExchange

Once you have your two main orgs (1. your LMO / CRM org 2. your Managed Package Development Org), and have uploaded at least one Managed Released version of your managed package, login to the AppExchange using your Managed Package Development org credentials, click on your name in the top right corner, and click on the “Publishing Console” drop-down option.

You may be asked, immediately, to specify the credentials of the org where you want to manage licenses for your application. **Enter the credentials of your LMO/CRM org**.  At this point, a “Package” record and “Package Version” record(s) will be created in your LMO corresponding to the Package and Package Versions developed in your APO(s). If someone installs one of these Package Versions, new Lead and License records will be generated in your LMO corresponding to the installed Package Versions. NOTE: This can all happen WITHOUT having a Public AppExchange listing. You can use the LMO to activate licenses, extend trials (up to 90 days), enable Site licenses, or deactivate / suspend license records.

NOTE: Never delete License records from your LMO!!! You can’t recreate them – special magic happens on the backend that generates them, and this is non-reversible.

Now, we’re going to establish which org in our org network will play the role of AppExchange Publishing Organization / APO. To do this, go  on the “Publishing Console” area. From the main screen, click on “Your Organizations”.

YourOrganizations

You may be asked, immediately, whether your organization has done any AppExchange publishing before. If you click “Yes”, you will be asked to enter the credentials of your “AppExchange Publishing Organization / APO“. **Enter the credentials for your LMO / CRM org.** By doing this, you will define your LMO / CRM org as your APO, meaning that it is now the central place for managing all of your company’s AppExchange apps. This is recommended. It is possible for your APO to be your Managed Package Development org, but NOT recommended. If you need to change your APO, you typically are able to simply by clicking “Change my AppExchange Publishing Organization”, but if you already have a Public AppExchange release, this will not be possible – so you’ll need to  log a case in the Partner Portal, and they’ll change it for you.

Next, **link your Managed Package Development organization** by clicking “Link new Organization”. Enter the credentials of each Managed Package Development organization whose AppExchange listings and Licenses you’d like to manage through your LMO/CRM org’s umbrella.

APO_Organizations

Once this is done, you’ll be able to, by logging in to AppExchange with your LMO/CRM/APO credentials, see and manage all of your company’s AppExchange listings which you have linked to your APO! (Note: your CEO will like this! No logins to DE orgs needed, and single-sign on views are NICE. Very nice.) Just repeat this process every time you create a new AppExchange application, associating your managed package development orgs to your APO.

5. (Optional – mainly for ISV’s) Create an AppExchange listing

Login to AppExchange using your LMO/CRM/APO credentials, then go to the “Publishing” tab. Create a new Private listing corresponding to each of your Managed Apps. Part of your Private listing settings require you to choose a managed-released version of your app to associate with your package.

In order for the Listing to be changed from Private (meaning only you can see it) to Public (meaning that anyone can search AppExchange for it), your application will need to pass the Salesforce.com Security Review. To do this, click on the Package Version’s “Start Review” action. This will initiate a review process — you’ll get sent an email with a Security Review Questionnaire to fill out (not bad), which you’ll have to submit through the Partner Portal.

Once your app is Security Reviewed (usually takes 2-3 weeks for native apps if your Checkmarx report is error-free, but if you get hit for something, you’ll have to do it all over again, i.e. another 2 weeks), you’ll be able to make your app’s listing PUBLIC on AppExchange, and start earning revenue! Yay! Once customers start clicking “Get it Now”, new Leads and License records will be created in your LMO.

6. (For OEM’s using Trialforce) Create a Trialforce Management Organization

For OEM partners, who are using Force.com as a platform but are not using Salesforce.com CRM or Service Cloud objects, Trialforce is a massively powerful feature of the Force.com Partner Program. It basically lets you create your own trial environments, preconfigured exactly as you want with sample data, pre-installed packages (one or many!), metadata (e.g. reports, report types, custom settings data, public groups, you name it) — which will be used to create trial accounts for your prospective customers, saving them (and you) the hassle of having to set them up with an environment that really showcases your app in full working condition.

To start out with Trialforce, you need to create a Trialforce Management Organization (TMO): to start, create a DE / PDE org, and then go to the Partner Portal and log a case asking for this org to be made your TMO. Once this is enabled, a special “Trialforce” area will appear in the Setup menu below “Develop” and “Deploy”. This area allows you to spawn new Trialforce Master Orgs — these are the actual environments where you define the “trial templates”, from which trial orgs will be created for your customers. So to get this straight, you have ONE Trialforce Management Organization, for managing all of your one or many Trialforce Master orgs, which define the templates for your customer’s trial orgs. However, these Trialforce Management Orgs also serve another purpose, so let’s list out the two main uses of Trialforce Management Organizations:

  1. Managing all of your Trialforce Orgs: the TF Management Org allows you to create  one or many Trialforce Master Orgs, which are “template” orgs which allow you to define full Salesforce environments pre-configured with sample data and one or multiple managed applications, which users can use as starting points when they click “Try this application in a free trial environment” from AppExchange, or from a form on your company’s website (if you’d prefer not to go through AppExchange at all). You can push out multiple “Snapshots” of each Master org’s configuration, and you then can change which “Snapshot” is used to actually populate customer trials. There’s two ways to define which “Snapshot” is used:
    1. For AppExchange initiated trials: go to the Appexchange Publishing Console and select which Trial Template you’d like to use. Note: these templates have to be Security Reviewed. However, this process is generally very quick, a few days at most.
    2. For Company-website initiated trials: go to the Partner Portal, and log a case, specifying the new Trialforce snapshot to use.
  2. Managing your Custom Branding. From the Trialforce Management Organization, you can define Custom Email Branding to use with each of your Trialforce Master Orgs and define (through a slick builder) a Custom Login Site that users who started a trial using your Trialforce orgs will see INSTEAD of the default Salesforce login page.

7. Create Partner Test Organizations

From the Partner Portal’s “Create a Test Org” area, you can also create specially configured test orgs to use for validating your package internally. These orgs have special privileges:

  1. You can write APEX in them, without a Sandbox or having to do Test Coverage.
  2. You don’t have to pay for them (a plus!)
  3. They have lots of different user licenses pre-configured, like Customer Portal, Partner Portal Gold, Salesforce Platform, etc., that you can use to experiment with these features / functionalities.
  4. You can get them in any Salesforce edition type: e.g. you can create a test Group Edition org, Professional Edition org, or Enterprise Edition org. This is very useful for testing compatibility of your package with various edition’s feature restrictions.
  5. YOu can request certain features to be activated in them for internal validation: e.g. you do NOT want to enable “Advanced Currency Management” in your managed package development org if you want your package to be installable into orgs that don’t need this, but you might want your package to play well with this feature. So, to test this, get a test org, and log a case to have this feature enabled, then install your package into it and see how it works.
  6. You can install Managed – Beta packages in them.
  7. They’re great for doing demos for Customers.
  8. They come with 6 Sandboxes, including one Full sandbox, so it’s easy to quickly do Quality Assurance of new package version functionality in a sandbox of your main Customer Demo org
  9. They have a decent amount of data space — more than your DE orgs will — so you can do load testing.

8. Support your customers

As either an ISV or an OEM, once you’ve got customers who have paid for your app, either through AppExchange Checkout / Recurly or through checks in the mail / credit card / direct deposit, and you’ve activated their licenses (through your LMO), you’ll want to be able to help your customers resolve any problems they may be having. For this, the Salesforce Partner Program has a great tool called the “Subscriber Support Console”, which comes along with the LMA and as such is automatically in your LMO. From the “Subscriber Support” tab included in this app, you can see ALL customers who have installed your application – getting a summary of their org and what packages from your company they have installed, whether those packages are active / expired, when they expire, what version their on, and more!

PLUS, your customers will actually be able to Grant Login Access to your company, in addition to Salesforce.com Support and their admins, so that you can, through the Subscriber Support tab, actually log-in to a customer’s org exactly AS a customer sees it, and make changes – this is known as “Partner Black Tab” access. You will actually get special privileges – for instance the ability to see Protected Custom Settings and set special Sharing Rules – that your customers cannot see on their own.

9. Upgrade / iterate your app

Your app is probably not going to stay the same, so how do you get your existing customers onto newer versions? And what if only certain customers should be upgraded, or if you want to try out upgrades / new features on certain beta-tester customers before all folks should get it?

Fortunately, Salesforce has tools for this as well. From your managed package development org, go to Create > Packages > “Your Package Name”, and click on “Versions”. Then, click on the “Push Upgrades” button. If you haven’t yet, you’ll need to go to Partner Portal to request access to this feature set. Once it’s enabled, though, you can do the following:

  • Create Patch Development Orgs: “patch orgs” are like “branches” of a given Managed Released version (e.g. 1.24) of your package that customers may have installed. Each patch org, like their parent managed package development org, can actually create/upload package versions, however only certain components can be modified in patch orgs — no new fields, objects, or components can be added, but existing components, such as Apex code, can be modified to some extent. You can then PUSH these Patch versions to selected / all customers who are on the parent branch (e.g. you may develop a patch 1.24.1 – and then all customers on 1.24 are eligible to upgrade to 1.24.1)
  •  Push Major Upgrades: as of Winter 13, you can actually push Major Releases of your package to customers as well – so customers on 1.6 can be upgraded to 1.24 directly, automatically, in the middle of the night, with no action on your end other than scheduling it to take place. However, this possibility is NOT to be taken lightly: tread carefully, following these guidelines.
  • Manually Upgrade customer using install links: you can always take the install link from either a Patch version or a Major release version and manually install a package into a customer’s org by logging in to that org (if you have access), or having the customer log in to that org and pasting the link into the URL.

SUMMARY

Anyway, hope this was helpful. To review, do you know what these acronyms stand for now?

  • DE – a Developer Edition org, where you can develop / experiment with Salesforce functionality
  • PDE – Partner Developer Edition – a special “super-sized” development edition type appropriate for AppExchange application development
  • LMA – the License Management Application. Each Partner should have ONE org, typically their CRM for Partners org, that has this installed in it. Whatever org has this app installed is dubbed the “License Management Org” / LMO.
  • LMO – License Management Organization / Partner CRM org – where you track customers and package licenses, and support customers
  • APO – AppExchange Publishing Organization – AppExchange terminology for the org that you would like to be the AppExchange listing management hub for all of your company’s AppExchange apps/listings. As a best practice, make this your LMO/CRM  org. This will allow you to manage all of your AppExchange listings from one place.
  • TMO – Trialforce Management Organization – where you manage your company’s custom branding and create/manage your Trialforce Master Orgs
  • ISV – a Salesforce partner who is part of the ISVforce program. Typically these partners build apps for AppExchange distribution, to fit in to any Salesforce org.
  • OEM – an “Original Equipment Manufacturer”, but in the Salesforce world, a Partner who uses the Force.com Embedded Edition distribution model, selling Force.com Licenses (technically “Salesforce Platform” / AUL licenses) “embedded” in their application’s cost.
Advertisements

26 Comments

  1. Thanks for taking the time to write this up! The appexchange can be a confusing environment for an ISV.

    I wonder if you know the answer to a question we’ve been looking in to…

    Our SaaS service is sold through resellers around the world, several of which offer our software under their name in a white/private labeled model where my company is completely behind the scenes. We’re wondering if our AppExchange app can be white/private labeled as well.

    We want to change out the logo and some text in our AppExchange App to reflect our reseller’s brand rather than ours. We want our resellers to be able to offer the app to their customers without having to go through the full process (since it’s one app just rebranded). Ideally they’d have their own listing in the AppExchange…

    Do you have any knowledge in this area?

    Thanks again.

    • Michael,

      There are various ways to custom brand / private label an AppExchange Application for each customer. For one, your Application can include one or more “Apps”, as they’re called in Force.com parlance, which are really just named collections of Tabs with a unique logo that shows up in the top-left corner. If all you’re looking to do is have this logo be custom to each client, you can just sell one AppExchange Application, and then in each customer’s instance of Salesforce, you’d just need to switch out the default logo for your “App” that you include with a custom one for the particular customer.

      Now, if you’re talking about having completely custom-branded AppExchange listings, this is also possible through something called “Private Listings”. When you first setup an AppExchange app, your app will be a Private listing. Once a version of your app has gone through Security Review, and you have associated this version with the listing, you can mark this listing as “Public”, and it will be visible through the full AppExchange search engine. However, you can make many different “Private” listings, all associated with either the exact same version of your Application, or with slightly different versions of your Application, and have them all named and branded completely differently – e.g. your main app is called ‘Acme Recruiting’, but you have other re-branded versions called ‘Universal Containers Recruiting’, ‘Acme Recruiting for Healthcare’, or something like that – where the apps are all basically exactly the same, just re-branded. These “Private” listings, though, are not really private – you can search for them on Google and find them, and you can easily pass the link around or put the link to the listing on your website or something. They’re just not findable through AppExchange search. Now you could also post these white-labeled apps as “Public” listings on the AppExchange, as long as their corresponding app versions are security reviewed, but the need for / appropriateness of this would depend greatly on how many of these resellers they are and how broad their particular niche markets are, and how wide the market is for their particular white-labeled versions of your app.

      If you’re going more of the OEM route, you can also create custom-branded Salesforce.com login pages for your company so that all users of your app will see a login page with your customer login. This could be done for each of your resellers. This functionality is performed from the above-mentioned Trialforce Management Org.

      Then of course there’s the possibility that you want the core functionality of your application to be slightly different for each of your reseller-branded versions. For this, you might want to have a base version of your application and then have several reseller-specific “extension” Apps that tweak the look and feel and even functionality of the base app. This might be the way to go anyway, but it depends on your business model.

  2. Great Post, very helpfull.
    I have few questions regarding OEM licences:
    – Do they come with sandbox?
    – Can customer extend application by adding new fields on custom objects from application, changing picklist values on existing fields, create new workflows, create/change email templates, create/change language translations?
    – Can customer extend application by writing their own apex classes, triggers and pages?

    Thanks,
    Łukasz

    • Thanks Lukasz, good questions:
      1. OEM (Force.com Embedded Edition) licenses come with 1 Developer Sandbox.
      2. Yes, the customer can extend the application by creating custom objects, adding custom fields to objects in the OEM app, changing picklist values, adding workflow rules, adding translations, translating resources in the OEM app, creating new and cloning existing email templates. In general, you can’t modify packaged resources (there are a few exceptions), but you can extend them and clone them.
      3. Yes, the customer can write their own Apex classes / triggers and Visualforce Pages against objects in the app. However, beware of two things:
      (a) You cannot guarantee which Namespace’s Triggers will be executed first. For instance, if the OEM app has a before insert Trigger on the Account object, and you have written your own before insert trigger on the Account object, out of the box there’s no way to require that your before insert trigger gets executed first.
      (b) You cannot override the standard actions, other than Tab, with your own custom Visualforce Pages, for custom objects included in a managed package, e.g. if the OEM app has a “Class” object, and you make your own “EditClass” Visualforce Page, you can’t actually assign it as the Override for that object’s Edit action.

      • Thanks,
        Are you sure about “Yes, the customer can extend the application by creating custom objects” – according to documentation (http://www.salesforce.com/us/developer/docs/packagingGuide/Content/oem_user_license_comparison.htm – “End users can’t: develop applications or extend applications by creating additional custom objects”) that’s not the case, or am I missing something?

      • Lukasz, in my experience building OEM apps, yes, technically, yes, the customer can create custom objects. I think that what you are referring to is a contractual restriction — the customer is not supposed to create new custom objects, but technically, they can.

  3. Great post Zach. Any advice on analytics? I use the reports in the AppExchange Publishing Console. Is there any other way to pull data about our packages?

    • Thanks Rich. Regarding Analytics from within, are you more interested in Lead analytics, or License analytics? For Lead Analytics, my main comment would be about the “Lead Source” field, which for LMA-generated Leads can be quite cryptic. Here is an explanation of the various Lead Source values:

      1. “SFDC-DM|<YourAppName>”, e.g. “SFDC-DM|Skuid” — from AppExchange, user requested your demo video
      2. “SFDC-TD|<YourAppName>” — user did a Test Drive of your app
      3. “SFDC-IN|<YourAppName>”, e.g. “SFDC-IN|Skuid” — from AppExchange, user requested to Install your app using “Get It Now”, but may not have actually finished installing it
      4. “SFDC-IN-dup|<YourAppName>”, e.g. “SFDC-IN-dup|Skuid” — from AppExchange, user requested to Install your app using “Get It Now”, after having already done this before with the exact same credentials
      5. “Package Installation” — a user successfully installed a version of one of your Managed Packages into an org
      6. “SFDC-TS|<YourAppName>” — I have seen this before, but don’t know what it means 🙂

      Regarding License Analytics, one piece of advice I have is to setup some daily Analytics Snapshot(s) to allow you to do Trend analysis on the number of Active and Used Licenses of your packages — this is some seriously useful, and awesome, information to have.

  4. I wish I’ve found this post earlier! This made me understand much clearer and faster than most of the official documentation. Thank you for sharing!

  5. zachelrath Im developing an OEM app and will use Trialforce only since my future customers don’t have SF currently.

    My customers do business mostly in a B2C way so Person Accounts fit smoothly in the app design. But since PA dependencies ain’t possible to package then what are my alternatives?

    Alternative 1) Is it possible to enable Person Accounts on a Trialforce Master Org so when a new customer signs up he automatically gets PA enabled? And if so then another issue arises: how should I develop other component’s interactions with PA? should I develop that within TMO? is it recommended or even possible?

    Alternative 2) I’m currently working on adding custom fields (like First Name, Last Name, Birthdate) to Account so it can be used as an Individual. This can be packaged but seems kind of improvised.

    • Sebas, can’t say I have a robust answer here, as I have not managed any packages where we relied on Person Accounts. For the sake of others’ enlightenment, can you specify which particular “PA dependencies” you haven’t been able to package? Certainly the Person Account feature cannot be packaged, but if you are going to rely on it, then your Alternative 1 of enabling it in the Trialforce Master Org (TMO) makes sense, this should be possible, and yes it should cause it so that new customers’ orgs created from that TMO will automatically have Person Accounts enabled. In this scenario, developing functionality in your managed package development org that relies on Person Accounts should be fine. It is certainly possible. What this will introduce, however, is a “feature dependency” into your managed package. Users will no longer be able to install your package into an org unless the org has the Person Accounts feature. But since your users are coming through Trialforce, and their orgs should already have Person Accounts enabled via the Trialforce org, then this should be fine!

      • My technical evangelist replied this:

        “Packaging is not supported and might never be for PAs and we have found that many partners have had issues with updates/patches.”

        The alternative I’m working in is having 2 record types in Account (Individual and Business). Account has 2 custom fields (First and Last name). And I simply assign LastName__c + FirstName__c to Account.Name when Recordtype is Individual.

        What do you think?

  6. Zach, tallking about OEM apps, I’d like to know if there’s a way to avoid the Admin user to access standard objects. Most of my potential customers are independent professionals without employees. So as far as I understand, they will aquire 1 license (Admin) and thus have access to CRM objects that just confuse them. Any clues? If not, do you know how do OEM partners handle this with their customers?

    • Sebas, good question. I don’t think there’s any way for the 1 Admin user to not be a full Salesforce user license initially, and all full Salesforce user licenses will be able to interact with standard CRM objects. Moreover, many of the true “admin” permissions are only available to users / profiles who are full Salesforce users, so trying to assign your users to some other “hand-crafted” Admin profile that’s got a Salesforce Platform license is probably not going to cut it.

      • Thanks, that sounds great. My only concern is when my customer only needs one user then either he buys 1 admin license (with the cons of having access to CRM objects) or he buys 1 admin license (just to fulfill SFDC requirement) + 1 user license (to actually access my app and not have access to CRM objects)

        The second option sounds more user friendly but the price is a huge disadvantage. Although I could just charge the customer the SFDC floor price for the admin license and maybe sell it as a required bundle?

  7. Zach … huge thanks for taking the time to put this together. It’s a perfect summation of the labyrinth of steps involved in becoming a Salesforce ISV partner, but also the opportunities that it brings.

    • Thanks Glenn. Been too busy of late to post much here, so I’m glad that my older posts are still proving helpful to others!

  8. Very helpful article. My company has an app in the AppExchange but hasn’t yet signed the ISVForce agreement (I realize this isn’t common). I’m wondering if we really need the partnership. Why pay Salesforce 15% when we can sell/install/manage directly (our app is hybrid, we can manage licenses on our side)?

    Would love to hear your thoughts on this.

  9. Today I found out that Trialforce – TMOs allows you to do just one “branding profile”. What I mean by this is the following:

    In order to have a custom branding login site you have to register a domain name and upload a logo for the desktop and mobile custom branded login sites. So the domain name was easy, you just enter “mycompany” which automatically gets the suffix “.cloudforce.com”. But the logo made me doubt. Which logo should I use? My company’s or my app’s? I ended up setting my app’s logo since I believe it will be what the user expects.

    The only thing here is that the logo will be used by any app you want to promote via Trialforce. So if you’re like me with a bunch of different ideas for other cool apps this method will confuse your customers. You won’t like your App2 users to login in a page with the App1 logo, unless your apps are all part of the same family like Office. But in my case App1 and App2 are for very different markets and industries.

    I was thinking that I could get a different TMO for each new app, and just register the domain name like mycompany.myapp.cloudforce.com. But so far my technical evangelist haven’t gotten me an answer to see if this will be fine.

    Any thoughts?

  10. Hi Zach,

    I found your explanations clear and concise regarding both models (ISV vs OEM)
    Could you please tell me how non-salesforce users can access to application developped in Force.com in the OEM distribution model, as the developed application come with Force.com embedded licence (35 dollars/month), the application would run in a Force.com environment?

    Thanks

    • In both the OEM and ISV distribution model, users of your product will technically be Salesforce users, the difference is that in the OEM distribution model, your users have the Force.com embedded license (with its limitations), whereas in the ISV distribution model, you are assuming that your users already have some kind of Salesforce license (there are many, many types), and by building your ISV “app” you are just creating a new set of features that they can use when logged-in to Salesforce —- you’re extending the capabilities of their existing experience.

  11. Great detailed post. Thank you for pen this down.

    I too should have done similar (as I’ve 3 apps on AppExchange since 2 yrs now) , but didn’t had time (bla bla excuse). You have done a great job here!

    Let me know if I can be any help.

  12. Hi,

    When I login to AppExchange, I don’t see Publishing Console. Is there any changes?

    Do I need “username@partnerforce.com” credential to be able to publish applications to AppExchange?

    • @patlatus, you need to be a registered ISV Partner and have the License Management App (LMA) installed into your AppExchange Publishing Org (APO). Then, you need to login to the AppExchange using your login credentials for your APO.

      • What does it mean to be a registered ISV Partner? Do I need to pay anything? Or do I need just to wait upon 6 months or more when they review my application as Individual publisher?


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: