Multi-Org Collaboration Architecture Solutions

so thank you everyone for coming along to this session on multi-org collaboration architecture I hope you understand what that means if you don’t I hope you understand what that means by the time I finish my name is Richard Clark I’m the chief technology officer from make a positive a UK is V and s I’d partner back in saying Mia if you want to contact me after the session today you can reach me on Twitter rich Clark 808 or better still via the success community is out there let’s use it among all the Richard Clarke’s most of them are me but the one you want to reach – they make a positive one so today what I’m going to talk about is I’m looking at the fact that with Salesforce it’s no longer a CRM only tool and that’s that customer base for Salesforce grows year-on-year we need to collaborate more and more both internally and externally with other Salesforce users we need that single customer view that we’re so elusive that we’re all looking for both internally and again when we share data our partners we need to have that single customer view one source of the truth we need to avoid having multiple logins across orgs ok I think we all suffer that problem when we work on different people’s communities or work even with your own orgs it’s quite painful having the multiple logins and ideally I’d like to have a single chatter feed for all the Salesforce orgs I’m a member of and we want to make sure all my master data across all those orgs is managed for me and we want to minimize impact on users when we change it so I’m going to talk about the classic news cases of multi org and multi community so even if you’re a single org you still face some problems with multi community which I’m going to tackle I’m going to talk about the different architectural solutions are available and some best press practice experience of when to use each and this session is aimed at architects consultants and business users looking for solutions for multi org or multi community if you’re a developer and you’re looking for hints and tips on API api’s you want to use and things like that I’m not there to ask those questions but feel free to post them and I can get back to you with the answers so say CTO make positive I’m certified admin sales service cloud and developer also run a team of architects that make where we have some certified TAS as well and looking to grow that over the next year so first I’m gonna talk about what is an org I’m then going to talk about the reasons for multi and organ multi communities and talk about the single of multi-org architectures when it comes to communities and then from the problems that raises I’m going to talk about how we can solve some of those challenges so firstly I want to define what is an org seems like a simple question but when I typed into Google I got a number different responses none of them are very clear this one from Roberto desist though from Gartner I did like because it’s very succinct it didn’t mention the word multi-tenant anywhere so it was a addressable by all people I feel so an org is a in the southwest vernacular is a logical instance of death data and metadata for a set of users now in that sense I think when it comes to communities you have also an isolation of chatter data obviously we have the same meta data but we also have isolation of data for communities so I very much treat communities as mini orgs and we’ll see that within the architectures that I do here so it where’s can collaboration across communities even a single org can be an issue that I’m trying to tackle so why do we have multi orgs well the classic use cases are organic growth so we have a company independent departments or divisions over the last 15 years each of acquired or started using Salesforce for their own purposes and then within that organization you tend to find this there’s more and more instances of Salesforce each doing different things also we see often a organization their sales and contact center divisions are very separate and each has put in place their own version of Salesforce with their own settings and configuration obviously mergers and acquisitions when two companies come together you throw an acquisition or a merger there’s often no budget no appetite to change and no single owner who’s all gives it when we had two orgs which all wins so you often find that both orgs still survive that merger and then we have corporate strategies there may be very good reasons that we want to keep our business units autonomous that we don’t want to all be in one Salesforce org because what different requirements or there may be regulatory reasons so like in the UK the electricity industry the distributor and supply parts need to stay separate they need Chinese walls between their data and then finally they are most with different companies each of us is different legal entity we each have sales force their own reasons but it doesn’t mean we shouldn’t be collaborating as partners suppliers and customers using Salesforce and similarly for multi community so that what are the reasons for that well as soon as you enable communities you have multi communities because you have this internal this default community for internal users today when you use chatter so if you enable one customer

community you’re already facing the multi community problem and obviously with our customers partners and companies we have different groups some needing different communities and purposes you won’t put your partners in the same community to your customers you have different content want to show those and even on a customer community you have different segmentation so you may have a gold platinum diamond customer portals different features different brands potentially as well within each of those customer portals there may be very good reasons to have separate communities but there are some chatter posts though that you want all your community users or groups of those users to see and collaborate with to and many customers one employee interaction in one stream not multiple I’m going talk some more about this and the problem we have so first I’m going to address the architectures so we see here I have a very simple relative simple single org with some additional communities so we’ve got our internal wall chatter over here we’ve got customer community and a partner community and we’ve got our Salesforce data that’s shared across those so that’s good so we’ve got our single view of the customer however we’ve got diverse chatter conversations happening so if you look on the left here my fictional company better POC in my internal stream I have a couple of automated posts about groups are created but for my same user taken at the same time well in my customer community some ones that mentioned in me and having a conversation with me the only reason I know about that is if I switch into that community and look or I have email alerts on and personally I really hate email was anyone make positive can tell you so when we have multi-org one of the options we have is to move towards a single or consolidation this is a very acceptable and valid pattern to take so when you have a company that has a strategy to combine their multiples into one this is this is basically doing self absorbed to here with his own chatter and community has been merged into org number one it’s really important you take careful planning around this it’s really important to use good tooling for deduplication of data and automated testing and I’d also recommend you consider things like hierarchical custom settings I believe there’s a session this week on that to make sure that your workflows validation rules triggers and I guess flow triggers as well now each customize the cortege requirements so you will have processes from org to that you can’t just push into org one so let have let you have that differentiation let you control by profile or by user your business processes by each group however we still have that same problem with a chatted collaboration we still have three communities here okay and we still have three feeds to look at and if you want to migrate chatter data from this community or this org that’s not a simple thing to do one of the known issues is if you try to move say a mentioned post the creative date for that post you can’t just set through a data loader even if you have the feature activation from Salesforce thirdly we have a multi org master org approach again a very acceptable pattern a lot of companies address this so we have a master org at the top here where we have all our corporate data feeding into that for reporting we may also be using it for master data management so it could be unidirectional feed from each of our orgs up to our master org for reporting or we may be using it for MDM have bi-directional feed of data flow in both ways with the truth about the customer account customer master key account management from the master org now you can use Salesforce to Salesforce for doing this data replication and you can use the punt ETL tools many of them at Dreamforce this week and there is also the cross org data sharing which I think it’s now out of pilot I’ll check that the crosswalk data sharing allows you to the master org with the readwrite copy of account and custom objects and then your other all’s have copies of that read-only mode slightly different to sales with the Salesforce if you’re using an ETL solution for federating your data then you can include chatter post in that so you could yourself make sure you tack with that problem with the chatter data and move the feed items and the comments etc between orgs regardless of which data you’re moving you need to may have a very strict conflict management policy so what happens if you have both of these also able to update the same record where it’s chatter data or an account what happens if one of them the mount both orgs make changes at the same time who wins that and then if you’ve decided how you’re going to control that how did you inform the other person that their changes were lost you also have to consider your field mappings so field map something very complex in or gwanghui maybe in a mere org and we have address line 1 2 3 4 5 or some custom fields the same logical data mates exist in our US org as a street city state zip code seems like a simple mapping but of course they’re not going to fit so it’s important before you do this you tackles

things like canonical addresses you make sure you standardize your data model as much as you can before you attempt this ok and finally we have a multi org cross community collaboration so this could be organizations where each Orkneys to be maintained individually or it could be different legal entities so each of us in this room are in the situation if we want to collaborate we have our own orgs which we want to control we don’t want to anyone else imposing changes on us but we do want to still collaborate have conversations so why do I have to look at your community when I have my own org so if I’m over here in my org and I’m also part your customer community why is it that I have to go to your org and log into your community when I want to have a conversation with you you still need to think of MDM so there may be a need to make sure that you’ve got answer the data especially your partner network to make sure accounts and contacts are shared even cases and the examples of this you think about it today when you go on to the success community you’re actually logging into all 62 which is seamless in terms of sign-on but it’s still a separate chatter feed isn’t it you go in there and have conversations you collaborate separate to your daily work in your own org their separate chatter streams so which of these is right for you so the first one the single log just to summarize where the centralized IT functions so if your IT is within the company and you’ve got a single team then the single org will work very well for you make sure you have across your business units consistent processes you don’t want to have lots of complexity lots of rules make sure you have clear record ownership who owns the record who’s the account owner who’s just on the account team and also you need to work within the you limit so there are some settings and org limits that you can’t change they may be flexible but there’s still limitations you’ll place it on yourself a number of batch jobs for example so in the challenges you’ve got the field sets you’ve got the data limits your think back things like large data volumes if you’ve got a hundred million records you’re probably not going to suit a single org on that object you have to think about things like data skew that’s where you have say a master detail relationship and you have more than 10,000 child records that parent the org limits already mentioned too and if you have really complex sharing rules showing rules are a very expensive computation if you’re having to do really complex sharing that you may actually be better off for multiple walls if you have multiples today you want to move to a single strategy obviously we have the same pros and cons but what you need is also to make sure that strategy is desired that everyone’s bought into that because if they aren’t it’s going to fail you need that drive for consistency across the organization again on the challenges you will have conflicting requirements and you will have quite hard to say profile proliferation so that means so many times I’ve seen people do the multi to single org and what there’s nice care across all the same profiles because they understand what they are you’re going to and all this 250 profiles that’s just not maintainable so if you’re going to merge your orgs look at your profiles make sure you rationalize them make sure you get the permission sets out you need make sure you re invest your time in your profiles finally a thirdly if you have master org so if your business units are autonomous if they act independently have different requirements then you probably need to keep them in their own org still but you still have this requirement for a centralized reporting and you don’t want to just pull it all out into a bi warehouse I think we’re see this week with analytics cloud as well even more appropriate to use this solution are the challenges that is that data mapping I mentioned across orgs and the record ownership who owns the record which August the master of it what happens if there’s any changes how do we manage duplicates across those orbs how do we control that and then finally the multi org so again if you’re autonomous units they have independent IT teams or different Salesforce partners as their suppliers you have conflicting feature requirements so one come one partners division once use chatter one part dozen one division wants to use a certain custom setting or certain setting and number one dozen so also if you want to collaborate with your customers and partners own August and you’re in this multi org scenario you can still be one of these as well but when it comes to your external network your multi org so the challenges are the same around that master data management the corporate reporting becomes a headache you have to start look at those BI tools and you have to beware that you’re gonna have these data silos so each of those four solutions have three common weaknesses though we have the disparate chatter conversations either across communities or across orbs and we have multiple chatter feeds for our internal users we also have to tackle the problem with master data management and we need to worry about deployment so as soon as you have multi org object on the place as much a single org need to make sure your portals still working when you make a change you need to make sure your alter still sync when I deploy a validation rule or a change

set one org is myself what’s the Salesforce still working how do I check that so how can you solve and alleviate those issues that’s the point of today so the first one we’re going to concentrate on so this was about collaboration after all so multi community chatter collaboration so that make positive we developed an application about three years ago called passport and it was the first application that was taken chatter across alt and bringing it together and we end up now we call it application passport hub it runs on the Salesforce one platform using Heroku and hub-and-spoke architecture propagating messages between different salesforce orgs we then develop some could possible native because about 18 months ago we had demand for versions of passport they were running completely on force comm there were large enterprises who weren’t happy to use Heroku for what of reasons at the time they were demanding that we do something that was native and that was a real challenge that was really really hard to get that working with in the governor limits and I’ll explain how we did that and then finally last year a prospect approached us they like what we’re doing with passport but they had a bigger problem with the community collaboration so we came up with possible communities and I’m happy to say now that I think we’re like with that customer and it’s working very well for them and again it’s 100% post complication now I was going to demo passport but whenever I try and demo this all you see is chatter so it all works exactly the same as chat works all we’re doing is stuff in the backend so here in this example we have Johnny Bainbridge and we see after his name is Amir he’s from our Mia org and he’s having a conversation with water in my org in our local or here and there collaborated in one feed even though they’re working on the different orgs and over here we have similarly we have a group that’s been synchronized the Amir group synchronized into our asia-pac gorg and the reason we can tell that is we badge with passport logos anything that’s come from a separate org you see here Johnny’s got a badge on him and here we have the group of a badge again we can collaborate individual groups we can select across feeds diving into more detail so passport hub let’s say uses Heroku so the hub automatically manages the synchronization of those groups and those users every time a new user is added every time a new group is added if it’s included with passport it will federated cross those orgs whenever you connect a new org up as well the hub will notice that once it’s connected and it will start an immediate data sync of all the past chatter messages that are in scope within each org we have a managed package we install and that takes care of the profiles the connections and the sharing rules but data for the passport native the 100% solution we had to take a different approach so we couldn’t use the same solution we couldn’t use a hub-and-spoke architecture like we did before because having a individual Salesforce org just for that purpose would be probably prohibitive for most customers and we’re faced with the issues with governor limits could we still do that and we decided we couldn’t so we came up with a peer-to-peer model and on that PHP model we were able to deploy any all can be connected to help to two other orgs and again governor limits restricts us but other ways you can see that kind of quite complex out architecture so what we have here is all gays just happy to start the chain it has a batch job and when that runs that triggers updates so it tooks the next organ the Train it says these are my messages for you since we last talked and can I have your messages when that fires also then kicks of an asynchronous job on or B which will then communicate with the people down extreme and bring messages back so it doesn’t wait on a minute basis to go all the way across the whole set of orgs it will communicate within a few minutes every chatter message okay and they’re finally possible for communities so possible communities are links a community to the internal chatter it seems like it’s quite easy but it’s surprising how hard this is to do it provides a user a single chatter feed that’s the whole point of it so within my one feed I can have all my interactions with all my customers all my partners all my internal users it works as a managed package installed to the org and you can combine it with the hub and the native solutions and it works therefore with both single or multi org you can also link multiple communities up so if you have a partner and a customer community or several customer communities we can link it all together with the internal community to propagate messages so how does it work so passport uses all standard objects all the versions of passport I said about so it’s compatible with Salesforce one it’s compatible chatter desktop and there any other chatter applications that you use within each org we create what we call ghost user now a standard this uses a chat a free license and on the passport hub product for example don’t worry about running out passport free licenses because that comes with possible free users you need to have those ghost users so communities actually interestingly uses those ghost

users out the box all your internal users have these ghost users already within the communities so very pleased that Salesforce copied our design for that your users importantly only need one login okay if they have multiple users already we can connect those up so if you have login to the mirror org and a login to the age of PAC org we can connect those instead of using ghost users and you can jump between orgs if you want to actually work on the data but if you just want to have conversations you can kind of converse across any of those chatter feeds most of the posts that we cover and we talk more about that are using the Salesforce one platform API very pleased Salesforce combined that last year into one API key slots easier to talk about than the seven or eight API that that used to be called but there are some posts that we can’t do using the API so when it comes through an app mention post there isn’t actually an API easily to do that we have to use the ghost user and act as that user to parent make that post similarly private messages and files we have to post those as those ghost users groups are synchronized across each reciprocal org and you have a central management of which groups you want to see synchronized across those and it maintains a rep mapping between record IDs so we have something called object collaboration so wild password doesn’t federal object data the only federated chatter data if that chatter is on a account an opportunity or a case then it will make sure when it moves that chatter post across it reconnects it with the mapping of the same object ID but if you’re using ETL or or salesperson Salesforce so bring it all together possible applications can be combined to share posts across odds and communities so over here we have the partner community and we use impossible for communities to synchronize that with our internal org but we also have possible hub here so in our partner or B we’re also exchanging messages with those guys now alternatives to that you can use a single org you can also use an tl tool to do this yourself you don’t have to buy passport or you could write your own passport but I want to talk you out of that if I can single migration so if you go for a single migration again you’ve got the single admin you’ve got consistent processes you’ve got your Albright Analytics it’s a good solution it reduces massively reduces your integration single can’t be forgotten about but you have got those complex rules that covered earlier you’ve got a single set of settings single set of limits and you haven’t really increased the regression test effort that you have to think about when you make a change it could break a lot of parts these still haven’t solved the cross community chatted over the single org with the ETL integration so there are free ETL tools out there that’s good news so you can do it yourself without much cost you don’t have to pay for passport that’s probably attractive to you guys and you can reuse it across multiple walks however there’s certain things you can’t do and we’ve investigated this originally is one of their options you can’t do things like the app mentioned support so some post an app mentioned chapter message you can post it as a text message another org but they won’t be notified there won’t be alerted they won’t be following that you can’t you have to be very careful if you’re using ETL tools for a cross community chatter then you’re basically making an external tool call in and out to move data internally in Salesforce so you’re gonna use a lot of API calls up to do something that should really be internal you’re also going to have to make sure you follow the Salesforce releases so you have to track those as you go through so and I’ve got to every single service release we have to do an update passport there’s always a new feature is always something else that we need to support it also includes creases in complexity for each or while it may work very well of two or three orbs every time you have another org you want to interact with it gets harder and harder to do hard and hard to do the mapping and it is very challenging if you’re actually talking about working with your customers or partners it’s very hard to agree who owns that ETL tool and what permissions you want together if you choose passport and possible communities it can be set up in just one day and it’s suitable across different legal entities for that reason we include the additional chatter licenses and you have a centralized place for doing your configuration and you management because it’s an application of obviously we support it and we do all the release tracking when you connect a new org up to passport as well it automatically goes into a sync mode where it tries to recover and put in place all the messages all the conversations you want replicate that new org and from that org into the existing ones now the downside is if you want to collaborate on objects so if you want to collaborate on a case or an opportunity then you need the appropriate Salesforce license for Ghost users so you need your extra sales or Service Cloud licenses depending which object you want to collaborate on if it’s not about objects though it’s fine with chatter free if your talk about account you probably about chatter Plus

licenses and also doesn’t move your non chatter data so you still need to use Salesforce the Salesforce or ETL for your object data and there’s a very small passport license costs from US per user per month if you do want to use passport very reasonable though the lessons we learned though is sales has been very prolific when we first did passport we would looking at synchronizing these users synchronizing groups feed items comments polls likes attachments great we’re done oh no hang in a minute then we had to do subscriptions we did the object chatter group memberships member requests mentions comment attachments current mentions oh we finished this this products ready now and then last year at Dreamforce what happened since Dreamforce 13 we’ve had topics private groups group archiving announcements questions thanks I’m expecting the list to be just as long at Dreamforce 15 of another set of features so it requires a full time team to keep this going and keep it in sync you also have to think about the parent-child dependencies so when you’re moving a chatted post you think you move that post over but you have to think about who’s the user who made that post make sure that users replicated first and if anyone’s mentioned in that you need to make sure that person’s been created first and if any groups are now mentioned you need to make sure that’s posted first so the the dependencies can get quite complex it’s really important as well around the org limits we learned very quickly to optimize that batch jobs so you go to a customer when they had ten batch jobs and you can use one of them and not happy about that they’re very precious resources so we made sure we had just one batch job and had a design pattern that recued and managed all itself it’s so self being recued as well so make sure you do things like that the licensing I’ve mentioned already about the ghost users so you need the right license type for the right object we also face the issues of government limits so web serves call out limits effects possible native so if we want to move a file from one oak to another with possible at native at least 100 percent native version we were limited to about two and a half Meg within the three Meg limit to do that the workarounds we came up with that is either to post notifications across those overall same user a has posted this file in alt B or chatter files may solve this over time the other option is to host your files outside a Salesforce and then make sure your posting links instead even if you solve that two-and-a-half mega limits you still have limits on things like heap size so working natively there are many restrictions if you’re trying to build this we also found things especially around across all the versions of passport around chatter notifications so the emails if someone’s getting a email settings set up for their chatter feed those emails are not sent when they’re posted by a ghost user so we had to work around that with our own workflows personally I try to encourage users to use digests instead of using instant notifications because to me the whole purpose of chatter is to try and avoid all those emails in my inbox every morning that I don’t really need to read and finally external collaboration so we also experimented with integration with drive and Yama so by having a tool that’s outside it’s very easy to do the main issues we had with that it’s doing that feature mapping so while we can support those you have to accept limitations on the types of message that map Yammer Maps better than jive but there’s still limitations and what you can do so that’s enough about collaboration let’s talk about some of the other issues with multi org so master data management so I’m not a master data management expert but there are lots of people at the expo this week who are I recommend you see some of them consider things like Salesforce to Salesforce it’s free don’t ignore it and the crosstalk data-sharing if they don’t address all your needs then think about the tail tools that are out there also focus sorry considered not just within Salesforce so if you’re doing master data management you think about your ERP systems or your opossums as well so don’t have one solution for linking up your Salesforce alter master data and a different solution for linking up in your ERP solution use one solution for all of those and focus what’s essential don’t try and crack the whole thing at once do your accounts and contacts first maybe do your orders that kind of information first don’t try and do too much and make sure you have a very clear system of record far too often you go into somewhere financial er peebs team believes they own the account record CRM team believe they own it you’ve got to at one clear system as part of that you need to harmonize unique record identifiers is the amount of times I’ve been in two companies I look in their account object and I see five external IDs for five different keys across five different systems you just shouldn’t be doing that make sure everyone agrees which is the right identify it doesn’t have to be the southside a but agree that one identifier is the true unique identifier for account record and make sure you enforce field and record security in each of your Salesforce orgs

to avoid update conflicts so be religious in doing that because if someone does get to change a value system admin somewhere can change the value mono slave orgs then you’re gonna have problems with that data not seeing King and then deployment management cannot underestimate how important this is so in terms of deployment when we’re talking about cross or we can’t use things like change sets at the moment so the recommendation I make is to use a master config repository so something like github or your own get server and the migration tool kit or any of the third-party tools that are out there as well this can be very complex and manage but it’s well worth the effort when you get it working is a challenge to keep 100 cent accurate as well very much so and you have to be careful if you’ve got multiple orgs you need to be very careful about people making local configuration changes so someone may create a new field in one of those organs with something you have in a new master set of configuration and then your deployment files and then you’ve got data that is already there you have to make I’ll move you also end up with this approach with a super set of configuration so you’ll find your account object has several hundred fields on there different all different divisions different business units and different fields you also find you run out of things like tabs fields external IDs master detail etc very quickly if you’re not careful and even if using continuous integration tools such Jenkins deployment can be extremely time consuming taking several attempts however it’s also suitable for a single log so if you are used to single log moving between sandbox is the same approach having a config repositories definitely worth considering still so the second option is to use management packages so the idea here is you have a core manage package for your central functions and your data model managed by one team and that’s done within a separate developer edition org and you take that base manage package and you deploy it into another developer edition org and in that developer edition org you build out your business requirements maybe for HR for fine for the areas that you want to package up functionality or if you think of it as an application that sits within your Salesforce that can potentially be a extension package and you package that up as well and then when it comes to your different orbs what you do is reinstall those two packages you install the base package and optionally all the different extension packages that you want to use as well and the benefit this is it keeps the core very light and it allows the local admins and those territories or those companies or those organizations to still make their own changes because when you create an manage package and put some name space on it so it’ll protect you against local changes however you still want to look at things like having a prove list of app exchange apps so you probably don’t want every org using a different ERP solution in Salesforce financial course or another one you want is probably standardized on the other apps that they can install and the private app exchange is one way to do that if you are using more than three orgs I definitely recommend the manage packages over the previous option so even if you’re doing even those options and even you’re a single org you still need to certain have a process in place you need a change management process needed a change management team to decide what goes into that corset perhaps the earth the config repository or the managed packages you will see the governance team to review and accept those ideas into the core make sure that you’re not duplicating something make sure it’s not a variation on something you’ve already written and make sure they’re managing which apps they’re permitting to be installed to those orgs you still need to do config management in either case you still need that change history it’s because you need to fix and go forward you can’t put an old manage package in you can’t roll back a deployment you have to fix and go forward so make sure you’ve got a copy of what the code was there before I cannot underestimate as well about multiple sandboxes so if you’re an enterprise edition developer sandbox on its own isn’t really going to cut it if you want to imagine these changes you need to have a separate sandbox for UAT and testing and make sure you use an established deployment process make sure everyone knows when the change window is and when those change is going to happen make sure you’ve got a team on hand to test that as well whether it’s smoke testing or using automated tools such as probe are so probe are is a another pitch for another application of valves over here at Dreamforce this week and what Provo allows you to do is allows you to run regression tests and build your test cases up on salesforce and it’s the only tool that actually allows you to do this and it allows you to do it for your internal users your internal pages your portals your communities even Salesforce one and it does that it looks at standard pages visual pulls pages and your mobile web and hyper pages and you can either sort of capture as you click through a page being external page or you can have it inspect your org for you

and suggest the fields that you might want to map and look at what’s conditional and unlike other test tools such as selenium it’s not bound to the IDS that Salesforce generates is bound to the metadata so long as you don’t rename your API names and things as you test across different sand boxes of different orgs the tests will still run as well it also includes things like API testing so as well as testing within Salesforce we can do a lookup we can make a web service call we can look at them QQ and see that a data value exists in a database somewhere else we could also use it we really use that also for data management recently a customer had a problem a large oil company had an issue with their data across sandboxes they quickly decide to pull data from one or to another we connected probe r up suck the data out of one org captured that and replayed it through the UI on the other org it’s something we couldn’t do through their API is alone and also a continuous integration so Provo will work with things like Jenkins so you can set up automated daily tests and know that your build is safe that the or orgs are all running your sandboxes all in sync so next steps so if you interested in passport just go on the up exchange and search passport I’m not gonna do it have you pitch on that anymore if you’re interested in master data management go out and the expo probably visit informatica first and asked about cloud MDM but do visit the other ETL tool vendors and ask them what their messages on MDM in terms of ETL tools personally I’ve used mule soft informatica just a bit Dell Boomi talent and there are many more out there so again talk to those guys see what they’ve got to offer and probe eyes over in cloud expo north in the far right corner as you walk in so please go and talk to any of their guys their guarantor Ashutosh about probe r and you can also visit the website probe are testing you can also catch me tomorrow if you have any questions so i’m going to be a stooge and another session three o’clock one of our other consultants about seven episodes was console completely unrelated today thank you very much any questions yep if you come up to the mic can you talk about what trends you’re seeing in terms of you know company large enterprises that have adopted Salesforce and have for the reasons on your first slide they’ve adopted multiple instances of Salesforce and what’s sort of the the trend is towards consolidation versus staying independent what are you seeing the largest companies doing and why what are the best practice trans if you will okay so the large companies we see largest we seen is about 50 60 orcs and they’re never going to consolidate those and it would never fit in one Salesforce org so whether their main focus was around key account management so I went to make sure they had those global accounts managed across those and some of those took the master org approach so they had the key accounts manager that master org they had that organ addition for their reporting across that but they still wanted the chatter conversations to be company-wide and have that cross out upsell on the other end of the spectrum when you look at smaller companies but maybe two or three orgs pretty much they almost always end up opting to migrate and merge their halls together to this single or migration anymore it’s quite hard to see this light in my eyes don’t be shy okay thank you very much enjoy Dreamforce hope you have a great week