dreamforce14 multi org collaboration architecture
DESCRIPTION
Dreamforce14 session for Architects on Multi Org and Multi-Community CollaborationTRANSCRIPT
Multi-Org Collaboration ArchitectureRichard Clark
Chief Technology Officer
@RichClark808
Success Community: Richard Clark (makepositive)
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
Richard ClarkCTO of makepositive
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
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
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
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
Multi Community/Org Architectures
1. Single Org – Multiple Communities• Shared data across communities
• Single view of the customer• Diverse Chatter Conversations• Employees collaborate in multiple Chatter Feeds
9
InternalOrg
Chatter
CustomerCommunity
A
PartnerCommunity
X
Data
Salesforce Org
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
10
InternalOrg
Chatter
CustomerCommunity
A
PartnerCommunity
X
Data
Salesforce Org 1
InternalOrg
Chatter
PartnerCommunity
B
Data
Salesforce Org 2
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
11
Data
Salesforce Master OrgInternal
Org Chatter
InternalOrg
Chatter
CustomerCommunity
A
PartnerCommunity
X
Data
Salesforce Org 1
InternalOrg
Chatter
CustomerCommunity
B
Data
Salesforce Org 2
• 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
4. Multi-Org – Cross Community Collaboration
Org62 Success Community• Could have a private group and restrict
access• Still separate Chatter Streams though
12
InternalOrg
Chatter
CustomerCommunity
A
PartnerCommunity
X
Data
Company ABC Salesforce Org 1
InternalOrg
Chatter
CustomerCommunity
B
Data
Company XYZSalesforce Org
Architecture When ? Challenges
1. Single Org
Centralised IT functionConsistent processes across business units
Clear record ownershipWorking within data and org limits
Field LimitsData Limits, LDV, Data Skew
Org LimitsComplex Sharing
2. Multi to Single Org Strategy
As above plus..Strategy for Single Org desired
Drive for consistency
As Single Org plusConflicting requirements
Profile proliferation
3. Master OrgAutonomous divisions/business unitsCentralised Exec reporting required
Data mapping across OrgsRecord Ownership / Dupes
4. Multi Org
Autonomous divisions/business unitsAutonomous IT teams and/or SF partners
Conflicting feature requirementsCollaboration with Customer or Partner SFDC Orgs
Master Data ManagementCorporate Reporting
Data Silos
Which Architecture is right for you ?In brief…
All these solutions have 3 common weakness1. 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
#1 Disparate Chatter Feeds
Multi-Community Chatter CollaborationAt 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
Org A
Passport App
managesProfile
ConnectionsSharing
rules
Your Passport Hubautomatically
managesSynchronisation
IdentityConnectionsEncryption
Other customers’Passport Hubs
Org B
Org Z
Passport Hub
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
…
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
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
Bringing it all together…• Passport apps can be combined to share Chatter posts across Orgs and Communities.
Alternatively… • Use a single Org• Use an ETL tool, or write your own Passport
21
Internal Org
Chatter
Org A Partner Org B
Partner Community
Internal Org
Chatter
Passport HubP4C
22
Multi-Org/Multi-Community Collaboration Solutions
Solution Option Pros Cons
Single Org Migration
Single adminConsistent Processes
Org Wide AnalyticsReduced Integration
Complex rulesSingle set of SettingsSingle set of Limits
Increased Regression test effortNo Cross Community Chatter Feed
ETL Chatter IntegrationFree ETL tools
No Passport license costs!Re-usable across multiple orgs
No @mention supportAPI Limits for Cross Community Posts
SF Release TrackingIncreases in complexity for each Org
Initial implementation timeChallenging to implement across legal entities
Passport + Passport for Communities
1 day to implementSuitable across legal entities
Includes additional Chatter Free licensesCentralized configuration and issue
managementApp Support and Release Tracking
Auto Synch to new Orgs
SF paid licenses for object chatterStill requires S2S or ETL for Objects
Small Passport license cost per user pcm
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
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
#2 Master Data Management (MDM)
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
#3 Deployment Management
Deployment ManagementEither:
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
+ =+
Deployment ManagementOr:
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
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
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
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” !
Q&A