Recently, Salesforce announced that it will be splitting a number of its North American customer instances. This can be an event that goes by without notice, or one that causes custom functionality to break and leaves you scrambling to put out fires without proper preparation. Below are answers to key questions and steps for how to plan for the coming instance splits.
What Is a "Split" and Why Is It Happening?
All Salesforce customers are grouped together on "nodes" or "clusters" which Salesforce calls "Customer Instances". Currently there are 22 instances serving customers in North America. When one of these instances begins to approach capacity, Salesforce will "split" one instance into multiple instances. This is to ensure proper performance and capacity across instances.
What this means for you
The split process has been done many times in the past without major issues. You should make sure that you are properly prepared for this event, however. This would be a good exercise for your company's Salesforce leaders to evaluate now, regardless of whether your instance is one of those up for the next round of splits, and on an annual basis going forward.
When you can expect this to happen
The current information from Salesforce states that we should expect the next split to occur in the April 2015 timeframe and will affect multiple instances. You can find your instance by looking at the url when you use Salesforce, which will begin with "NA" and a number. Here are the latest instances and timetables for splits from Salesforce (in order of date to be split):
+ NA11 Split: January 10, 2015
+ NA5 Instance Migration: March 7, 2015
+ NA4 Split: March 21, 2015
+ NA2 Split: April 18, 2015
+ NA6 Split: May 2, 2015
What you need to do to prepare
The most common cause for error in a split scenario is hard-coded references in your Salesforce customizations. Custom links that use a hard-coded reference to your Salesforce Instance instead of a relative link which points to whatever your current instance is when the link itself is clicked (or used by code that contains it).
Hard-coded links in code, Visualforce pages, custom buttons, email templates and other similar areas.
A hard-coded link or reference explicitly uses the full Salesforce URL to link to a page, record or other item on the Salesforce Instance. Any hard-coded references will break following the split, and as a result any other functionality that is dependent on them will also break. Best practice is to never use hard-coded references like this, and instead use relative references. Relative references use only the portion of the URL following "naxx.salesforce.com"
Example:
Instead of using a reference such as "http://na2.salesforce.com/home/home.jsp?tsid=02u40000000axXG"
use the relative reference "/home/home.jsp?tsid=02u40000000axXG"
Salesforce has recommended ways to use the Force.com IDE to find hard-coded references quickly.
Integrations to your Salesforce Instance
Integrations of many flavors, including direct API calls and middleware integrations can also use hard-coded instead of relative links. These should be verified to be relative prior to the instance split.
Integrations may need to be restarted following the split. It is recommended that these be monitored during the maintenance and restarted following the maintenance window if needed. This can be due to DNS caching causing the integration to not find the IP for the new instance following the split.
Additional custom applications that integrate with your Salesforce Instance
This is the same possible issue as integrations, and should be checked thoroughly for hard-coded references before the split.
Salesforce for Outlook
All Salesforce for Outlook users will be required to log in again following completion of the instance split.
External Links into Your Salesforce Instance
Links from other company systems such as intranets, links to specific knowledge articles or records, or any other link from an external system that uses the "http://naXX." prefix will break when you are moved to a new instance.
What you don't need to worry about
Users Logging In. Your users will use the same url to log in and should notice no change.
Links in Chatter messages. These are relative by default and should see no issues.
Communities or Portal URLs. These, like login urls, will not see any issue.
Salesforce Content or Files. Content and File references in Salesforce are relative.
Web or Email to Lead/Case. By default, links in these forms are relative, so these should cause no issue unless you have modified them.
Org ID. Your Org ID will not change.
Sandbox Environments. All of your Sandbox environments will be moved as well, and you should experience no additional interruption in service. All of the other preparations in this article would apply to any Sandbox environments individually.
How to do more to prepare
Salesforce is offered a webinar on Tuesday, December 9 to explain this all in detail (using the NA11 instance as an example). The recording of that webinar is available here.
You can also find an additional article directly from Salesforce on splits here.
As always, Summa is ready to help you in this situation. You can reach out to your Client Partner directly, or get more information at sales@summa-tech.com
