Testing Workflows with `urlParams`

💬 Feature Requests
,
1

Problem

I want to be able to test my workflow in the Retool Editor with urlParams

This is the startTrigger but it only provides a method for setting data

startTrigger
startTrigger334×209 8.53 KB

Also, referencing the startTrigger doesn't even hint that urlParams is a property we can use :frowning:

missing
missing359×189 9 KB

Current Method

As far as I know, this is the only way to test your workflow with urlParams

  1. Set the trigger as webhook
  2. Copy the cURL
  3. Append the test params
  4. curl -X POST --url "https://api.retool.com/v1/workflows/<GUID>/startTrigger?taco=bell
  5. Inspect in the Editor the last run
    taco
    taco447×227 15.5 KB

Proposed Solution

Add some key/value boxes, or another JSON input field to let us add test urlParams values for validating the behavior of our workflow while staying in the Editor.

2

Hi @khill-fbmc,
You are correct in that the startTrigger doesn't even hint that urlParams is a property. However, when I tested it as startTrigger.urlParams, it still worked!

You can see in my test workflow we do get the intended taco bell!

chrome_CeUo1KNTsT
chrome_CeUo1KNTsT1049×563 41.8 KB

which is actually the urlParams you see in the run history.

chrome_ld0yYUhoTZ
chrome_ld0yYUhoTZ1003×586 41.7 KB

3

Correct, but how did you test that? did you use curl?

4

I tested it via an external http request in make.com.

chrome_ZSjA8jvDUT
chrome_ZSjA8jvDUT1236×773 45 KB

5

This is confirming my original post, that there is no native way in Retool to test a workflow with urlParams.

I feel like it would reduce friction and benefit users to keep testing a workflow all in Retool. No using an external tool, or service, or pasting in copied curls...

My Dream

I would love a way in the editor, to set startTrigger.urlParams for test runs, the same way you can set values for tests in startTrigger.data. Then we click Run and test.

2 Likes
6

Ok, got it. That would save time for sure.

I will +1 that if you put in a feature request. :slight_smile:

1 Like
7

I just logged this feedback internally - a feature like this would definitely be convenient. :+1:

I'll provide an update here as soon as I have news to share!

1 Like
8

image
image411×450 14.8 KB

YOU BEAUTIFUL PEOPLE! :tada:

2 Likes
9

UPDATE: After revisiting this, I seem to have misunderstood and misrepresented the particular feature that rolled out earlier this year. Most notably, the new startTrigger block still does not allow you to test URL parameters. It does, however, allow you to set and test headers, a JSON payload, and path parameters.

  • pathParams - When you create a webhook alias for your workflow such as /orders/{id}/status, users can trigger your workflow via https://{domain}/url/orders/{id}/status where id is a dynamic string. You can then access the dynamic path parameters via startTrigger.pathParams

You can likely refactor your workflow to use path parameters instead of URL parameters, but I'll go back to the team and request that we offer a clear solution for testing the latter as well!

You beat me to it, @khill-fbmc! We rolled this out with the release of version 3.193.0 - there's a quick blurb about the feature here. Definitely let us know if you run into any issues!

10

Hello there,

I followed the discussion, but I still have issues with this.

I can test correctly using pathParams in the Workflow editor, but when I test the public endpoint and add a URL parameter (i.e., ?id=13 appended to the URL), the pathParams object turns empty, and the hidden urlParams gets the correct value.

Here is the log by invoking the URL:

image
image686×546 31.8 KB

So, testing in the editor is possible if the code references pathParams while the published endpoint works by referencing urlParams.

As a workaround, I use something like {{ startTrigger?.pathParams?.id || startTrigger?.urlParams?.id }} in the code/query that needs to reference it.

Is it expected behavior?
Or am I missing something?

Many thanks.