Instance Latency and program "races" due to overuse of "Person is Created" campaign trigger | Community
Skip to main content
JasonSantoMF
JasonSantoMF
New Participant
October 17, 2023
Solved

Instance Latency and program "races" due to overuse of "Person is Created" campaign trigger

  • October 17, 2023
  • 3 replies
  • 2810 views

Hello,

I just want to do a sense-check on something I'm noticing in my instance. We've got about 20 or so Active Smart Campaigns running with the "Person is Created" trigger, and a bunch of them have no constraints and filters. Considering that we have users uploading thousands of contacts at a time, should we be concerned about latency and campaign "races" because those new records would tee off multiple campaigns at the same time?

I feel as though it's bad practice to have things set up as such.

And thoughts are welcome and appreciated. 

Regards,

Jason

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by SanfordWhiteman

You can easily slow an instance by having a high number of independent Person is Created campaigns and an associated high volume of new people being created. What “high” means isn’t concrete. It depends on what exactly the campaigns are doing, and you don’t necessarily solve issues merely by combining flow steps into into fewer campaigns.

 

We wouldn’t call this is a race condition, though. It’s merely an attempt at parallel execution, which will in reality not be truly parallel for the same lead, it’ll be effectively random.

 

If the final order of operations for someone doesn’t matter, there’s no race condition.

3 replies

Darshil_Shah1
Darshil_Shah1
Community Manager
October 18, 2023

Totally agree with everyone here! You should definitely look into creating a centralized process and a workflow of actions that should be performed on new people getting created in your database instead of having multiple campaigns listening for the same thing, i.e., the  Person is Created trigger. I also second the idea of using the Executable campaigns, as the flow steps in the Executable Campaign are run in series with the parent campaign (unlike the Request Campaign, which runs in parallel in a separate Trigger Campaign). They guarantee the synchronous execution of flow steps and hence, are totally suitable for dependent flow steps/campaign execution. Read all about the Execute Campaign flow step and Executable Campaign here.

    Katja_Keesom
    Katja_Keesom
    Community Manager
    October 18, 2023

    What I always try to do is have the central Person is Created processes clustered in a single trigger campaign that in turn runs a series of executable campaigns living in several other data management programs related to the respective data management process. Doesn't necessarily reduce the amount of steps, but it does reduce the trigger volume and gives some more control over what runs first.

      JasonSantoMF
      JasonSantoMFAuthor
      New Participant
      October 18, 2023

      This is what my gut was telling me. I believe isolating this (and several processes like it) into a single triggered campaign that's called as part of an order of operations (and is excluded based on certain conditions) is better architecture. 

       

      Thank you for backing up this theory with your practice. 

       

      - Jason

        SanfordWhiteman
        SanfordWhitemanAccepted solution
        New Participant
        October 17, 2023

        You can easily slow an instance by having a high number of independent Person is Created campaigns and an associated high volume of new people being created. What “high” means isn’t concrete. It depends on what exactly the campaigns are doing, and you don’t necessarily solve issues merely by combining flow steps into into fewer campaigns.

         

        We wouldn’t call this is a race condition, though. It’s merely an attempt at parallel execution, which will in reality not be truly parallel for the same lead, it’ll be effectively random.

         

        If the final order of operations for someone doesn’t matter, there’s no race condition.

          JasonSantoMF
          JasonSantoMFAuthor
          New Participant
          October 18, 2023

          Thank you, Sanford. I was hoping you might pop onto here with an answer and this confirms what I sensed was the issue - in particular your mention of parallel execution being random; that appears to be what's happening.

           

          There are flows running off the triggered campaigns and I thought that those being triggered simultaneously would result in race conditions, but I see what you mean. Apologies for the confusion on that. We definitely DO want an order of operations created for many of these campaigns, and I believe we'll want to isolate high volume triggers into their own campaigns so they can be conditionally included/excluded, so I guess we're moving toward an environment where race conditions could arise. I'll have to think more on that.

           

          A quick follow-up for clarification: constraints on Person is Created would assist with the high volume parallel operations, wouldn't they? I would think that using more constraints (but not filters) would be an effective way of lessening the number of flows these thousands of contacts being uploaded are qualifying for. Or does it only come down to the complexity/number of flow steps that are running which slows things down? I would think less person records qualifying would mean less parallel processing.

           

          Thank you.

          Jason

          Michael_Florin-2
          Michael_Florin-2
          New Participant
          October 18, 2023

          Totally agree with Katja, and I would even go so far as to say: "Person is Created" may only occur once per instance.

            Terms & ConditionsAccessibility statement

            Loading footer...