Functions Is Now Generally Available: Write Logic Once, Govern It Everywhere

Every operation is different, and none of them stand still. The App Builders and process engineers who understand the work best are also the ones under the most pressure to keep up with it. They update the same validation rule in a dozen apps, tracking down every copy of a work-order flow when one detail changes, or waiting on IT to standardize something the team already knows how to do.

Today, Functions, Tulip's reusable trigger logic capability, moves out of early access and becomes enabled by default for every workspace for all weekly customers as part of r380.

Functions let App Builders define a piece of trigger logic a single time with the same visual editor, native looping, and complex conditionals already familiar from Automations and call it from as many Apps or triggers as the operation needs. Update the Function, and every App that references it picks up the change the next time it's published. No more hunting down and manually syncing a dozen copies of the same logic.

This is authoring the way it should work: the people closest to the process, quality leads, process engineers, Centers of Excellence, building governed, reusable solutions directly, without waiting on a vendor or a central dev team to make a change ripple everywhere it needs to.

Reusable logic only helps if you can trust it, so Functions were designed to be governed from day one. When you publish an App, it locks in the version of every Function it uses, so if that Function's logic changes later, Apps already running in production keep working exactly as they did. Before editing a Function, Where Used shows you which Apps are currently building on it, so you know the impact before you make a change instead of finding out after.

And for Centers of Excellence, that reliability turns into real leverage: rather than every App Builder recreating the same sensitive logic by hand, a COE can build, review, and approve a Function once, then let the rest of the team build on top of it with confidence.

This is the same principle that runs through Tulip as a platform: speed doesn't have to come at the cost of control.

Functions has been in the hands of early adopters for months. Today, it's on by default for every workspace, along with a few capabilities early adopters asked for:

• Import/Export, so Functions travel with your Apps across instances and workspaces with Machine and User references remapped on the other side, so nothing silently points to the wrong place.
• Rename, duplicate, and archive Functions directly from the Functions list page.

None of this is theoretical. Some of Tulip's most process-heavy customers have been building on Functions since early access, and the patterns they've landed on say more about what Functions are for than any feature list could.

One mobile automation manufacturer has built two of their most heavily used Functions around unit creation, pulling an in-progress work order, or reaching into their ERP for the next open one, and work order completion, both run extensively every day across roughly 300 applications. For their process engineers, the value isn't just fewer duplicated triggers, it's readability: instead of a wall of if/then logic, they can look at a step called "create unit" and understand exactly what's happening, without needing to see what's underneath.

For another robotic manufacturer, Functions have become the backbone of a shift toward a hub-and-spoke app architecture. A small set of centrally maintained Functions handle the standard operations, while citizen developers build the specific apps around them. Table writes, in particular, are treated as function-only by design:

"If you're creating a table record or modifying it in any significant way, I run that through a function every time. It lets me be prescriptive to my citizen developers. I know that if someone's creating a unit, they're going to provide the exact same information, in the exact same way. No one's going to misuse it and break something I then have to go diagnose."
— a Solutions Engineer, on their team's use of Functions

Innovafeed, which runs a heavily automated process to produce insect-based protein, uses Functions to keep logic consistent across different versions of the same app. A single Function now defines the logic for allocating containers and generating shipping documents, called identically from both the full desktop app their planners use and the lighter mobile version their operators carry on the floor. This function replaces what used to be three separate copies of the same logic spread across different buttons. The team has also used Functions to replace a looping workaround that had gotten unwieldy to maintain, consolidating repeated logic into a single reusable component. These changes have been faster to run, more reliable, and far easier to maintain.

The best place to start is with patterns you already have. Look for the logic your team has already copy-pasted more than once: a validation rule repeated across every scan step, a work-order update sequence rebuilt in App after App, the same error-handling wrapped around every Connector call. That repetition is usually the clearest sign of where a Function will pay off immediately, both in time saved today and in risk removed the next time that logic needs to change.