Forum Academy Marketplace Showcase Pricing Features

How can I see what parameters are passed to a backend workflow in debug mode?

I am debugging a situation where an API workflow is scheduled to create a new record but values in the resulting record suggest that the parameter values passed are not what I would expect.

Here are the two key steps of the workflow that calls the API:

Step 2 makes some changes to an Item record.
Step 3 uses some values from the result of step 2 to create a new Item record based on the result of step 2.

The result in the new Item record suggests that the last parameter is not getting the expected data passed to it but there is nothing in the debugger that shows what is actually being passed.

How can a get a look at what is being passed into the API?

NOTE: I realize the problem may be in the API workflow and I will look at that next. But even so, it would be helpful if there is a way to see what’s happening at the API workflow scheduling step via the debugger. It could save a lot of time and trouble.


+1 would love the ability to inspect backend workflows as well

Its insane that you cant step through backend workflows. The logs are really hard to work with and I have a development background. God help a no code developer. I have wasted two hours tonight trying to work out what is going wrong in a complex backend workflow. If I could step through it it would have been simple (simpler).

Bubble is such an awesome tool. WTF hasnt it got some kind of backend workflow debugger. My workflow is being triggered by a webhook so I cant think of a way to run it in the front end to see what is happening


Well, there you go. :slight_smile: I don’t even know what a webhook is. I’m just triggering my workflows from the frontend app and have no visibility into what’s happening in the backend workflow.

And in my specific case, all I really want to do is inspect what is being passed as parameters to the workflow. That should be doable in the debugger but isn’t.

Yes that’s crazy I think. They are such clever guys at bubble clearly because of how good it (mostly) is. I employ a lot of software developers in my business and they just do see what mere mortals see. I just feel like a simple backend step by step debugger would absolutely transform bubble.


For debugging backend workflow, I created a datatype to store my custom logs and using “create a new thing” action in the the workflow to put data result/parameter that I want to know. I wonder if anyone has better Idea/approach than this?


I’ve done the same thing, @hadirs. And it’s something that should be unnecessary. Bubble should provide realistic debugging tools for backend workflows.

Similarly, Bubble should be providing performance profiling tools so we developers can more effectively understand where our apps are slowing down and using more resources.


I have spent like 8 hours debugging a backend defect.

I helps with performance but if you have a bug it’s a blackbox and you’re screwed!

I have mentioned this. Its an awesome tool but its sadly lacking a backend debugging tool and also the performance tools are not great. For example I can see loads of workflows running but not drill down to see which ones they are. I have to click on a pie chart that shows me a percentage but not able to just see a list of workflows that have run in chronological order even though they have them I assume.


Definitely a +1 for this ability.

I’m sending things off to the backend workflow and obviously messing something up or missing something vital but it’s really hard to tell what. I’m expecting a backend workflow to create a new item in the database but it keeps coming up blank.

When I do the same action in the front end it seems to work consistently. Clearly something isn’t being passed or triggered correctly but I’m a bit lost as to what that may be. A debugging tool would definitely help me realise what it is that I’m not doing correctly.

There might be a clue in error log(s), but I’m not even proficient in using them.

Hope you’ve worked it out by now.

1 Like

You’re absolutely right.

The logs have proved a really useful tool for observing what’s going on and what’s been scheduled.

Definitely recommend them to anybody else reading this thread and would still recommend bubble frame them in a slightly more immediate and obvious way for users, perhaps even a link from the debugging tool front end to the logs back end with a mini explainer when an API is triggered, could help a few people to get familiar with them and improve the UX of the bubble build experience slightly.

1 Like

Oh, that’s so clever! I actually think it’s a pretty decent solution. I have created a separate /log page that looks like this (I think you’ll easily figure out how it works), and it works great:

I also created a custom “Log” event (with type of thing = text) so that I don’t have to create a thing manually every time.