Condition debugging in workflow run logs

Today we're launching a step change in your workflow run debugging experience with our new enhanced conditions debugger that surfaces the conditions we evaluated across step, channel, and preference conditions for each step in your workflow.

Previously, we showed a single log line telling you conditions were not met on step and channel evaluation, leading to a confusing user experience in understanding exactly what caused the condition to not pass. Now, with our new conditions debugger, you can get a clear picture of all of the conditions we evaluated when executing your workflow, including exactly what the variables you're referencing in the conditions evaluated to.

You can read more about the debugging conditions in the documentation.

Sliding batch window support

We've added support for sliding windows in our batch function. Previously, when a batch was opened the window for which the batch was open was static, meaning that there was no way to extend the window to accumulate more items inside of the batch. Today, we've added a new "sliding" feature on our batch windows so that any new activities that are added to the batch will extend the window that the batch is open by recomputing the batch window.

You can read more about sliding batch windows in the documentation.

Fixes and improvements

  • 👀 We added a new contains_all operator to complement our existing contains conditions operator.
  • 🐛 We fixed an edge case with our user and object upsert API where overriding a null property with an object would cause an API 500.
  • 🐛 We fixed an issue where \n characters could cause an issue with push templates.
  • 🐛 We fixed a regression where syntax highlighting was broken in our code editor.