For non-Salesforce connectors, any job failures that occur before the execution is started do not follow the standard failure notifications that you may have configured for your job.
Gainsight’s Reason:
The notifications will only trigger once the source execution has begun. However, in our case, it failed before the execution started, as shown in the screenshot.
If we're using an SFDC connection as the source, we'll receive a failure notification even if it fails during the extract process. But for other connections like Zendesk, we won't receive a failure notification unless an Extract action has occurred.
If the job fails before the execution starts that is still a noteworthy failure that should be communicated. We configure our system to have failure notifications so that we do not have to manually check that everything is working properly every time.
That’s rough,@rachelhibbardtmo .
I’m curious to learn more: What causes a job to fail before the execution starts? What scenario or combination of events are the precursors to this happening?
This was the specific error we ran into:
Error: The job cannot be completed as the [users::updated_at, organizations::Updated At] fields were either deleted from the source or the user is not authorized to access the fields. Remove the fields from connector mappings and re-run the job
It seems as though the failure occurred during the initial field read.
This particular bug is something I first observed as being problematic a year ago, but only started causing issues last month, with the Zendesk job having duplicate Updated At fields with no means to reconcile.
We are planning to add the change in our code. Post the patch release (planned this 15th), we should be able to received job failed email notification in case of job failure due to source field deletion.