# Trigger Performance/Efficiency Differences **URL:** \ **Category:** General\ **Tags:** triggers, best-practices, master-data\ **Created:** [February 12, 2025, 2:54pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805 "2025-02-12T14:54:32Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jmlowden](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/jmlowden/32/8645_2.png) [@jmlowden](https://community.tulip.co/u/jmlowden)\ **Post date:** [February 12, 2025, 2:54pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/1 "2025-02-12T14:54:33Z")
I’m puzzling through the optimial architecture for master data in a Tulip Table and wondering whether there would be any meaningful differences in performance/efficiency between these two approaches: A) Create my table records with IDs that I can call up directly based on the barcode scan output - will require expressions to string together non-adjacent sections of the barcode to construct the table record ID that would be loaded. ![image](https://us1.discourse-cdn.com/flex020/uploads/agilemfg/original/2X/4/4051229dc005a28a4b85637c56ecd7555c8a560a.png) B) Using a table aggregation to get the ID of the record I need to load based on the content of the barcode scanned Option A is going to require a higher level of rigor for creating table records, as I would need to add variant suffixes to the GTINs to prevent duplicate IDs. Option B could use random IDs, but I’m wondering if using barcode scan output from earlier triggers as app input for a table query to produce an aggregation result might have some performance issues if the aggregation doesn’t load in time for the subsequent device trigger to load the table record. ![image](https://us1.discourse-cdn.com/flex020/uploads/agilemfg/original/2X/3/3fa34946bf318a15e3082a925cba27c92f30deaf.png) **Was this ever an issue with earlier LTS? Is it still an issue now? Am I worrying about nothing?** ---
**Author:** ![jmlowden](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/jmlowden/32/8645_2.png) [@jmlowden](https://community.tulip.co/u/jmlowden)\ **Post date:** [February 13, 2025, 4:29pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/2 "2025-02-13T16:29:01Z")
For reference, the lookup table would have something like 200k rows. ---
**Author:** ![koncvaker](https://avatars.discourse-cdn.com/v4/letter/k/51bf81/32.png) [@koncvaker](https://community.tulip.co/u/koncvaker)\ **Post date:** [March 20, 2025, 9:04am UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/3 "2025-03-20T09:04:56Z")
I have similar concerns and thoughts about our clients application about performance and subsequent triggers after aggregation. Can you share your experience? How did you solve it in the end? ---
**Author:** ![Beth](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/beth/32/5987_2.png) [@Beth](https://community.tulip.co/u/Beth)\ **Post date:** [March 21, 2025, 12:05pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/4 "2025-03-21T12:05:51Z")
Hi @jmlowden and @koncvaker - I checked in with some of our solution engineers on this! In terms of evaluating Option A and Option B for Best Practice - Neither are “bad practice”. **Solution Requirements:** - **Option A:** Requires maintaining a barcode schema, managing printing (or ordering) the labels, and creating/maintaining Tulip trigger expression logic everywhere (which might be easier with [reusable logic](https://community.tulip.co/t/come-to-product-office-hours-march-26-11am-et-learn-about-the-future-of-reusable-logic-in-tulip/14167) coming in the future) - **Option B:** Requires understanding Tables queries/aggregations (and things like how to use Mode aggregation), and creating/maintaining [special Tulip trigger expression logic](https://community.tulip.co/t/quick-tips-autoincrement-table-records/3980) everywhere. There should be no performance concerns with either approach. And, for the record, 200k records is pretty minimal compared to other customer usage (we have customers with over 1 million records running aggregations and such just fine 🙂 ) So really up to you which option you prefer here! As always, goal is to try and keep things simple, especially for future app builders in your org, so if you feel one of these options is simpler in that sense, that could be a good one to choose also. ---
**Author:** ![koncvaker](https://avatars.discourse-cdn.com/v4/letter/k/51bf81/32.png) [@koncvaker](https://community.tulip.co/u/koncvaker)\ **Post date:** [March 23, 2025, 8:18am UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/5 "2025-03-23T08:18:09Z")
Hi @Beth, Thank you so much, for your insight! So just to make sure, that I understand this correctly if I: 1. Change aggregation paramaters 2. Reference aggregation data 3. Do something based on aggregation data The next trigger will always work with a loaded aggregation data, there is no possibility that the aggregation won’t load in time, and ruin the next triggers? The triggers will wait for the aggregation to refresh and then continue working? ---
**Author:** ![jmlowden](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/jmlowden/32/8645_2.png) [@jmlowden](https://community.tulip.co/u/jmlowden)\ **Post date:** [March 24, 2025, 5:25pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/6 "2025-03-24T17:25:48Z")
I haven’t run into a situation yet where a lagging aggregation update has caused an error, so it might just be hypothetical problem / red herring. That said, if you have a table write or play sound trigger these seem to cause a small delay in trigger execution which can allow time for display refresh for visualization of rapidly changing widget data (such as when step-looping). ---
**Author:** ![jmlowden](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/jmlowden/32/8645_2.png) [@jmlowden](https://community.tulip.co/u/jmlowden)\ **Post date:** [April 8, 2025, 1:39pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/7 "2025-04-08T13:39:14Z")
Update: I just ran into this situation where a lagging aggregation is causing an error - I think it has something to do with that I am poplating a variable from one aggregation and then relying on that variable as an input to the query for a subsequent aggregation. The error I am seeing is that if I try to write the two aggregation results to variables in adjacent trigger actions within the same trigger, the second aggregation is writing the “old” result into the variable. Device trigger for this series of actions is barcode scanner output. Still troubleshooting, will try splitting the trigger and other things to see what works. ---
**Author:** ![jmlowden](https://sea2.discourse-cdn.com/flex020/user_avatar/community.tulip.co/jmlowden/32/8645_2.png) [@jmlowden](https://community.tulip.co/u/jmlowden)\ **Post date:** [April 8, 2025, 6:06pm UTC](https://community.tulip.co/t/trigger-performance-efficiency-differences/13805/8 "2025-04-08T18:06:07Z")
Splitting the second aggrecation call into a subsequent trigger seems to have fixed it!