This is more of a knowledge question than anything specific.
If one was working on developing a full automation, lets say webhook trigger to an action, and you wanted to test the webhook to action handoff to see data coming through from the webhook into the action (without just manually entering test data within the action).
Is there a way to test that within the assembly editor or can you only do it on the automation editor?
Actions are decoupled from triggers, meaning they can be built and tested in isolation from each other. See this for a quick overview on decoupling: https://www.c-sharpcorner.com/UploadFile/dacca2/design-pattern-for-beginner-part-11-implement-decouple-cl/
This allows actions to be used in ways they may have not originally been intended. Actions aren’t confined to just automations, they can be dragged out of the catalog and used as module blocks:
Here I have dragged two actions out of the catalog and placed into a single assembly. Note this currently only works for actions that have static input fields.
Generally you don’t have to test triggers and actions in the automation editor, especially after you gain experience with the system. If triggers and actions work ok in the assembly editor, they almost always work ok in automations.
I understand. Basically i was wanting to test the webhook and display the data received to see the exact format it is in to develop my actions around.
For example, if i create a webhook that receives say 5 lines of a csv, I can see each column (a,b,c,etc) is attached to a variable with each row in that column numerated 2,3, etc. (which would be a, a2, a3, b, b2, b3, etc)
I can grab each value fine but if I wanted to pass the entire dataset through to the action as a single value, and not just separate fields, how would I go about that and how would it be formatted? I want to pass the entire data set over all at once since I need to parse the rows and depending on a value within each row, will handle it differently (may combine, may delete, etc)
In the long run that is my reason for the original question of is there a way to test the trigger and action together in the assembly editor. I thought that would give me what i needed.
If you build the actions in a way that they expect that specific payload, then those actions become only useful to that one trigger, or triggers that only emit the same CSV payload. You are coupling the actions to specific triggers, making them less generic. This is an anti-pattern, don’t go down that path unless there are good reasons.
The best design pattern is to create a custom webhook trigger that parses the CSV and emits data fields from it, just like all other triggers do. Then your actions don’t need to parse the payload, they just operate on the field values they need to process a single action.
See the Gmail “new email with CSV” action as an example: e13c087be68646ff8ffe602e569f58be
For the special cases when you really need the entire payload to be processed by an action, all webhook triggers that receive a POST payload will emit the raw payload as a mappable data field:
So your action just needs a single data field to receive the entire payload. If your test data contains no semicolons, you can define a static data field in the Action module and enter the payload into the “test data” field. Otherwise, create a subassembly to define the data field and test data, like in assembly 8503b89e763240e08b315adeb1024a9c.
