Running Smart Campaign every 15 minutes

[Jo_Pitts1]

All,

I have a situation where I can't use a trigger to fire off webhook calls (I won't get into the reasons why, suffice to say there is a quirky legacy system at the far end of the pipe).

My desire is to use a smart campaign running every fifteen minutes to fire off all eligible records created and/or changed in that timeframe.  However, Smart Campaigns can't be scheduled to run at that frequency.

Any thoughts on how to do that?

Cheers

Jo

[Kelly_Marco2]

This might be an incredibly unsexy solution, but you could create the same smart campaign 4 times and just run them at different intervals. 

(just realized my first solution likely wouldn't solve what you're trying to do) 🙂 

[Jo_Pitts1]

Kelly,

give the scheduling granularity only goes down to daily, the 'unsexy' solution (and it is that 🙂 ) becomes untenable, given it would need 48 instances of the smart campaign.

[Jay_Jiang]

this is the most non-technical solution. you don't need a smart campaign each time, you can have a flow with multiple wait 15mins + request campaign flow steps until every 15 minute interval in a day is covered

e.g. 96x 15 min intervals in 24 hours = 4 smart campaigns with 24x wait + request campaign flow steps. each smart campaign's daily recurrence would be 6 hours apart - but you could probably forgo the sync during after business hours?

The likely solution would have more moving parts than just this by the way...

[Jo_Pitts1]

@SanfordWhiteman , don't suppose you've got any insight on this?

[SanfordWhiteman]

Can you explain the whole can't-trigger-when-updated-must-send-batch-to-trigger thing?

[Jay_Jiang]

I think the use case is essentially a custom one-way sync.

@ OP, this is typically architected using middleware to PULL the data from the source system via API

[SanfordWhiteman]

---

I think the use case is essentially a custom one-way sync.

@ OP, this is typically architected using middleware to PULL the data from the source system via API

---

That's clear, but it's still using a webhook either way.

Just in one case it's triggered by a change (potentially higher volume depending on rate of change, and staggered schedule), and in the other case it's a batch-to-request-trigger (predictable schedule and potentially lower volume if there are a lot of discardable changes in-between runs).

So it's not clear exactly why the remote service wants one over the other.

[Erik_Larson]

If you have dev resources, or want to write some code yourself, it's easy enough. You could set up a campaign to react to the changes you care about on records that adds the records to a static list. Then stand up a cron job in python or something that runs every 15 minutes, which simply pulls off that static list and requests your campaign with the webhook, and removes the records from the static list. This could be done in a few lines of python using the rest api package out there. Happy to help if needed.

[SanfordWhiteman]

Still, the final effect is either one or zero webhook calls per person per 15-minute window. Would still like to hear what it is about the rate of change within that 15-minute window that makes it untenable for the other side. A field that must change multiple times in 15 minutes, all the time, across the db, seems like a design problem.