Why Multi Org ?
Having all sales , service and marketing clouds on a single org is no more a good practice from overall Org strategy point of view. Having everything on one instance makes sense from data availability point of view but this is not more an excuse since near real time data can be access using various channels on Salesforce platform.
Having everything in one org have some other limitations , to start with the governor limits which can be seen in terms of code character usage , data storage constraints , sharing related issues like hiding sales data to anyone else in the org who are not intended to know those.
While moving Sales , Service & Marketing clouds into separate Orgs solves all these problems.
Hub Org should be the Master Org where all the Orgs data is synced. This Org can be used for analytics purpose and also can act as backup database.
There may be instances where Service cloud need to see sales cloud data. For example , Case management might require account details.
How to Sync data between Hub and Spoke Org ?
Since all these instances are salesforce we might consider using Salesforce-to-Salesforce (S2S) feature . This might look a good option but there can be some challenges in going with this approach. Here are few limitations :-
- If there is any record sync failure due to some custom validation or some other exceptions , we don't have any retrial option to sync the failed records. Also , manual monitoring is required.
- Not all Objects are supported by S2S . For example Entitlements , Notes etc.
External Objects are good for view purpose but the records which need to be updated in multiple instances can cause record lock issues. Also , external object currently don't allow workflows or process builders which eliminates this from our list of viable options.
We can try using steaming API push topic which can be fed to Mulesoft and later synced to hub org,but it comes with lot of limits too.
We can also try the REST polling mechanism where we get list of records inserted/updated/deleted in a given interval. Then further describe call is made to get record detail.
It gives a snapshot of all fields which can become an overhead to process increasing the processing time.
Finally , we have a mechanism which sends us platform events which is crisp and up to the mark. This is called Change data capture (CDC) .
CDC gives us exactly the fields which were changes during one update , insert or delete operation , making our life easy.
This is how a sample CDC even look like -
{
"data": {
"schema": "IeRuaY6cbI_Hs7hr61Mc5g",
"payload": {
"ChangeEventHeader": {
"entityName": "Case",
"recordIds": [
"<record_ID>"
],
"changeType": "CREATE",
"changeOrigin": "com.salesforce.core",
"transactionKey": "001b7375-0076-257e-e6ca-brcyufyi8b69f",
"sequenceNumber": 1,
"isTransactionEnd": true,
"commitTimestamp": 15015678653,
"commitNumber": 568056772780,
"commitUser": "<User_ID>"
},
"CaseNumber": "123456",
"Description": "Faulty Keyboard?",
"OwnerId": "<Owner_ID>",
"CreatedDate": "2017-08-05T19:10:11Z","CreatedById": "<User_ID>",
"LastModifiedDate": "2017-08-25T19:16:44Z",
"LastModifiedById": "<User_ID>"
},
"event": {
"replayId": 7
}
},
"channel": "/data/ChangeEvents"
}
Further these events can be easily processed using open source KAFKA or Mulesoft and the different Orgs can keep their data in sync with Hub.
Comments
Post a Comment