Building Stored Procedure Actions: The Long Road To Doing More With Your Data

At Sigma, we’ve always made it easy to explore, model, and visualize data. But analysis is only  part of the story. The real value kicks in when you can do something with your insights without hopping between platforms or pulling in another team.

For a long time, that wasn’t possible. If you wanted to act on a next step—trigger a workflow, run a forecast, update a record—you had to leave Sigma. I saw customers doing some pretty advanced logic around what-if analysis, automated data cleanup, and system updates, but there wasn’t an easy way to initiate those workflows directly from the workbook. That gap became the spark for Stored Procedure Actions.

No jumping between tools. No awkward handoffs.

In developing this feature, my team and I wanted to make sure that users could take action from inside Sigma. With it, you can trigger stored procedures, pass in arguments, and even work with return values—right from a button or element in the workbook. No jumping between tools. No awkward handoffs. Just a way to do something with your insight, all from the same place you found it.

Behind the feature: What it took to pull this off

We kicked this off by making two key technical and architectural decisions that made everything downstream smoother.

First, we decided to build on Sigma’s new Workbook Actions framework—a powerful system that lets users trigger logic off elements like buttons or tables, pass inputs, and chain outputs. Stored procedures mapped perfectly to this model, and this gave me and the team a clean way to wrap procedural logic in a user-friendly interface. The second decision we made was to lean into familiar ground when designing permissions. Stored procedures live in the warehouse just like tables or views, and so I made our permissioning model consistent with those existing patterns. That helped keep things intuitive for users, and it made our implementation more robust.

But one of the hardest technical challenges I hit was warehouse variability. Every platform handles stored procedures differently: argument handling, overloading, default values… The edge cases were endless. To get ahead of it, I built a compatibility matrix across all nine warehouses we support. That let us spot common ground and make smart calls on where to abstract and where to go custom.

One especially tricky edge case had to do with overloaded procedures—same name, different argument signatures. That broke our system’s assumption that each object had a unique path. I ended up treating all overloads under a single path as one permission unit. That decision simplified things dramatically, while still aligning with how most users think. It was a good example of a larger principle I followed throughout the build: prioritize usability over theoretical completeness. And if customer feedback ever pushes us in the other direction, we’re ready to adapt. It’s exactly why I focused early on getting the core experience right. That really paid off because we reached GA faster, with a better product.

Prioritize usability over theoretical completeness.

One thing I personally loved discovering throughout this process was that in Snowflake, you can write stored procedures in Python. That means someone can pass a Python script into a workbook input, execute it inside the warehouse, and return the result—no extra infrastructure required. That’s wild. It shows just how much power this feature can unlock for more advanced users.

How feedback (and a lot of iteration) shaped the final build

From the private beta to public launch, customer feedback played a huge role in shaping how this feature came together. One of the first things people flagged was the stored procedure path—you had to manually enter it, which wasn’t great. A bunch of users pointed out that they liked the inode picker we already had in other parts of Sigma, so we added it. Then folks wanted to filter it down to just stored procedures. It made sense. So, we built that too.

More recently, as the public beta rolled out, I started hearing a consistent ask for support with tabular data. That hadn’t been in scope originally, but the signal was clear and now it’s officially on the roadmap for an upcoming release.

Throughout, the team and I stayed close to customers. That helped me figure out what really mattered—not just technically, but in terms of how people actually needed the feature to work. That feedback loop made a huge difference. Within the first two months of launch, over 50 organizations were already using the tool. And so far, it’s been triggered more than 12,000 times—and growing at 50% month over month.

This wasn’t built in a vacuum. It came out of tight collaboration across teams. Product brought in a real customer use case—a major prospect with a massive library of stored procedures they wanted to run inside Sigma. Design turned that into something that felt familiar and usable. Then we in engineering got to figure out how to actually make it happen. We tied it into the Workbook Actions framework, worked through the permission model, and dealt with all the cross-warehouse complexity to bring it to life.

Within the first two months of launch, over 50 organizations were already using the tool. And so far, it’s been triggered more than 12,000 times—and growing at 50% month over month.

If there’s one thing I’d pass on to another engineer working on something like this, it’s this: ground everything in real use cases. Skip the “hello world” stuff. Talk to customers. Work with actual examples. That’s what keeps the work focused—and helps you build something that people actually want to use.

‍