I've been trying to get the 'Sync Person Updates to SFDC' Activity type to get a specific activity from a lead. I checked the lead's activity log and it's there but I can't query it. Is there a limitation or a reason why I can't get this specific Activity Type?
Solved! Go to Solution.
Ahh, yes - AFAIK the Sync Person Updates to SFDC activity specifically is not available to be queried via the GET endpoint/Marketo SL. Sync Person Updates to SFDC is logged upon automatic data sync b/w platforms when a synced person record is updated (and not due to execution of a Marketo flow step).
Some users create a custom Datetime field in SFDC that updates (using SFDC workflow/Apex) when the default SystemModStamp changes (or perhaps more selectively if you want).
Then you can detect changes to that field using, for example, the Get Lead Changes API.
Is the activity you're trying to reference older than 90 days? FYR - SFDC sync activities are considered as a high volume activities, and hence they are not available to be queried by the Marketo SL filters past 90 days since the activity date. Even though the activity appears in the person activity logs, but still the SL filters referencing high-volume lead activities beyond their 90-day retention period will not have the activity to reference. You can however use the bulk extract REST API use to extract the older Sync to SFDC activity data.
The activity is actually just yesterday. So its really impossible to get the Activity Type Id of 'Sync Person Updates to SFDC' using `/rest/v1/activities/types.json` endpoint? Or to even query the activity using the `/rest/v1/activities.json` endpoint?
Ahh, yes - AFAIK the Sync Person Updates to SFDC activity specifically is not available to be queried via the GET endpoint/Marketo SL. Sync Person Updates to SFDC is logged upon automatic data sync b/w platforms when a synced person record is updated (and not due to execution of a Marketo flow step).
I see, Thanks for the response Darshil!
Some users create a custom Datetime field in SFDC that updates (using SFDC workflow/Apex) when the default SystemModStamp changes (or perhaps more selectively if you want).
Then you can detect changes to that field using, for example, the Get Lead Changes API.