Salesforce Exporter

📘
The Salesforce Bulk API documentation can be accessed here

🚧
Important Note on Data Management

We recommend testing this connector using credentials from a staging environment to ensure data flows as intended. Given that the reports can overwrite existing data or create new entries, please proceed with caution when executing them to prevent any unintended changes.

Set up

To get set up with the Salesforce exporter connector you will need the following:

Username - Your Salesforce username.
Password - Your Salesforce password.
Domain - If your Salesforce application is hosted at https://tea-pot.my.salesforce.com, the domain is tea-pot.my.salesforce.com, excluding the https:// portion.

Features

Feature	Support	Notes
API reliability	🟢	Reliable

Reports detail

⬇️ Report	🔑 Incremental key	🔑 Primary key	📄 Link to API endpoint
Create Objects	`N/A`	`N/A`	Bulk create records
Create Objects (Custom)	`N/A`	`N/A`	Bulk create records
Failed Job Results	`N/A`	`N/A`	Failed Job Results
Failed Job Results - Bulk	`N/A`	`N/A`	Failed Job Results
Update Objects	`N/A`	`N/A`	Bulk update records
Update Objects (Custom)	`N/A`	`N/A`	Bulk update records
Upsert Objects	`N/A`	`N/A`	Bulk Upsert
Upsert Objects (Custom)	`N/A`	`N/A`	Bulk Upsert

Failed Job Results Bulk report

Fetches line-level failure detail for Salesforce writebacks automatically, using the
Bulk API v2 failedResults endpoint. The report
reads the IDs of failed jobs from a warehouse table you prepare from the writeback's
own response table.

How it works

A writeback (Create Objects / Update Objects / Upsert Objects) runs and stores its
Salesforce job-info responses in <destination-table>_responses. Each row's RESPONSE
column holds the job JSON, including id, state, and numberRecordsFailed.
You run a transform (below) that reads that _responses table and writes a new table
containing only the Job IDs that had row-level failures.
This report exports that Job-ID table, calls/failedResults once per Job ID, and stores each response (the failed records plus their sf__Error messages) in <source-table>_responses.

Prerequisite

The writeback must have already run, so its <destination-table>_responses table exists
and is populated.

Step 1 — Prepare the Job-ID table

Create a single-column table of the Job IDs to inspect. Only jobs that reached
JobComplete with numberRecordsFailed > 0 have anything at the failedResults
endpoint, job-level failures (state = 'Failed') carry their reason in errorMessage
instead and should not be sent here.

CREATE OR REPLACE TABLE SALESFORCE_FAILED_JOB_IDS AS
SELECT DISTINCT
       TRY_PARSE_JSON(RESPONSE):"id"::STRING AS JOBID
FROM   <your_schema>.<writeback_table>_RESPONSES
WHERE  TRY_PARSE_JSON(RESPONSE):"numberRecordsFailed"::NUMBER > 0
  AND  TRY_PARSE_JSON(RESPONSE):"id" IS NOT NULL;

Notes:

The column must be named JOBID
CREATE OR REPLACE rebuilds the full queue each run and will re-fetch historical
failures. For repeated/scheduled use, make it incremental (e.g. filter on
_KLEENE_EXTRACT_DATE, or anti-join against an already-processed set).

Step 2 — Configure and run the report

In the extract:

Report → Failed Job Results (from table).
Source table → the table from Step 1 (SALESFORCE_FAILED_JOB_IDS).
Save and run. No Job ID input is required, the IDs come from the table.

Output

Results land in <source-table>_responses (e.g. SALESFORCE_FAILED_JOB_IDS_RESPONSES),
one row per Job ID. Each row's URL column ends in /failedResults/<jobId> so you can
tell which job each set of failures belongs to, and its RESPONSE column holds the
failed records with Salesforce's sf__Error message per record.

Notes

Two failure modes. This report only covers row-level failures (specific records
rejected by a job that otherwise completed). Job-level failures — a whole batch
rejected for a bad field name, wrong object, or malformed CSV — never reach the
failedResults endpoint; their error is in the errorMessage field of the writeback's
_responses table. Capture those separately from _responses if you need them.
Empty is normal. If a queued job turns out to have no failed rows, its
failedResults response is empty, no error, just no detail. Keeping the Step 1 filter
(numberRecordsFailed > 0) avoids queueing such jobs in the first place.

Limitations

📘
Behaviour of exporter (and additional table for logging)
Whenever you run these reports the connector will store the requests in a table in the same schema with the same name as the destination table + _responses
so if you export little_pond.big_fish, it’ll be little_pond.big_fish_responses
The rows will contain the first level of the request map flattened (like url, method, headers, etc) as columns, and then a response and error columns with the response or error that came from that request.
In subsequent runs, the new rows will be appended to that same table.

📘
Update and Upsert Reports

To Update: The source table must contain the Salesforce Id for each record you wish to modify.

To Upsert: Using an External ID field (e.g., customExtIdField__c), you must specify this field in the extract setup and include it as a column in the table being exported.

📘
Custom Reports

Use the Custom report option to manually input an object name if your Salesforce object does not appear in the dropdown. A list of standard Salesforce objects can be found here.

📘
Failed Job Result report
In the destination_table_response , if the numberRecordsFailed field in the Response column > 0 , you can query the failed records separately due to the asynchronous nature of the Bulk API.

Input the ID from the response column into the Failed Job Report to identify why the API job failed.

Point the extract to the same warehouse table as the original attempt.

The destination_table_response will be updated with the results of the new query.

🚧
Batch Sizes

There is a limit of 15,000 batches allowed in a 24 hour period. Each Job, which is equivalent to a report run can not exceed 150 MB.

🚧
Troubleshooting INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST errors
If your Salesforce export fails with:
INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST: bad value for restricted picklist field: <VALUE>:<Field>__c
Salesforce rejected a value that isn't accepted for the target picklist.
What to check in Salesforce:

Value exists and is active in Setup → Object Manager → [Object] → Fields → [Field] → Values. Watch for trailing spaces, case mismatches, or unusual characters.

Value is enabled for the record type under Setup → Object Manager → [Object] → Record Types → [Record Type] → [Field]. It must appear in Selected Values, not just Available. This is the most common cause of values that work in one org but fail in another.

For multi-select picklists, every ;-separated value is validated individually. One missing value fails the whole record, and the error usually names only the first one. Diff your full source values against the picklist to find all gaps at once.

🚧
Empty Source Table

If the source table contains zero rows at the time of export, the extract will fail. Ensure the table has at least one row before running.

Important Note on Data Management

Set up

Features

Reports detail

Failed Job Results Bulk report

How it works

Prerequisite

Step 1 — Prepare the Job-ID table

Step 2 — Configure and run the report

Output

Notes

Limitations

Behaviour of exporter (and additional table for logging)

Update and Upsert Reports

Custom Reports

Failed Job Result report

Batch Sizes

Troubleshooting INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST errors

Empty Source Table

Troubleshooting `INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST` errors