Looking for advice on the best API option to return a list of Ids in a particular object when only specific changes are made to the records. From what I gather, the REST option of GetUpdated doesn't allow for filtering based on changes, so it'll return records with unrelated changes.

Field history is enabled on some of the fields I'm interested in, but not on others, and it's not a scalable option to add to all of them.

Would Streaming API be the best fit here? Or is there another option? The basic gist of what I'm doing is data replication for an external warehouse, but I'm only concerned with a handful of fields and real-time updates isn't really necessary.

  • 3
    Streaming API would be a very good resource and most likely the best fit sans an outbound message WFR based on the fields you would like. I would go streaming API if you can
    – Eric
    Commented May 29, 2017 at 19:33
  • 1
    Do you want a 100% API based solution, or would you look at adding additional flag fields or queue objects in Salesforce as well? Commented May 29, 2017 at 19:40
  • @DanielBallinger my current workaround solution is a WFR that sets a flag field = true when the fields I'm concerned with are changed. Then I use Query to look for those records, pull the updated values, and reset the flag back to false. This works pretty well, just seems inefficient.
    – Matt
    Commented May 29, 2017 at 19:43
  • 1
    There is also the new platform events functionality that is going GA in summer17, this article touches on the distinction between streaming API use case and platform events use case at the end : developer.salesforce.com/blogs/developer-relations/2017/05/…
    – gorav
    Commented May 29, 2017 at 19:46

1 Answer 1


The best object will be dependent on a number of factors, such as how quickly you want to know about the change, how many records are expected to change over the period of interest, and how many API calls you can burn to monitor the changes.

There are several options:

  1. Use an Outbound Message fired by a Workflow rule that is monitoring the fields of interest for changes. That will give you a built in queuing and retry mechanism with a SOAP callout to a service you host.

  2. Use the Streaming API with NotifyForFields.

    Streaming API provides two types of events that you can publish and subscribe to: PushTopic and generic. PushTopic events track field changes in Salesforce records and are tied to Salesforce records. Generic events contain arbitrary payloads. Both event types don’t provide the level of granular customization that platform events offer. You can send a custom payload with a generic event, but you can’t define the data as fields. You can’t define those types of events in Salesforce, and you can’t use them in Apex triggers. Source

  3. Use the new Platform Events to raise an event when the fields of interest are changed.

    Platform events enable you to deliver secure, scalable, and customizable event notifications within Salesforce or from external sources. Platform event fields are defined in Salesforce and determine the data that you send and receive. Apps can publish and subscribe to platform events on the Force.com Platform using Apex or in external systems using CometD. Source

  4. Use a trigger to add the records of interest to your own queue table where you can query them as needed and then remove them from the queue once processed. This is similar to your existing solution of setting a flag field via a workflow rule and then querying for it and clearing the flag. Perhaps not the most elegant or efficient solution, but it is robust and proven over the years.

  5. Both the REST API and SOAP API have methods to get only changed records during a period. As you noted, these will find any record updated in the given time period. Not just those where the fields of interest have been updated.

  6. There is the current External Services (Beta) running. You could have Salesforce callout to a service of your own implementation when a change occurs.

  • Makes sense. So one of the major differences between Streaming and Platform is the ability to customize the payload? Right now with Streaming I'll receive the record Id, but then still have to do a separate API call to pull the field values, whereas Platform will let me send them in the initial payload?
    – Matt
    Commented May 29, 2017 at 20:22
  • The Streaming API PushTopic can include fields as part of the Query. I think the difference with Platform Events is that the payload is defined on the event itself rather than being tied to a specific sObject. So the Platform event could aggregate data from several sources. Commented May 29, 2017 at 20:32
  • Vs. the Generic Streaming API where they payload is more freeform. Commented May 29, 2017 at 20:36
  • 1
    @Matt I've created a more generic question around the differences between the Streaming API and Platform Events. Commented May 30, 2017 at 1:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .