Reader small image

You're reading from  Force.com Enterprise Architecture - Second Edition

Product typeBook
Published inMar 2017
Reading LevelIntermediate
PublisherPackt
ISBN-139781786463685
Edition2nd Edition
Languages
Right arrow
Author (1)
Andrew Fawcett
Andrew Fawcett
author image
Andrew Fawcett

Andrew Fawcett has over 30 years of experience holding several software development-related roles with a focus around enterprise-level product architecture. He is experienced in managing all aspects of the software development life cycle across various technology platforms, frameworks, industry design patterns, and methodologies. He is currently a VP, Product Management, and a Salesforce Certified Platform Developer II at Salesforce. He is responsible for several key platform features and emergent products for Salesforce. He is an avid blogger, open source contributor and project owner, and an experienced speaker. He loves watching movies, Formula 1 motor racing, and building Lego!
Read more about Andrew Fawcett

Right arrow

Required organizations


Several Salesforce organizations are required to develop, package, and test your application. You can sign up for these organizations at https://developer.salesforce.com/. Though in due course, as your relationship with Salesforce becomes more formal, you will have the option of accessing their Partner Portal website to create organizations of different types and capabilities. We will discuss this in more detail later.

It's a good idea to have some kind of naming convention to keep track of the different organizations and logins. Use the following table as a guide and create the following organizations via https://developer.salesforce.com/. As stated earlier, these organizations will be used only for the purposes of learning and exploring throughout this book:

Username

Usage

Purpose

myapp@packaging.my.com

Packaging

Though we will perform initial work in this org, it will eventually be reserved solely for assembling and uploading a release.

myapp@testing.my.com

Testing

In this org, we will install the application and test upgrades. You may want to create several of these in practice, via the Partner Portal website described later in this chapter.

myapp@dev.my.com

Developing

In a later chapter, we will shift development of the application into this org, leaving the packaging org to focus only on packaging.

Note

You will have to substitute myapp and my.com (perhaps by reusing your company domain name to avoid naming conflicts) with your own values. You should take the time to familiarize yourself with andyapp@packaging.andyinthecloud.com.

The following are other organization types that you will eventually need in order to manage the publication and licensing of your application. However, they are not needed to complete the chapters in this book:

Usage

Purpose

Production/CRM Org

Your organization may already be using this org for managing contacts, leads, opportunities, cases, and other CRM objects. Make sure that you have the complete authority to make changes, if any, to this org since this is where you run your business. If you do not have such an org, you can request one via the Partner Program website described later in this chapter by requesting (via a case) a CRM ISV org. Even if you choose to not fully adopt Salesforce for this part of your business, this type of org is still required when it comes to utilizing the licensing aspects of the platform.

AppExchange Publishing Org (APO)

This org is used to manage your use of AppExchange. We will discuss this a little later in this chapter. This org is actually the same Salesforce org you designate as your production org, and is where you conduct your sales and support activities from.

License Management Org (LMO)

Within this organization, you can track who installs your application (as leads), the licenses you grant them, and for how long. It is recommended that this is the same org as the APO described earlier.

Trialforce Management Org (TMO) and

Trialforce Source Org (TSO)

Trialforce is a way to provide orgs with your preconfigured application data so that prospective customers can try out your application before buying. It will be discussed later in this chapter.

Typically, the LMO and APO can be the same as your primary Salesforce production org, which allows you to track all your leads and future opportunities in the same place. This leads to the rule of APO = LMO = production org. Though neither of them should be your actual developer or test orgs, you can work with Salesforce support and your Salesforce account manager to plan and assign these orgs.

Previous PageNext Page
You have been reading a chapter from
Force.com Enterprise Architecture - Second Edition
Published in: Mar 2017Publisher: PacktISBN-13: 9781786463685
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
undefined
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at £13.99/month. Cancel anytime

Author (1)

author image
Andrew Fawcett

Andrew Fawcett has over 30 years of experience holding several software development-related roles with a focus around enterprise-level product architecture. He is experienced in managing all aspects of the software development life cycle across various technology platforms, frameworks, industry design patterns, and methodologies. He is currently a VP, Product Management, and a Salesforce Certified Platform Developer II at Salesforce. He is responsible for several key platform features and emergent products for Salesforce. He is an avid blogger, open source contributor and project owner, and an experienced speaker. He loves watching movies, Formula 1 motor racing, and building Lego!
Read more about Andrew Fawcett