New vs. Updated record from Salesforce

[mmaher]

We need to automate system provisioning based on record creation and update in Salesforce. Of course I'm using the Salesforce connector with new or updated record as the trigger, but here's my issue: When I work with Flows in Salesforce, I can access the change type as well as the new vs. old field values. In Workato I have none of that, the most significant gap being change type. Some of our systems provisioning can't be managed via API, which means I can't just check to see if the user has already been created and then create or not. I will be sending emails in those cases to the owners of the systems prompting them to create the new user, or revoke permissions from an existing user, which means I need to evaluate in the recipe whether it's new or updated.

I'm curious what others do here - do you (a) assume that if the record is new, the created date and the last modified date would be an exact match? (appears to be the case in testing but hard to feel confident it would always be the case), (b) manage a table of records separately to use as a comparison point, (c) use a flow in Salesforce to evaluate the change type then send a message to a custom API endpoint? (d) enable history on the record and query from the history record as a first step in workato, (e) something else?

TIA!

[Deepan]

In Salesforce integration we can consider the option A as to compare the created dataTime and the last modified dataTime if it equal then newly created and lastmodified datetime is greater then created datetime it is updated record.  It will be good option as this the simplest way to figure it and salesforce will definitely change the timestamps when there is update.

[shivakumara]

Hi @mmaher ,
Here my detailed view on the Approaches I want go with:

(a) Compare CreatedDate vs LastModifiedDate
Use case: Lightweight, low-latency solution for basic differentiation.
My view:
1. Works in many cases, especially if you're polling recently modified records and only want to distinguish new from updated.
2. However, it's not 100% reliable in all edge cases — especially with processes, automations, or triggers that update fields shortly after creation.
3. Good for low-risk, non-critical logic.

b) Maintain an External Tracking Table

Use case: Accurate change detection over time.

My view:
Best for high integrity or audit-driven processes.
Store record IDs + LastModifiedDate in a Workato Lookup Table, DB, or Snowflake.
On each run, compare current LastModifiedDate to the stored one.
Pros: Works across deletions, re-creations, and complex updates.
Cons: Slightly more overhead to maintain.

(c) Use Salesforce Flows to Trigger API Calls
Use case: Real-time and precise.
My view:

Very effective when you want event-driven integration instead of polling.
Use a Flow to detect changes and call Workato via an HTTP trigger or callable recipe.
Less polling = better performance.
Pros: Real-time, only processes meaningful changes.
Cons: Slightly more dev effort + Flow maintenance.

The third approach—using an API-based trigger—is the most reliable way to handle this scenario. Unlike the first approach, which relies on comparing timestamps and can miss edge cases (potentially resulting in records being neither created nor updated), the API method ensures consistency.

By having the source system trigger our Workato recipes directly via API calls whenever a record is created or updated, we gain better control and accuracy. This eliminates the dependency on polling intervals and timestamp-based logic, which can be error-prone in high-volume or rapid-change environments.

Alternatively, for a more event-driven and scalable architecture, we can leverage Salesforce Platform Events or PushTopics. These options reduce reliance on Workato’s polling and allow the system to react only when meaningful changes occur.


Thanks and Regards,
Shivakumara K A