As Salesforce continues to grow as a leading cloud-based CRM provider, companies are increasing their use of the...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
platform. With this growth, Salesforce server capacity is stretched beyond its original capabilities, which has led the company to acquire more servers across the globe.
As a result, Salesforce has begun splitting servers and moving some companies to the newly acquired data houses. This means some companies will switch instances for their production environment, which changes the direct URL of that instance. If a company’s Salesforce team uses best practices and does not hard-code URLs, this should be a fairly easy process. But a thorough evaluation of the instance is required to ensure this runs smoothly. Here are the steps to take if you have been notified that you are being moved to a new Salesforce server.
The Salesforce server switch
Step 1: Alert key stakeholders of this change. When an instance is switched to a new server, changes are happening rapidly both during and after the switch. It is important to identify key stakeholders and keep them updated on the process.
During the switch, any users trying to access the Salesforce platform will not be able to or will be able to access the server only in read-only mode. This could affect 24/7 contact centers that use softphones through Salesforce or log cases within Salesforce for tracking purposes. These groups need as much time as possible to identify workarounds when the Salesforce server is down, which could be up to three hours.
Additionally, any user who has saved the login to Salesforce as a homepage, rather than the login.Salesforce.com page, will not be able to access his or her account despite having used a correct email and password. IT should be made aware of this while troubleshooting potential problems once the switch is made. Also, any groups that have connections to Salesforce endpoints may need to change the endpoints should they reference the server name, such as connections to a single sign-on system.
Step 2: Identify hard-coded areas. A free application, Eclipse, can be downloaded online and synced to your instances. All you need to do is add the Salesforce plug-in after the download. This should be the only tool you need to identify where your instance is hard-coded, and it is likely your developers may already utilize this tool and can do a quick run for you.
For example, if when you log into your instance the URL is https://na9.salesforce.com, you will want to run a scan of the instance for everywhere “NA9” is referenced. For large organizations, to split your run of Eclipse, run a search on all Apex classes first, then Objects second, etc. Once you run all your searches, you will have a complete list of all areas of Salesforce where the URL has been referenced.
Areas to pay particular attention to:
- Apex classes
- Email templates
- Buttons (within each object)
- Custom settings
- Visualforce pages
Step 3: Move as much to dynamic URLs as possible. Where possible, references to the URL should be dynamics, and the actual server reference should be removed. Developers should make changes to any references within Apex code or Visualforce areas, and admins should be able to make changes to any buttons, custom settings, email templates or workflows. As is true for all development, this should be done in a lower sandbox, then tested in UAT, before anything is changed in production.
Step 4: Switch over. On the night of the switch, often scheduled during the weekend by Salesforce, any 24/7 group using Salesforce will be able to access only the instance in read-only mode. Reconnections to any third-party source, such as single sign-on or portal that was not transitioned to a dynamic reference, will need to be re-established. Additionally, any references in admin or developer areas that were not made dynamic will need to be changed. Because this can be a fairly large move for older and larger instances, teams should allocate time for full regression testing of key functionality once the switch is made.
Server switches need not be a painful undertaking if there is ample preparation from key stakeholders. The best defense is a good offense, so creating dynamic URLs from the beginning allows for less work during a Saturday night maintenance window and less likelihood of experiencing problems. Working between IT and the business once such a move is scheduled is also important for identifying all the areas that need changing and support once a switch is made.
Salesforce Wave promises ease of use, accessibility
Salesforce, Box team up to combine ECM, CRM
Is IoT Cloud already proving its value?
IoT adoption still facing hurdles