Dreamforce14 Multi Org Collaboration Architecture

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