Smartsheet Bridge: Practical Lessons from Building Real Workflows
Smartsheet Bridge is not for the faint of heart. It's a powerful tool with limited documentation, yet it's probably Smartsheet's best premium app, alongside the Control Center. Bridge is essentially a higher-grade automation tool: with scripts and API calls, you can automate virtually any workflow that Smartsheet's native automations can't handle.
Where do you start? Chances are, you have a project in mind but don't know how to begin, or you've tried and hit a wall.
Make sure to check my beginner tips first if you haven't, or some concepts here might seem foreign: Smartsheet Bridge beginner tips: What I wish I had been told when I started
Before touching Bridge, map out what you're trying to build. What does the end result look like? Given this, what intermediate steps do you need to go through? How will you handle errors or unexpected values? Answer these questions first and sketch it out. It's likely you'll need some parent/child workflow relationships, so knowing this upfront saves a lot of rework.
Of course if this is your very first time you might not know what to do at that step, so let's dive in instead.
The two main triggers are: schedule or integration. The integration option requires some configuration, but you'll most likely be using the Smartsheet integration, which is straightforward to set up.
The Smartsheet integration trigger will usually produce references you can exploit further down the workflow. Either way, I'd recommend running the trigger at least once early on, this starts populating the references you'll use throughout.
Your very first module should almost certainly be "Get Sheet." Add it, grab a sheet ID from your sheet's properties or from the trigger data, and run the workflow again. Then open the logs for that first run and explore all the information related to your sheet. For any value you want to reference dynamically elsewhere in Bridge, find the three dots on the right and choose "Copy data reference." This gives you the path to that item for every subsequent run.
It took me a long time to understand what States are actually for. They serve two purposes: first, they help you keep things organised by naming each step clearly, so you know what you're looking at in the reports. Second, they store the results of your modules, which becomes essential if you're using the same module more than once.
For example, if you have the "Get Sheet" module twice but only one State beneath both, the State will only record the last result. This makes sense once you see how references are structured: — if two Get Sheet modules share the same state name, both references are identical, and neither you nor bridge can distinguish between them.
Where you go from here depends on what you're building.
If it's a straightforward workflow, add a few more modules and States, test, iterate, and you're done.
If it's a more complex workflow with multiple steps and arrays, you'll need one or more child workflows. The concept is simple: once you have an array, pass its reference into the "number of runs" field of the child module. The data for each run is then passed into the child workflow.
The challenge arises with volume. If you're trying to pass 1,000 runs and each takes around 30 seconds, a failure at run 340 stops everything and your remaining 660 runs won't be processed. To handle larger datasets reliably, you'll need a JavaScript module to divide the data into chunks. For example instead of one array of 1,000 rows, you'd have four chunks of 250. Each child workflow receives 250 rows at a time, and at that point you'll want to use the Smartsheet API to POST those rows to your target sheet.
If you'd like a hand applying any of this to your specific use case, feel free to get in touch via the form below.