99.99% you can not…but who knows what is in the Enterprise plan 
But…is this on the Roadmap anywhere?
Doesn’t this make sense and is reasonable/doable?
Not sure what your use case is, but if it is triggering another workflow using a workflow itself, then the “webhook trigger” workflow is what you need.
It’s in beta for Business and Teams starting today.
It’s not clear what to do once the Glide webhook is triggered. How do I parse the incoming request body so that I can look up a record and then update a field? Or is this not yet possible and I should just use Make?
Can you describe more about your use case? What data flows in, and what are you trying to do with it?
Can it just be done with a relation and a set column action instead?
It’s triggered at the end of a custom form. All of the data collected is to be used to create and populate other records and I can’t think of another way to currently do that within Glide.
Can you describe your data structure?
- Build a JSON payload of add/update mutations
- Use a Call API or Trigger Webhook action to pass the JSON payload to a webhook triggered workflow
- In that workflow, you need 2 steps:
– the first step should use Query JSON to parse the incoming data payload
– the second step should use Call API to pass the payload to the Glide API
I’ve used this method and it works perfectly fine. Here is what it looks like:
-
Workflow 1 (User Triggered)
-
Workflow 2 (Webhook Triggered)
The question could be asked why not just call the Glide API directly from the user triggered workflow. That can be done, and will work, but can result in a less than optimal user experience as the Call API action will block and wait for a response from the API. By offloading this to the second workflow, this processing happens in the background without affecting the end user.
3 Likes
In the Query JSON step, are you just supposed to query one value at a time?
Also, is it possible to find a record in a specific table (via a row ID provided in the webhook request), and then update that record using the values in the request body? I’ve run into this in other workflows, where I want to look up a record and then update it, but it doesn’t seem to be possible if the record isn’t in the workflow’s source table.
It depends on what you need there. It uses JSONata, so you can be flexible.
I imagine that should be possible, as long as you can parse the ID you need.
Maybe something like this?
But if you have mutliple columns that needs to be updated, I imagine that means one more Query JSON module to get the data out in the format you need, then use a Call API step.
1 Like
Ah, ok so I just need to learn JSONata. This is so helpful, thank you!
Let us know if you need any further help with that. ChatGPT/Claude can write decent JSONata queries as well if you don’t need something too complicated.
Ok, so I just learned that I can’t use JSONata in the fields for setting the new values, but surely I don’t need a query step for each of these values right? Am I missing something?
You should only need a single JSON Query step. Just ensure that your JSON is correctly constructed in the first place so that it can be passed straight through to the Glide API. This is what mine looks like:
I Query the above and extract data, then that is posted in the body of the subsequent Call API step.
I don’t have a problem sending the data between workflows; I’ve already got that working. The issue is mapping the data to the record found in the second workflow. I want to map the business fields to the single record that I pulled from the Accounts table. From what @ThinhDinh shared, it seems like I would have to have a Query JSON step for business.name, business.ein, etc. which I would then use to populate the fields in the found record, but that doesn’t seem right, so I’m wondering if there’s a better approach.
ah, apologies - I misunderstood.
Yeah, unfortunately that is the only way for now. It is extremely cumbersome, and that point has been made to Glide, and been acknowledged. So I would expect that some time in the future there might be a better way to manage this.
1 Like