Get your FREE 30-day trial.
Please complete all fields.
Building a solid foundation is crucial to scaling the functionality and services a company provides – and Salesforce helps enable this concrete practice. If a company is using Salesforce, and likely many of its products and features, a pillar of this foundation will include creating a multi-instance Salesforce environment from which to build a blueprint, and to then customize for your clients.
Whether you are an independent software vendor (ISV), or just a large organization with multiple sizable clients, a multi-instance approach allows for building a very robust security and access model, leveraging a flexibility of configurations for every client or partner. At 2U, we fully embrace this multi-instance approach which allows us to leverage automation best practices while implementing customized processes to each client we support – and have learned some multi-instance hacks along the way.
For any organization, leveraging a multi-instance environment, creating a mold from which you can customize per client, is the first step, and the most important step. This multi-instance model allows for flexibility while not necessitating that every instance to be completely unique. And once that blueprint has been created, when universal changes are released, these updates should be deployed across all client environments in a mandatory wait – meaning, avoiding “partial universality” when changes are only applied to some and not all. Unless there is a conflicting reason, such as a client-customer agreement dictating otherwise, we recommend adhering to this rule.
And because a multi-instance environment requires a greater discipline of deploying changes, it will be easier to deploy with a consistent internal release schedule. Another good way to do this? Use enterprise class deployment tools. There are a few of them for the Force.com platform, and we’ve found them to be extremely valuable in dealing with deployments to several instances at once.
To make additions and updates less of a headache for you and your team, follow this rule: constantly standardize labels and API names religiously across all instances. It doesn’t seem like a big deal to change a field label in one organization and make it specific, but as you do more work within the multi-instance environment, you and your admins can start to lose understanding of the functionality — is it the same or different between organizations? Though it may seem tedious, down the road, the team will thank you for putting this basic, but necessary, processes in place.
Speaking of standardization, beyond labels – set up a separate core “blue print” which will contain all the universal functionality you have set up in every organization. Having this documented in one place will help keep your team’s sanity. And lastly, this could be very effective for breaking out new orgs. If you are an ISV Partner you could use Trialforce, or use free private AppExchange packages to distribute your universal metadata to other instances if your metadata is compatible.
In order to make Salesforce multi-instance work for you and your company, you need to have total control over cross-organization permissioning, and clearly defined access roles for different people. The Salesforce security model is very robust and you can build very detailed permissioning schemas individually in every organization. Our hack? Just make sure that at the end, it all comes up to the centralized logic of roles and permissioning. With our team, we introduced artificial Business Roles, which are represented by unified profiles and permission sets across all organizations. Field level security can - and will - be different (for example we have a lot of “org-specific” fields), but at least we can ensure that people in the same business roles in different organizations have the same level and type of access, but are privy to only the information meant for them. This also allows the team to avoid any kind of distortion when it comes to applying permissioning to new pieces of “universal” functionality.
The fact that you have multiple organizations doesn’t mean that all your teams should be “siloed” in individual Salesforce instances. We found out that some teams (e.g. tech support) are very matrix in nature, and most of their work is typically across organizations. If this is the case, then there is no reason we should force users to work in a few instances simultaneously. It’s a good idea for teams like these to build a HUB org and share data from individual instances in this compiled matrix. The current Force.com universe provides multiple ways to share data between orgs — from SF2SF and 3rd party ETL services to custom build solutions. And with this, you could create better experiences for your matrix teams, optimize use of licenses, while benefiting from having multiple-instance flexibility.
Working in a multi-instance Salesforce environment will only benefit you and your customers, and having a blueprint, universally deploying updates and chants and standardizing will ensure success. Above all, with Salesforce becoming more focused on services and solutions for multi-organization environments, keep your eye on what’s coming up, and you stand to gain from the Salesforce infrastructure you developed even more.
