I agree that the documentation is a bit vague on what actually makes an sObject replicateable.
Certain objects cannot be replicated via the API. To replicate an object via the getUpdated() call, its object must be configured as replicateable (
replicateable is true). To determine whether a given object can be replicated, your client application can invoke the describeSObjects() call on the object and inspect its
There isn't any guidance on how the replicateable property can be configured.
For empirical evidence, I iterated over all the DescribeSObjectResult's returned via the API and captured the name of anything where
replicateable was false:
The resulting non-replicateable list was:
Points of interest:
- None of my numerous custom objects appeared (no __c suffix). I assume this means replication is available for all custom objects. However, this is a based on a sample size of 1, so your results may vary.
- Many of these represent views and sharing access over other data. This is system level data. Things like CronTrigger and ApexLog. It wouldn't really make sense to provide this data for replication.
- The Content* (e.g. ContentVersion) records appear and might be something you want to replicate. Content has always been a bit off the standard sObject implementation and more a law unto itself. The probably also explains why it isn't supported.
- I did have some external custom objects with the __x suffix appear as non-replicateable (I excluded them from the list above). That makes sense as the data isn't actual in Salesforce.
Interesting response from @superfell in SOAP API - getUpdated()/retrieve() vs query()/queryMore(): (my emphasis)
Specifically for the getUpdated() case, you are correct that you can do a query/queryMore alternative by building the correct where clause. However the where clause differs by object type. You should use the SystemModstamp field where available, if it doesn't have that, then use LastModifiedDate and if it doesn't have that, use CreatedDate. This is basically what getUpdated() is doing under the covers.
So replicatable is relying on those three fields to provided the getUpdated() functionality.
The same answer also has:
But, it worth understanding that there is no SOQL equivalent for getDeleted(), many types of rows can be hard deleted and so a queryAll with isDeleted=true will not spot these deletes, but getDeleted() will (which keeps a separate delete log).
It is unclear what drives that separate delete log, but it is probably tied into the replicateable flag.