Input and output Values
Autopilot
Merged in a post:
View Raw Inputs and Outputs in Automation History
J
JG
The information available in automation history is too limited to be useful for debugging. Viewing raw inputs and outputs would improve the experience.
Jon Darbyshire
Great to hear your perspective, Quintin Pearson! I have a few more questions for you:
- Can you provide an example of a specific scenario where the current display of input and output values has hindered your troubleshooting process?
- What specific information about the input and output values do you believe would be most helpful to see in the automation run history?
- Are there any specific types of runs (successful, failed, etc.) where this additional information would be particularly useful?
Quintin Pearson
Sure! Jon Darbyshire
Firstly, If we can see (possibly select) a trigger record to have some data visible that would be amazing. That way when mapping your trigger values in the following steps it's easier to see what you are mapping. Especially when it comes to linked records it can be quite unclear what exactly you're mapping. You might also have similarly named columns in different tables or steps that just further hinders the speed of creating automations.
Another useful location would be in the history. In the case of values not existing, it would be useful to see their mapping value(field title) just to know what field is causing the issue without needing to exit the history and go back to check the mapping in your steps.
Also in history you get the record URL and a bunch of id's for the trigger record, but you can't see the actual field values of that record. I think seeing the trigger record's field values along with the empty mappings(field titles) down the line would allow you to troubleshoot in one place, rather than needing to open a new tab to look at the table for record values, go back to the automation to look at field mappings and then hope the 2 correspond (without having the reference from your selected trigger).
I think it would be useful in both successful and failed runs. sometimes you'd like to come back to the history and search for a run based on other criteria, and if the info is available, it would be much easier to find where the problem was even if it's user related and not an actual failed or errored run. I hope this makes sense at all :)