Forum Discussion

odeykassam's avatar
odeykassam
Qrew Trainee
3 months ago

Workaround for 90 Pipeline Limit?

I have reached 90 Pipeline (triggers) limit for my table.

I need to do more pipelines with that table, anyone has a workaround ? (I cannot turn off pipelines)

Here's what I've tried so far:

1- Zapier/Make : doesn't work because I cannot trigger a zap if a specific field was updated. 

2- Consolidate pipelines: Doesn't work because I cannot set a condition of "what trigger caused this pipeline to fire)

3- Look up field in another table and trigger the field based on that: Doesn't work, QB doesn't trigger workflows on lookup fields

4-  (3) + A formula field that dynamically sets the value matching the field on the main table: Doesn't work, QB doesn't trigger workflows on formula fields

 

 

8 Replies

  • I suppose if you are desperate enough, you could make a new table called XYZ Pipeline Triggers and use your last (90th) Pipeline to Trigger on any change to any possible trigger field and do a Bulk Upsert to XYZ Pipeline Triggers, Merging on a Custom Key field of [Record ID# of the Real XYZ].  I think that will give you 90 more triggers.  

    Just by the way, I recently had occasion to make 18 pipelines trigger off the same field being changed.  They all triggered and ran simultaneously very quickly with no problem at all. Nothing really to do with your situation other than I was wondering if there is any limits to how many pipelines could be triggered off the same field being edited on a record. 

    • odeykassam's avatar
      odeykassam
      Qrew Trainee

      Thank you for the suggestion!

      I thought about that but wouldn't that require me to have XYZ Syncing in real time with my main table? meaning if any record gets created in my main table, also create it in XYZ ? if so, I tried making a table from "source = quickbase" which achieves exactly that, the only issue, is that it's not real time, (1 hour delay) 

    • Jross-Dev's avatar
      Jross-Dev
      Qrew Member

      I am late to the party, but a PL can run in parallel with 30 "clones" at a time.  Once you surpass that, the next calls in queued up.

  • I'm not suggested a connected Sync table (due to th 1 hour delay). I'm suggesting that you use your last remaining pipeline to create or update a small version of your record in other table.

     

  • JamesCarr's avatar
    JamesCarr
    Qrew Assistant Captain

    Is the suggestion working for you? I would be curious about your various triggers. Perhaps there is another field you could create to help you determine the trigger in order to consolidated some of them.  Perhaps jinja could be utilize more? 

    • odeykassam's avatar
      odeykassam
      Qrew Trainee

      I see what you mean, I would need to think if this causes any race condition (field updating rapidly in a specific moment) I don't think so, but I will try it

      I Have a bunch of pipelines that are for "Notifications" which. basically call a webhook (always the same webhook) with a "Notification Template" whenever something gets changed (Survey gets booked, install gets scheduled/cancelled etc) I could think ok making a "Current Notification" field...

      I just realized while writing this, that formula fields wont trigger pipelines either

      • JamesCarr's avatar
        JamesCarr
        Qrew Assistant Captain

        My suggestion for the formula fields would be to use them in a condition step(s) to determine what path of logic to follow, and/or use Jinja to determine what to do and when. You may be able to take that approach to help you consolidate a couple of pipelines here and there. For example, I populate a rich text field for my notifications and build out my message based on values of other fields (some are formula checkboxes but others are based on particular field values) using Jinja.  If fieldA then <message> else "", if fieldB then <message> else if fieldC then <message> else "",  and so on. You could try something along these lines to reduce your pipeline footprint. Especially if different triggers currently follow similar enough paths of logic.