How can I use "webhook is called" in a smart campaign but isolate the behavior to the "parent program"?

[Anonymous]

I have this:

• Program A
  • Smart Campaign A
    • Triggered by "Fills Out Form".
    • Does a number of things including calling "Webhook X".
  • Smart Campaign B - Triggered by "Webhook Is Called".

• Webhook - is - "Webhook X"
• Response - contains - "Y"
• Flow: Send Alert
• Program B
  • Smart Campaign C
    • Triggered by "Fills Out Form".
    • Does a number of things including calling "Webhook X".

This is what occurs:

1. I fill a form out that triggers "Smart Campaign A" under "Program A", which calls "Webhook X" and in turn triggers "Smart Campaign B".
2. "Smart Campaign B" under "Program A" checks for a specific response code. If it finds it, it triggers an alert that includes some information about "Program A", including its program ID and a bunch of other {{my.tokens}} specific to the program.

The problem is, if I fill out a form under "Program B", "Smart Campaign C" also calls "Webhook X" and causes "Smart Campaign B" under "Program A" to send an alert.

How can I use "webhook is called" in a smart campaign but isolate the behavior to the "parent program"?

There's a bunch of tokens under "Program A" that I'd like to include in the body of the e-mail alert, so I want "Smart Campaign B" to be a child of "Program A."

[Rachel_Noble]

Hi Osman,

Maybe I'm not understanding exactly what you're trying to do here, but can you use the "Request Campaign" and "Campaign Is Requested" step & trigger instead of the "Webhook is Called" trigger in Smart Campaign B?

Rachel

[Grégoire_Miche2]

Hi Rachel,

Apparently, Osman needs the webhook process to complete before campaign B starts, which you cannot acheive with request campaign. webhook execution is asynchronous and you cannot know when the webhook will return a result.

-Greg

[SanfordWhiteman]

Actually webhooks execute synchronously. It's the data value update that is asynchronous, since the response from the webhook is placed in a data queue (effectively) rather than being committed to the database before the webhook step returns.

This may sound nitpicky, but it's an important distinction because a long-running webhook call will not proceed to the next Flow step immediately. Even if the next step does not involve the webhook-related fields it has to wait. Take a webhook that's used to sync data with an outside system's API, so rather than a near-wire-speed < 200ms turnaround you might have a 5-10s wait if you happen to hit that 99th percentile response time.

(This consideration w/r/t second-hop performance is why FlowBoost (Pro) has a "deferred mode" that allows a time-intensive webhook to return to the Flow immediately... more on that another time.)

[Grégoire_Miche2]

Hi Osman,

I would use a selective field in addition to the webhook that would tell campaign B which campaign has called the trigger. Ideally this field would be set as part of the trigger response, from a input value that would be set by a program token. But that would mean changing the web service so that it accepts the additional parameter and returns it. Alternatively, you could set the selective field just before calling the webhook. Not as good though since if the lead fills out both forms while the webhook is being processed, it may break...

Then, in campaign B flow, you could set a choice on the send alert flow step: if calling prog is A then send alert else do nothing. You could also filter it in the trigger with the response constraint.

-Greg

[Josh_Hill13]

Why wouldn't you just Wait X minutes, check if the call is done, then Call the next program with Campaign Is Requested?

If the Webhook breaks or stalls, then Add to List for those people for a batch to fix or for review.

[SanfordWhiteman]

An arbitrary wait step works in 99.999% of cases, but it's really just a guess and over a large enough volume you will see missing data. The flipside is the high-performance 99% is punished by having to wait even though their work is done.

It's like (on the browser side) setting a redirect page to wait ​N ​seconds before redirecting, in order to "let tracking calls finish" -- the calls will finish the vast majority of the time, but when they finish in 150ms the page still waits ​Ns​.

Luckily the ​Webhook is Called trigger lets you respond in exactly the right period of time, no more, no less.

[SanfordWhiteman]

I agree, echoing a campaign or program identifier back in the webhook is how you know what Flow it came from.  For example, always send and receive {{Campaign.ID}}.

[Anonymous]

The webhook's response is very general right now. It seems like including the program ID in the response, along with a more specific status when certain conditions are met, will help us get around this issue. (Which is what I think we're going to do.)

I was hoping there'd be another route we could go that that would allow us to leave everything as is with the webhook and just leverage Marketo, but I guess we'll tailor the response a bit more to include enough information for campaigns to identify responses that relate to their program.

Thanks, everyone, for the help!