Cheat-Sheet: Org Strategy

Choosing the right Org-Strategy is one of the hardest decisions to make during your CTA review board.
The org strategy has an impact on almost everything else.
Over our time of preparation, we created a small cheat-sheet about Org-Strategy.
As always, meant as a starting point for your own research.
Let me know your thoughts.

Table of Contents

Org Strategy Decision Guide 

Provided Tohar Patel

 Requirement/Use CaseSingle OrgMulti OrgWeight
R-001Are there any regulatory, compliance,security or Sharing requirements ?    ✔Critical
R-002Single Business with global process standard and global data access ( unification)  ✔ High
R-003Independent but similar business units ( Replication) High
R-004Unique Business units with a need to know each others transaction(Coordination) High
R-005Independent business units with different customers and expertise ( Diversification) ( aka autonomy) High
R-006Are there any Customer 360 or global case management or global business reporting requirements? Medium
R-007Merger & Acquisition  -> Review (R-0002 – R-0006)NANANA
R-008Have you reached the hard governor limits of what you can do in a single org? Critical
R-009Will you be using Chatter? Low
R-010Are you prepared to deal with the complexity of having multiple LOBs (Lines of Business)/Regions inside a single Org? High
R-011How many Lines of Business/Regions/Locations can you support? ( time to market) Low
R-012How much change can you effectively manage in a single org? ( predictability of delivery) Low
R-013Large number of Integrations with backend systems/ master data Med
R-014Are you willing to pay for the overhead of multiple orgs? ( cost) Low
R-015Who will modify your org(s) & who will maintain your org(s)? ( multiple distributed dev and Support team) Low

Introduction

An org strategy is a plan of how to best use Salesforce with your business. It outlines the underlying org architecture that will be used in your Salesforce solution. Two possible approaches:

  • Single-Org
  • Multi-Org

The multi-org strategy can be declined in different approaches:

  1. Complete Autonomy
    1. each organization is not directly linked to each other environment
  2. Master Child
    1. a master org pushes a subset of data to all child linking organizations 
  3. No centralized org
    1. each organization is directly linked to other organizations using Salesforce2Salesforce integration for exchanging and updating data

Consolidated – Single Org

Confederated – Multi Org

Federated –  Single Org – Unlocked packages

Hybrid – Multi Org

Links:

https://www.linkedin.com/pulse/salesforce-org-strategy-single-sumit-jain

https://www.linkedin.com/pulse/salesforce-org-strategy-multiple-sumit-jain

Factors to consider

People

Is there a overlap of people in different BUs which you consider to split up?

Examples: Candidates are support teams or management.

Process

Do you have many cross BU business processes which are tightly integrated?

Examples: Sales and fulfillment team are working hand in hand.

Data

Do you have data which is shared between different BUs?

Example: Cross national corporations. Sales people need to see all active contracts regarding region.

Technical constraints

Any technical constraints which make you use multi-org. Mostly around SF limits like Community User, Records in Objects…

Do you have data residency requirements? Examples are Russia or China.

Implications Org Strategy

Governance

Single Org Strategy

Only one COE and development team required.

Separation and coordination of development teams within that org might be more complex.

Only a limited number of parallel work streams can be handled within a single org.

Multi Org Strategy

One global COE for all Orgs. Common business architecture and standards across all orgs.

Local governance committees for each org. Individual product management, directions and priorities within that org. RACI matrix per org.

Org specific Architectural review board (but follow global standards). Tiered admin team local changes.

Reporting

Single Org Strategy

Customer 360 reporting supported. Simple reporting available.

Multi Org Strategy

Centralized point for Cross-Org reporting necessary. DWH or Einstein Analytics necessary to facilitate cross org reporting. Data standardized and linked.

Development

Packaging, Best Practices and Standards, Support (Local vs. Global)

Single Org Strategy

Hard to keep multiple Development teams from clashing with each other in one org if they Support multiple LOBs. Especially “Hot objects” like Account or Task will be affected.

Strict Guidelines and architectural rules have to be implemented. Definition of fields (Glossary) necessary.

Performance and limits can be suffering since lots of logic in form of PBs an so forth might be invoked.

Strict logic entry criteria for each object necessary. 

  • Trigger framework mandatory!

Multi Org Strategy

Each Org can focus on it’s own logic. Core packages like Trigger Framework, Data factory and so forth should be provided.

Global COE sets guidelines around development. All Orgs should follow same CI/CD process.

Certain Data has to be synchronized across orgs like Country Picklists, Discount rules and so forth.

Identity & Security

Single Org Strategy

All users are within the same org. Management of Profiles and Permission sets as well as sharing has to be focused on a lot. Might become tricky or even impossible.

Multi Org Strategy

Easier to implement (complex) sharing and security requirements.

Identity Connect can support multiple Orgs in parallel.

Some Users might need to use multiple Orgs. Users have to be aware which org to go to. Deep linking (SP Initiated Login) helpful.

Data visibility and access need to be considered separately.

Enterprise Architecture (Integrations)

Single Org Strategy

Simple Architecture, straight forward.

Multi Org Strategy

Strong integration architecture between SF orgs is necessary.

Can leverage a “Hub & Spoke” model where Heroku with Heroku connect works as the Hub.

Cross Org Data needs to be identified and provided for subsequent orgs.

Cross-Org Customer ID necessary.

Duplicates must be identified across orgs via ESB.

MDM Concepts: Registry or Consolidation.

Depending on the Use case you want to be aware of the records in the other system (Registry) or even consolidate data to create a golden record.

https://blog.stibosystems.com/4-common-master-data-management-implementation-styles

Example Questions

Which countries have strict regulations around data residency?

Russian and China.

Which countries can Salesforce provide a local server?

Canada (AWS?), USA, England, Germany, France,  Japan, Australia (AWS?), China (Alibaba?)

What are the implications on second level support in a multi org environment?

Second level support must be either separated by Org or be included in development, architecture and release of both Orgs.

How do you facilitate cross-org in Einstein Analytics?

EA has a Multi-Org Adapter. You can create one local and multiple external orgs. You can add actions also for multiple Orgs.

Does Quip work with multiple orgs?

Yes. You can add as many Orgs to Quip as you want.

Quip supports SAML with Salesforce for SSO. Salesforce acts as the IDP.

Quip Documents are handled as external Data Source in Salesforce (?)

How can you handle Cross-Org customer data?

You have to identify the customers as cross-org customers. Then you give them a common identifier across orgs like “Customer Id”.

Then you either inform each other org about the customer being here, create one master org or create a two way synching mechanism.

How to integrate Marketing Cloud with Multi-Orgs

One Marketing Cloud Business Unit can only connect to one Salesforce Org.

Documents:

https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy.html

Example Justification Org-Strategy

This justification is not meant to be a solution key but rather show the thought process.

This justification is maybe 60% correct, still a couple of topics like MDM, Global reporting and so forth missing.

Scenario: Universal Safety Technologies

I’d like to recommend for this scenario a multi org strategy. The main factors, which points me to this decision, are (sequence based on the impact on my decision):

1. data residency (page 4, point 4 a: “Due to regulatory requirements for fire and safety systems, the ERP implementations in the U.S. and Canada have very different order management processes and data requirements. For this reason, they have remained separate.”)

2. visibility requirements: only 15 users from HQ must have access to all data, even support is separated by country (page 9: “7. Support center representatives should be able to see all data within their geography only (U.S. or Canada) except for customer financial data.”), so only for these 15 users we have to pay twice for their user licenses

3. IT teams’ separation (page 9: “2. UST has geographically separate IT teams responsible for the two ERP systems (US and Canada) and the three monitoring systems. The ERP teams in particular have operated with a great deal of autonomy.”)

4. due to the fact that we have 2 ERPs, I’m expecting some potential differences in local business processes

Based on these factors, business operation model (coordination, unification, diversification, replication) looks for me like fitting “replication” quadrant, and the org strategy is going to be “separate” (due to data residency requirements).