Required organizations
Several Salesforce organizations are required to develop and test your application. Salesforce DX allows you to manage many of these organizations as environments. If you are an ISV developer, 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. As stated earlier, these organizations will be used only for the purposes of learning and exploring in this book:
|
Username |
Usage |
Purpose |
|
Namespace |
In this org, we will define a unique identifier for our application, called a namespace. You can think of this as a web domain as it is also unique to your application across the Salesforce service. The namespace org must be a Developer Edition org and is free to create at https://developer.salesforce.com/. |
|
|
Salesforce DX |
Salesforce DX requires you to first connect to an org known as the Dev Hub. This org helps Salesforce and you to co-ordinate all the orgs you need for development and testing purposes. I recommend that, for this book, you use the free 30-day trial available at https://developer.salesforce.com/promotions/orgs/dx-signup. |
Table 1.1: Creating test organizations
You will have to substitute myapp and my.com (perhaps by reusing your company domain name to avoid naming conflicts) with your own values.
If you are an ISV developer, 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 or Partner Business Org (PBO) |
Your organization may already be using this org to manage 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. Eventually, when you are ready to develop your package for real, this org will also become your Salesforce DX Dev Hub. For this book, we will use a temporary Dev Hub org as described earlier. |
|
AppExchange Publishing Org (APO) |
If you are an ISV developer, this org is used to manage your use of AppExchange. We will discuss this in the Introduction to AppExchange and listings section 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) |
If you are an ISV developer, 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) |
If you are an ISV developer, Trialforce is a way to provide orgs with your preconfigured application data so that prospective customers can try out your application before buying it. It will be discussed later in this chapter. |
Table 1.2: Organization types for ISV developers
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 org, you can work with Salesforce support and your Salesforce account manager to plan and assign these orgs.
Introducing Salesforce Hyperforce
Salesforce products and services run in the cloud; updating and securing that software on your behalf is one of the major benefits of using their services. Much of what goes on behind the scenes to deliver and manage all their code and data (including the Salesforce Platform itself) for you and your users to consume is thankfully hidden from you. When Salesforce first started, it provisioned and managed its own dedicated hardware, and took to creating data centers in different regions around the world as the service grew.
Providing this service comes with a range of costs, notably the hardware itself needs to be purchased, set up, and securely managed within the data center premises. This is on top of the costs to manage the billions of lines of code and terabytes of data. Aside from the costs, choosing a region in which to set up a data center becomes an extremely critical decision when choosing new markets and regions to target next.
General purpose public cloud services, such as AWS, GCP, and Azure have matured a great deal since Salesforce first started business. This has enabled Salesforce to re-evaluate the cost benefit of running its own data centers and physical machines versus using services such as those from AWS to host its own services and products, including Salesforce Platform. Additionally, because the regions supported by such cloud services are much broader and continue to grow. This enables Salesforce to support customers with specific data residency requirements, such as the EU Operating Zone.
While there is still a huge amount of work being done to manage Salesforce services and products, building on the investment made by public cloud services is a big advantage to Salesforce. Salesforce has taken this as an opportunity to create a base infrastructure for all its services and products to move to in the future – creating even more consistency in regional needs and indeed efficiency for their own developers building across their portfolio. At the time of publication, Salesforce still has a mixture of traditional data centers and new Salesforce Hyperforce infrastructure.
What is amazing is that the Salesforce products and Salesforce Platform continue to behave in the same way regardless of the hosting approach. As there are no additional features enabled by running an org on Hyperforce, this book will not go into further detail on Hyperforce. However, do be aware not all of Salesforce’s products, services, and in some cases, features are available. This is a changing situation, of course, so you and/or your customers should work carefully with Salesforce on your product and regional needs. This, however, is only an interim situation, in the future all of Salesforce will run on Hyperforce.