Release 269 - January 2024

Happy New Year Everyone!

New year, new Tulip. Release 269 brings many updates that improve navigation and management of Apps, Automations, and Connectors.

View the Full 269 Release Notes Here.

Let us know your thoughts and questions below!


1 Like

I want to highlight 2 things on this release:

  1. @danielpomeranz - there is now a trigger transition for “Complete App Then Go To First Step Of App By Name”. This transition is the same as “Complete App Then Change App By Name”, but will skip the splash screen for the new app and start the app on the first step. I know this is something you have been looking forward to!

  2. Linking and unlinking records is now transactional, meaning @jmlowden’s catch in this thread Should Date Updated Metadata Reflect Linking/Unlinking Updates? was fixed for LTS10.6, LTS11.1, r262, and r269

Thanks y’all for the great feedback here!

1 Like

Thanks for the update.
But why did you hide the “where used” at the connectors? :worried:

  • Its no longer visible if a Connector is not in use (you need to click through all connectors)
  • Its an additional click to see the usage and navigate to the App
  • Browser Search will no longer help to highlight all Connectors used by a specific App (before it worked at least on all connectors with less than 4 Apps… you could fix that with an App Filter)
1 Like

Definitely agree with all this!

Hey @thorsten.langner -

I’d like to provide some additional context regarding the recent changes to connectors. Connectors where used has proven to be a very challenging function to implement to a level of stability we expect from the product. To elaborate, this feature necessitated a query of every trigger action, across all triggers, in every app, and within each app version. Given the substantial volume of records involved, often reaching into the millions, the process of scanning for each connector became non-performant. Some of our customers were encountering limitations with this aggregation, and when the process failed, it had the potential to impact their instances, with the most extreme cases occasionally impacting their apps running in production. In these cases, we would entirely disable where used.

In anticipation of the 269 release, we identified an additional risk that suggested potential instability, which could extend to other customers. This compelled us to implement an immediate fix.

To address the issue in the short term, we opted to move this functionality behind the more menu, ensuring that we didn’t have to completely disable this feature for any of our customers.

We acknowledge that this adjustment represents a temporary step back in terms of usability. Simultaneously, as a part of our response, we redirected our engineering efforts toward resolving the underlying technical problem. We are actively working on implementing new design patterns that not only cater to your requirements but are also capable of performing at 10 times or more the efficiency of our largest customers. We anticipate rolling out the initial changes in approximately ~r272, with ongoing improvements planned throughout the remainder of Q1.

Thank you for your understanding and patience as we work to enhance the overall functionality and performance of our connectors. If you have any further questions or concerns, please feel free to reach out.



Hi Pete,
Thanks for this feature to put the connector “where use” behind a click, having this information “on demand” is perfectly fine for us.
Already tested in our staging and waiting this feature in next LTS for production instance.
I see that this feature is on connector level but on function level the where use is still display always. Any risk of performance issue? We have connector with more +200 functions.

1 Like

Hey @Nicolas -

Good question. The time to run this aggregation is roughly linear relative to the number of connectors in an instance, so the performance challenges is far far more pronounced on the connectors list page, than the list page for functions of a single connector.

At the most extremes, the function list can have similar issues, but these limits are significantly higher than any current customers are approaching. Relying on a single connector with tons of functions is a fairly common pattern for the heaviest connector users, so this is a pattern the underlying query has been designed around. Finding usage for a connector with 1 function and 5,000 functions is identical assuming the same number of applications, versions, triggers. We have proactively done a lot of testing here directly within the product with connectors with well over 2k functions.

With these new design patterns we plan to move where used behind a click to further future-proof as customers start moving into the realm of 10,000+ applications, millions of triggers, etc.


1 Like

Thanks for the explanation, I completely understand.

Would it be an Idea to add a symbol if the connector is in use (or better how often, if performance allows) and hide the “where used” behind this symbol?

This would make it easy to spot the unused ones as fast as before.


Which LTS release will include this?

Hey Jim - it should be in LTS 12!