I have a very simply workflow which runs a Powershell command to retrieve information from a database and then creates a new service request based on the information in the database response. When I test the step, it works perfectly. The workflow is triggered when a request with a specific subject heading is created and it triggers correctly. When I look in the workflow log I can see that the Powershell command completed successfully and when I run the Powershell command manually, I get the expected response (a json string). The next step in the workflow is to parse the response, but this step is not logged.
To muddy the waters further, the next two steps seems to run, but isn’t logged and the step after that does not seem to execute, once again works properly when I test manually.
The execution log filter that I have applied only has the service request number, no other filters.
Page 1 / 1
Hi.
That’s actually the expected behavior, by design of the logging feature of Workflow automator.
Execution logs in Workflow Automator record only results of App action nodes of the workflows using Orchestration integration. All workflows' logs are not recorded by design
Hope this clarifies.
Regards,
Expression and Web request nodes are shown as well. But that it’s about it.
The order of the steps are as follows:
Trigger event (a ticket is raised or updated)
Condition (does the subject line start with a particular string)
Powershell command with parameters supplied from service request and expects a json string returned (This entry is logged and shows success)
Parser to extract values from json in step 3
Powershell command using values from request and parser in step 4 (this is not logged but is executed)
Parser to extract values from json in step 5
Powershell command using values from parser step 6 and parser step 4 (this is not logged and not executed)
Expression to set email address (not logged)
Action to send email to address in step 8 and close ticket (not executed)
If the workflow fails at some point, surely that should be logged? Also I see step 5 being executed but not logged. Step 7 does not execute at all.
I suspect that something happens during the execution of step 5 but the execution is not logged so I don’t know what the error is at this point and I have been unable to find a way to see what happens
I have seen if a node totally fails to execute the WFA just drops and nothing happens. I have seen this with action nodes when I try to set something or e-mail using a placeholder that is blank. To troubleshoot this I add a action that creates a note before where I think it fails example : Placeholder_name {{placeholder_name}}
Hi.
Yes, as colleagues have suggested, you may try debugging your WFA using Add Note (or even Send E-mail) in the steps where you may be facing an issue, just right before the step that fails, showing then variables you may be working with.
Answering your questions, only those special nodes are logged, either successfully executed or not. Execution of simple nodes/steps are not logged, even if it fails.
That's why we use this debugging technique.
Thas is the DIY way.
You may always submit a support case and FW Support Team will help you debugging it, but they will basically do the same creating test tickets and adding the necessary Add Note actions to see what may be going on in order to isolate the issue.
Sincerely,
Hi @AndreLabuschagne@eeha0120@Daniel Söderlund
Hope you are well, Thanks for elaborating the issue,
I see from the 5th Step, The Execution Log isn’t recording the App Node, This means the Execution of that node for the Ticket has been timed out. You can cross-verify this in Ticket Activities: It should say something like: “Waiting for Orchestration Listener” or “Waiting for another Web Request Response”
-->We wait for the response of an Orchestration Node for 23 seconds, When there is no response from the Orchestration server during that time period, we consider it a Timeout.
-->Due to this, The Workflow execution is halted and doesn’t proceed further. You can reach out to us to extend this time such that we would wait for the response of node for as long as 1 minute.
Feel free to write to support@freshservice.com to Troubleshoot this further and have the timeout flag be extended incase the response is not captured in Execution Logs.
Have a great weekend : )
@Ammar KB thank you for the response - this is the information that I was looking for. It makes sense that the second PowerShell waits for a lock to be released on the data. I will see if I can rework the process in a way that will avoid multiple updates to the same database.
