Dreamforce14 session for Architects on Multi Org and Multi-Community Collaboration

1. Multi-Org Collaboration Architecture
Richard Clark
Chief Technology Officer
@RichClark808
Success Community: Richard Clark (makepositive)

2. Abstract
• As the Salesforce customer base continues to grow year-on-year the need and
opportunity to collaborate across both internal and external Salesforce organisation
to maintain a single customer view are increasing. How can you avoid having
multiple logins across orgs, use a single Chatter feed, manage your master data
across orgs and minimise the impact of changes on your users ?
• In this session I will provide an overview of the classic use cases of multi-org and
multi-community orgs, the different architectural solutions that are available, and
provide best practice experience of when to use each.
• This session is aimed at Architects, Consultants and Business Users looking for
solutions for multi-org or multi-community deployments
2

3. Richard Clark
CTO of makepositive

4. Contents
1. What is an Org ?
2. Reasons for Multi-Org and Multi-Communities
3. Single and Multi-Org Architectures with Communities
4. Solving the Challenges
4

5. What is an Org ?
“An org in the salesforce.com vernacular is a logical instance of data and
metadata for a set of users” - Roberto Desisto (Gartner VP & Analyst)
• Confusingly we also have isolation of Chatter data by Communities
• So when it comes to collaboration across Communities, even a single Org can be
an issue
5

6. Reasons for Multi-Org
• Organic Growth
– Independent departments or divisions
– Separate Sales and Contact Centre implementations
• Mergers & Acquisitions
– No budget, no appetite to change, no single owner
• Corporate Strategy
– Autonomous business units
– Regulatory Compliance - Chinese Walls
• Separate Legal Entities
– Collaborate with Partners/Suppliers/Customers using Salesforce
6

7. Reasons for Multi-Community
• One community = Multi-Community
– Internal Org Chatter vs Community Chatter
• Customer, Partner and Company Communities
– Different groups of Customers require different Communities, different content
• Customer Segmentation
– Gold, Platinum and Diamond Customer portals
– Different brands
But!
• Some Chatter posts you want your community users to see and collaborate on too
• Many companies want all employee interaction in 1 stream, not multiple
7

8. Multi Community/Org Architectures

9. 1. Single Org – Multiple Communities
• Shared data across
communities
• Single view of the customer
• Diverse Chatter Conversations
• Employees collaborate in
multiple Chatter Feeds
Salesforce Org
9
Internal
Org
Chatter
Customer
Community
A
Partner
Community
X
Data

10. 2. Multi-Org -> Single Org Consolidation
• Strategy to lose orgs
• Careful planning required
• Good tooling for data de-dupe & automated testing
essential
• Use Hierarchical Custom Settings for individual Workflow,
Validation and Trigger business rules
• Still have the Chatter Collaboration problem
• Chatter data migration non-trivial
– e.g. Created Date for mention posts not override-able even with the
Feature Activation
Salesforce Org 1
Salesforce Org 2
10
Internal
Org
Chatter
Customer
Community
A
Partner
Community
X
Data
Internal
Org
Chatter
Partner
Community
B
Data

11. 3. Multi-Org – Master Org
• Unidirectional feed of data to parent org
for reporting
• Bi-directional feed of data for Master
Data Management (MDM)
• Can use Salesforce2Salesforce (S2S) or
Partner ETL Tools
• Cross Org Data Sharing - Pilot (COD)
• Can include Chatter posts in ETL
• Conflict Management Policy
• Complex Field Mappings
– E.g. Canonical Addresses
Salesforce Org 2
11
Salesforce Master Org
Data
Internal
Org
Chatter
Salesforce Org 1
Internal
Org
Chatter
Customer
Community
A
Partner
Community
X
Data
Internal
Org
Chatter
Customer
Community
B
Data

12. 4. Multi-Org – Cross Community Collaboration
• Different legal entities
• Why do I have to log into your
Community when I have my own
Org ?
• Collaborate across orgs and with
my partner’s customer
• MDM should still be implemented
for enterprise deployments
Company ABC
Salesforce Org 1
Org62 Success Community
• Could have a private group and restrict
access
• Still separate Chatter Streams though
12
Internal
Org
Chatter
Customer
Community
A
Partner
Community
X
Data
Internal
Org
Chatter
Company XYZ
Salesforce Org
Customer
Community
B
Data

13. Architecture When ? Challenges
1. Single Org
Centralised IT function
Consistent processes across business units
Clear record ownership
Working within data and org limits
Field Limits
Data Limits, LDV, Data Skew
Org Limits
Complex Sharing
2. Multi to Single
Org Strategy
As above plus..
Strategy for Single Org desired
Drive for consistency
As Single Org plus
Conflicting requirements
Profile proliferation
3. Master Org
Autonomous divisions/business units
Centralised Exec reporting required
Data mapping across Orgs
Record Ownership / Dupes
4. Multi Org
Autonomous divisions/business units
Autonomous IT teams and/or SF partners
Conflicting feature requirements
Collaboration with Customer or Partner SFDC Orgs
Master Data Management
Corporate Reporting
Data Silos
Which Architecture is right for you ?
In brief…

14. All these solutions have 3 common weakness
1. Disparate Chatter Conversations
– Either across Communities and/or across Orgs
– Multiple Chatter Feeds for internal users
2. Master Data Management (MDM)
– Either across Orgs or across systems in the Enterprise
3. Deployment Nightmare!
– Are you sure your portal is working ?
– Are orgs still in synch ?
– Does S2S still work after rolling out changes in one org ?
How can you solve or alleviate these issues ?
14

15. #1 Disparate Chatter Feeds

16. Multi-Community Chatter Collaboration
At makepositive we developed the following Passport applications to address these needs
• Passport Hub – Salesforce1 Platform (Heroku) Hub
• Passport Native – 100% Force.com
• Passport for Communities (P4C) – 100% Force.com
16

17. Passport Hub
Org A
Passport App
manages
Profile
Connections
Sharing rules
Other customers’
Passport Hubs
Your Passport Hub
automatically manages
Synchronisation
Identity
Connections
Encryption
Org B
Org Z

18. Passport Native
Org A
Each Org
exchanges
messages
with it’s
‘children’
Org B
Org X
Batch job to
trigger
exchange of
updates to the
next Org
Org C
Org Y
…
Org Z

19. Passport for Communities (P4C)
• Links a community to the internal Chatter
• Provides a user a single Chatter feed
• Managed package installed to the Org
• Can be combined with Passport Hub or Native
• Single or Multi-Org
• Can link multiple communities

20. How does Passport work ?
• Uses all standard objects
– So compatible with Salesforce1, Chatter Desktop and all other Chatter apps
• Creates Ghost users in each reciprocal Org
– (Communities does this OOTB for internal users)
• Users only need know 1 login
– If they use multiple already these can be connected instead of using Ghost Users
• Salesforce1 Platform API used for majority of posts
– @Mentions, Private Messages and Files must be posted by the Ghost user login
• Synchronizes selected Groups in each reciprocal Org
• Maintains a mapping between record ids across Orgs
• Only propagates the Chatter, use S2S or 3rd party ETL tool for federating other
object data
20

21. Bringing it all together…
• Passport apps can be combined to share Chatter posts across Orgs and Communities.
Org A Partner Org B
Alternatively…
• Use a single Org
• Use an ETL tool, or write your own Passport
21
Internal
Org
Chatter
Partner
Community
Internal
Org
Chatter
Passport
P4C Hub

22. Multi-Org/Multi-Community Collaboration Solutions
Solution Option Pros Cons
22
Single Org Migration
Single admin
Consistent Processes
Org Wide Analytics
Reduced Integration
Complex rules
Single set of Settings
Single set of Limits
Increased Regression test effort
No Cross Community Chatter Feed
ETL Chatter Integration
Free ETL tools
No Passport license costs!
Re-usable across multiple orgs
No @mention support
API Limits for Cross Community Posts
SF Release Tracking
Increases in complexity for each Org
Initial implementation time
Challenging to implement across legal entities
Passport + Passport for
Communities
1 day to implement
Suitable across legal entities
Includes additional Chatter Free licenses
Centralized configuration and issue
management
App Support and Release Tracking
Auto Synch to new Orgs
SF paid licenses for object chatter
Still requires S2S or ETL for Objects
Small Passport license cost per user pcm

23. Lessons Learned
• salesforce.com have been very prolific!
– User synch, Group synch, Feed Items, Comments, Polls, Likes, Attachments
– Subscriptions, Object Chatter, Group Membership, Member Requests, Mentions, Comment
Attachments, Comment Mentions
– Since DF13: Topics, Private Groups, Group Archiving, Announcements, Questions, Thanks
• Parent-Child Dependencies
– Need to manage the object dependencies across Chatter and Standard objects
• Org Limits
– Optimise your Batch jobs and implement design patterns for re-queuing jobs
• Licensing
– Chatter Free licenses can be used for Ghost Users, unless you want Object Collaboration too
then you need the right license for the type of object
23

24. Lessons Learned
• Governor Limits
– Web service callout limit affects Passport Native restricting attachments to 2.5Mb
• Workarounds to post notifications rather than Files across orgs
• Chatter Files may solve over time or host Files outside of SF and use links
– Heap size limit is 6Mb
• Quirky Chatter Notifications
– Emails for Chatter Feed not sent when posted by a ghost user. Workaround with our own
workflows, try to use digests instead of instant notifications.
• External Collaboration
– Can extend solution to Jive and Yammer
– Requires feature mapping and accept limitations of APIs
24

25. #2 Master Data Management (MDM)

26. Master Data Management
• See the ETL and MDM specific vendors in the Dreamforce Expo!
• Consider Salesforce2Salesforce (S2S) and Cross Org Data Sharing (Pilot)
• Consider Salesforce and non-Salesforce systems (e.g. ERP, ePOS)
• Focus on what is essential to manage
• Clear system of record
• Harmonize unique record identifiers
• Enforce field and record security in each org to avoid update conflicts

27. #3 Deployment Management

28. Deployment Management
Either:
1. Master Config Repository + Force.com Migration Toolkit (or 3rd party tool)
– Complex to manage but worth the effort when done well
– Challenge to keep 100% accurate
– Inflexible to local variations, conflicts in API names
– Superset: Quickly hit Org Limits for Tabs, Fields, External Ids, Master-Detail, Rich Text Areas
– Deployment hell even with Continuous Integration
– Suitable for Single Org
28
+ + =

29. Deployment Management
Or:
2. Managed Packages
– Core managed package for central functions and
data model
– Extension managed packages for specific modules
– Approved list of AppExchange Apps - Private
AppExchange
– Keep the core light, allow each Org to add additional
customizations within agreed limits
– Strongly recommend for more than 3 Orgs
29

30. Deployment Management (cont’d)
Whichever way you choose, and even if you’re single Org you still need the
following:
– Change Management Process
– Governance Team to review and accept new ideas into the Core and permitted Apps list
– Configuration Management (e.g. Git)
– Multiple sandboxes for testing, UAT and validation of deployment
– Established Deployment Process and Tools
– Automated Test Tools, such as
30

31. Provar – Test Automation for Salesforce
• Internal, Portal & Communities
• Standard, Visualforce and
mobile web/hybrid pages
• E2E API testing
• Data management
• External test validation against
RDBMS, web services and MQ
• Continuous Integration of
regression tests

32. Next Steps!
• Passport
– Go to the AppExchange http://sforce.co/1gZmVjC
• Master Data Management (MDM)
– Visit Informatica and ask about Cloud MDM
• Extract Transform & Load (ETL)
– Mulesoft, Informatica, Jitterbit, Dell Boomi, Talend and many more...
• Provar
– Visit stand N2345 in Cloud Expo North
– Or visit http://provartesting.com
Catch me tomorrow at 3pm for “Setting up the Salesforce Console in 10 Steps or Less” !

34. Q&A