Hi Nitin Pande,
We tried using link jobs triggered on failure or success did not work (even with time-delay setup in the link job) because the predecessor SFTP job fails before force complete - job failure (though the state is present only for few seconds) gets captured by the link job.
We also tried using JavaScript in the link job but it didn't work as expected (we are yet to explore the reason behind it).
However, we created a link job for each SFTP job to handle notifications. The link job runs only if the SFTP job has failed (exit code 1). The link job is configured with a 1-minute delay:
- If the SFTP job is force-completed within that minute, the link job does not run.
- If the SFTP job is still in FAILED state after 1 minute, the link job runs and completes, sending a notification email (PagerDuty alert) that the SFTP job FAILED.
We also had setup another Alert in the services perspective - added in the SFTP job. If the SFTP job succeeds (Completed or Force Completed by the previous Alert), this new Alert ensures that the link job is force-completed successfully, preventing false failure notifications.

We've tested the approach, and it's working as intended.
Regards,
Thendral
-------------------------------------------
Original Message:
Sent: Sep 18, 2025 10:06 AM
From: Nitin Pande
Subject: Exit codes in SFTP jobs
Hi,
You can setup two link jobs. One will release on failure, and another on success. Then link jobs then connect to your successor jobs. Here is screenshot for the jobs, see if that helps. You can setup your Javascript in the link job based on fail or completed.
HTH,
Nitin Pande
------------------------------
Support
Broadcom
Toronto
Original Message:
Sent: Sep 11, 2025 07:02 AM
From: Thendral Krishnamurthy
Subject: Exit codes in SFTP jobs
Hello Broadcom Team,
We are experiencing issues when running SFTP jobs in ESPdSeries CA Workload Automation (R12.4).
The Issue: For cases like "No matching files found" or "Read timed out", the job goes to FAILED briefly and then force-completes automatically within a few seconds (due to Alert setup in Notifications/Service perspective).

But the problem is:
- CAWA shows the FAILED status immediately for few seconds (it should ideally work that way, but PagerDuty picks that up right away, creating incidents in ServiceNow). This results in false alerts, which makes it harder for us to spot real failures.
- The Completion code / Return code which is used for differentiating failures (1) and successful (0) completion of SFTP jobs, provides 1 for all the failures and returns 0 for force completed jobs. Sometimes it also throws zero for FAILED jobs (which weren't force completed).
- We do not find any option to add custom completion code / return code (customize or add it anywhere in JavaScript, Alert, etc) for SFTP jobs. There is no way to pass along a completion code, return code, or reason in the email notification that PagerDuty/ServiceNow could use to filter.
Workarounds Attempted:
- We tested WOB._status but it works only for Alerts.
- We tested adding a link jobs. Unfortunately, link jobs also get triggered instantly on the FAILED state, before the force-complete takes effect, despite setting many dependency conditions and custom JavaScript(s) in the run frequency of the link jobs.
We request Broadcom to explore on enhancement of SFTP job type with the following capabilities:
- Support for Standard SFTP Codes: Map SFTP job results to industry-standard SFTP exit codes (e.g., 0 OK, 2 No such file, 3 Permission denied, 7 Connection lost, etc.).
- Configurable Handling: Allow customers to configure which codes should be treated as Success / Failure like we have in Unix jobs.
- Options/Filters for Common SFTP Errors: Provide built-in options or filters for common SFTP errors (like file-not-found, read timeout, permission denied). Customers should be able to tweak these behaviors directly in CAWA (e.g., configure "file-not-found" to force-complete). This would eliminate the need for complex scripting or link job workarounds.
Impact:
- Current setup generates noise and false incidents in PagerDuty/ServiceNow.
- Teams waste time checking "false" failures.
- There's also a risk of missing real failures because the noise hides them.
In addition to the above enhancement request, we would also like to confirm if there are any existing configuration options or best practices within the tool that could already address or mitigate this issue? If so, could you please share documentation or examples?
Thanks & Regards
Thendral
-------------------------------------------