Question:

Pitfalls or risks in having a scheduled job run every 1 minute

Athena: 5 days ago

I've got a requirement to know which Contacts are associated to Open Opportunities, and it needs to be known very quickly upon OpportunityContactRole creation.

As we all know, OpportunityContactRole is not Triggerable in any way shape or form. (Another fun fact, OCR records don't go to the Recycle Bin unless it's the Opp that gets deleted.)

I've created a batch job that successfully queries OCR based on CreatedDate and I have it re-schedule itself in the finish method for 1 minute in the future.

It's all working as designed in a Sandbox, but I'm curious if anyone has a "OMG THAT'S A TERRIBLE IDEA" sentiment and if so...why? I'm assuming the largest risk is record locks?

Answer:
Hunter: 5 days ago

The biggest concern is that they'll follow through with their promise of delaying such suicide scheduling (https://developer.salesforce.com/blogs/engineering/2014/10/new-apex-queueable-interface.html). Locking is usually not an issue unless you're in a really busy org, but you might not get the performance you're looking for. There's no guarantee it'll run on time. That said, if you really want to go for it... go for it. Most orgs shouldn't even notice the scheduler kicking off every minute. You might get slightly better reliability if you were to use the replication API (get updated (https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_getupdated.htm), get deleted (https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_getdeleted.htm) calls) to replicate the data every few minutes to another database or even back in to Salesforce. While I honestly can't recommend suicide scheduling, it's the best possible solution given our current limitations within Salesforce.