Skip to Content

Map source dates to Salesforce Date fields and log response errors in Jitterbit Studio

Introduction

When writing data to Salesforce from Studio, two scripting patterns are consistently needed in transformation mappings:

  • Date field formatting: Salesforce Date and DateTime fields require values in specific string formats. When the source data contains a datetime string (for example, a database timestamp in YYYY-MM-DD HH:MM:SS format), the value must be converted to the format Salesforce expects before the write operation runs.
  • Response error logging: Salesforce write operations (such as Upsert, Insert, and Update) return a per-record result. When processing fails for one or more records, the success field in the response is set to false and an errors array is populated with one or more messages. Without an explicit check in the response transformation, these per-record failures can go undetected even when the overall Studio operation reports success.

This guide provides both scripts, explains each component, and describes where to place them.

Design pattern

Both scripts are placed in transformations within the same Salesforce write operation chain. The date conversion script belongs in the request transformation, which formats source data before sending it to Salesforce. The error-logging script belongs in the response transformation, which maps the Salesforce write operation response:

flowchart LR A[Source activity] --> B[Request transformation] --> C[Salesforce write activity] --> D[Response transformation] --> E[Target activity]

This guide assumes a Salesforce connection is already configured in the project.

Part 1: Map a source date to a Salesforce Date field

Salesforce Date fields expect values in YYYY-MM-DD format. Salesforce DateTime fields expect values in ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). The GetUTCFormattedDate and GetUTCFormattedDateTime functions produce these formats from a source datetime string. This part assumes the source field contains a datetime string in YYYY-MM-DD HH:MM:SS format and that the source time is UTC.

Step 1: Open the target Date field script editor

  1. In Studio, open the transformation where the target schema comes from a Salesforce write activity (such as Upsert, Insert, or Update).

  2. In the target schema, locate the Date or DateTime field to map.

  3. Click the field to open its script editor.

Step 2: Write the date conversion script

For a Salesforce Date field, use GetUTCFormattedDate, which returns only the date portion in YYYY-MM-DD format:

// Source field must be in YYYY-MM-DD HH:MM:SS format, expressed in UTC.
// GetUTCFormattedDate returns YYYY-MM-DD, which is the required format for
// Salesforce Date fields.
// If the source date uses a different format, apply a conversion function
// before passing it to GetUTCFormattedDate. See the date and time functions
// reference for available options.
// The third argument (false) uses non-European (month-first) date format.
GetUTCFormattedDate(<source_field>, "UTC", false);

For a Salesforce DateTime field, use GetUTCFormattedDateTime instead, which returns the full ISO 8601 datetime string:

GetUTCFormattedDateTime(<source_field>, "UTC", false);

Replace <source_field> with the path to the source date field as it appears in the transformation's source schema.

Tip

If the source data is in a time zone other than UTC, replace "UTC" with the appropriate time zone code. For example, use "America/New_York" for US Eastern time. The function converts the source value from that time zone to UTC before formatting the output.

Note

If the agent running this operation is a private agent, its system time zone may influence how the function interprets source values that do not include an explicit time zone. Cloud agents always run in UTC. For projects designed to run on both cloud and private agents, always pass an explicit time zone code rather than relying on the local system time.

Part 2: Log errors from a Salesforce operation response

Salesforce write operations return a response that includes a result array. Each element corresponds to one input record and contains:

  • success: A boolean indicating whether that record was processed.
  • errors: An array of one or more error objects, each with a message field. Populated when success is false.
  • A key field (such as an external ID or the Salesforce record ID).

Because result is an array, the response transformation loops over it once per input record. The script in this part checks success on each iteration and, when it is false, writes a log entry that identifies the failed record by its key field value.

Step 3: Add a response transformation to the operation

If the Salesforce write activity does not already have a downstream transformation that maps the response:

  1. On the design canvas, add a Transformation step after the Salesforce write activity.

  2. Open the transformation. The response schema from the Salesforce activity appears as the source, including the result node (which loops once per input record), the success and errors fields within result, and the key field from the request side of the schema.

  3. For the target schema, add a single String field (for example, response), or use an existing target schema if the response is being mapped to a downstream system.

Step 4: Write the error-logging script

In the transformation, click the target field to open its script editor. Write a script that checks success for the current result record and, when it is false, logs the key field value and error messages:

// Check whether Salesforce processed this record successfully.
// If not, log the key field value and Salesforce error messages to the operation log.
// Update the field references below to match the paths in your response schema.
// If the key field changes in your Salesforce operation, update the FindByPos reference.
If(<result.success> == false,
    WriteToOperationLog("The following record failed to process. Record: " +
    FindByPos(SourceInstanceCount(), <request.records#.keyField>) +
    " The issue was: " +
    SumString(<result.errors#.message>, ". ", false)));

Replace the placeholder references with the actual field paths from your transformation's source schema:

Placeholder Replace with
<result.success> The success field in the Salesforce response result node
<request.records#.keyField> The key field (external ID or record ID) from the Salesforce request node, using # notation to return all instances as an array
<result.errors#.message> The message field within the errors instance node of the current result record

Each function in the script serves a specific role:

  • The transformation loops over the result array, so If evaluates success once per input record.
  • WriteToOperationLog writes the error details to the operation log, where they are visible after the operation runs.
  • SourceInstanceCount returns the 1-based index of the current loop iteration. Because the result array and the request records array are in the same order, this index maps the current result back to the corresponding input record.
  • FindByPos retrieves the key field value at that index. The key field reference uses # notation to return the full array of instances so FindByPos can select the correct element.
  • SumString concatenates all message values in the errors array for the current result record into a single string, separated by ". ". If Salesforce returns multiple errors for the same record, all are included in the log entry.

Tip

If the success comparison does not behave as expected, try an explicit string comparison: <result.success> == "false". Some schema configurations represent boolean fields as strings.

Verify the integration

  1. Deploy and run the operation with a test payload that includes at least one valid record.

  2. Open the operation logs and confirm that the date field values in the Salesforce request match the expected format for the target field type: YYYY-MM-DD for Date fields, YYYY-MM-DDTHH:MM:SSZ for DateTime fields.

  3. To test the error-logging script, include a deliberately invalid record in the test payload (for example, a record that violates a Salesforce validation rule or references a non-existent related record). After running the operation, check the operation log for an entry that identifies the record by its key field value and includes the Salesforce error message.

  4. In Salesforce, confirm that valid records were created or updated as expected.