User Guide : Map Connectors : Source and Target Map Connectors : Salesforce
Share this page             
Salesforce, a product of, is a web-based customer relations management (CRM) software platform that enables users to access sales-related information on a Web Services repository.
Tip...  This documentation covers Salesforce version 2.5 and later. To set the version to use, before establishing a connection, enter a number for the API Version property in both the source and target datasets.
The Salesforce connector supports endpoint API version 42.0.
Salesforce is an open XML-based online platform that provides Simple Object Access Protocol (SOAP) access. SOAP provides a way for different operating systems, such as Windows and Linux, to communicate with each other. SOAP specifies the envelope for a message, expressed in XML, so a program in one computer can pass information to another computer. In addition, it specifies how the called program can return a response.
The Salesforce connector connects Salesforce data to virtually any flat file or database application. Salesforce cannot be held responsible for any use of third-party products that results in loss of or undesirable changes to data. For this reason, Salesforce strongly recommends that you use a separate Salesforce organization for testing and development and that you use, retrieve, and validate a backup of your data by using the Salesforce weekly export service. Contact Salesforce for information on establishing a separate Salesforce organization.
Tip...  Salesforce offers a test environment, called a sandbox, that is a mirrored representation of your production data and that does not access your live data. You can use the UseSandbox property to access the sandbox server. See Property Options. The test location can be accessed by logging on to the Salesforce test environment.
You may have setup tasks for which you need to contact Salesforce. In addition to using a test environment, you can back up data using the Salesforce weekly export service.
All entities exposed by the Salesforce API are supported. Entity names change with each version of the API. This connector also supports custom entities.
Salesforce provides a diagram of its sales objects and a list of standard objects in its API. If these links are no longer current, search for their updates in the Salesforce help. To use the integration platform with Salesforce, enable the API for your organization within Salesforce. Direct questions regarding Salesforce, including activating API access, to Salesforce. Be sure to mention that you are using the integration platform.
Note:  The Salesforce connector is SHA-256 compliant.
This section includes the following topics:
Connectivity Pointers
Upserts, Inserts, and Updates with Relationships
Connector-Specific Notes
Property Options
Additional Information
Connectivity Pointers
Two security connection options are available: User ID and Password and Session Token.
User ID and Password – Enter your Salesforce user ID and password to connect. The connection is limited to the access rights of the user ID. For most purposes, you should use a user ID with an Administrator profile. Use a separate user ID that is not used for normal logins.
Session Token – Enter a session token in the User ID field or pass the value to the field using a macro to connect. No value is needed for the Password field. For more information on session tokens, see Session Tokens.
Query statement syntax for this CRM connector is SOQL. For details on how to write query statements, see the application documentation.
If your company is using a proxy, enter the appropriate information into the ProxyServer field in the source or target properties. For more information about these settings, see Property Options.
Note:  Salesforce connector does not support Drop, Create, and Truncate table operations.
Upserts, Inserts, and Updates with Relationships
Upserts with relationships are especially useful if you want to insert a parent record and then upsert a related child record in the same map.
Inserts and updates with relationships are supported.
You can use external IDs to set other ID fields on an object without having to retrieve Salesforce IDs.
A special syntax in the target field value of a reference field ensures the data contains an entity name, external ID field, and a value for the external ID field relationship. Outside of this special syntax, normal values are permitted.
Creating a Custom Field for Parent or Child Entities:
In your Salesforce account, create a custom field for the desired parent and child entities with settings for the unique and externalID attributes.
See Also
To insert, upsert, or update an object that has an external ID attribute selected, but not the unique attribute selected, you must have the permissions to view all data.
For more information, see the Salesforce web site. For useful information on custom field name and relationship names, and upserts and foreign keys, see the Salesforce AppExchange Web Services API Developer's Guide.
Connector-Specific Notes
Long Connection Times. When you are connecting to a large source with many records, it may take a prolonged time to retrieve the records for viewing. If you open the Windows Task Manager, the status may say "not responding". This is expected behavior. After the records are read, the status returns "running" and you can view the records.
Daylight Savings Time. Dates and times are not automatically changed for daylight savings time. Make adjustments to your data as needed for your location.
Access Rights
Records. You are only able to access or modify records in Salesforce that are available to the user ID that you are using. Therefore, some records may only be read-only.
Tables. Some Salesforce tables are only visible to a user ID, or only modifiable by a user ID, depending on the user permissions or on the features that are enabled for your organization.
Fields. Some fields in certain tables are read-only, or can only be set during insert, not during update operations. For example, the Last Modified Date and Last Modified By fields are read-only. They are implicitly set each time a user modifies a record. The Owner ID fields on each table can only be set using the integration platform during insert. You must transfer ownership within the Salesforce application to change an Owner ID on existing records. Also, some fields in the Case table cannot be changed after the records have been inserted. Finally, some tables, such as User and Product do not allow deletes. You can, however, mark records in those tables as inactive.
Recycle Bin. You cannot access the Salesforce recycle bin using the integration platform.
Restricted values. Some fields have restricted values. Most commonly, all cross-reference ID fields (those fields that end with ID) must be references to valid entities of the appropriate type that the user has access to. For more information on ID fields, see the procedures for Cross Reference IDs, Direct Updates, and Deletes and Lookups.
Because of these restrictions, some insert, update, or delete operations may be rejected if the operation is not allowed for that user, or if the information is invalid. Check the the integration platform log to verify which records were sent properly.
Configuration Tables. Some of the Salesforce tables that are accessible, depending on your access rights, are configuration tables, such as User, Product, Role and Profile. The User table is a list of users defined in your Salesforce organization. You can determine user information and Owner IDs that are listed in another table by querying the User table. You can also provision new users, provided you have licenses available, or update existing users using the User table through the integration platform. Note that you cannot change the active status of a user with the integration platform.
Property Options
You can set the following source (S) and target (T) properties.
API Version
Salesforce API version to use. This property must be set before establishing a connection. Default is 42.0.
2.5 and later
Allows you to leave ID fields blank and let Salesforce create the ID with its own dynamic rules, or allows you to use a default assignment rule.
None is the default, which indicates that no assignment rule should be used. Using Default Assignment Rule applies the assignment rule that the account administrator has assigned as the default. This option applies for Lead or Case entities only.
2.5 and later
Path to a batch response file, which captures selected messages, errors, and other information returned through the connection. The file can be written locally after connecting to a Salesforce server. It contains detailed results for each object in a batch where the batch size is greater than one. This is useful in the following cases:
You need to capture system-generated object IDs for use in future updates
You need to correlate an error with its object and have enough information about the error for exception handling and error diagnosis
For more information, see Data File Formats.
MaxBatch Setting
The MaxBatch property must be set to greater than 1, or no batch response file is written.
2.5 and later
Allows you to download and check field IDs for matches when doing updates, deletes, or upserts with the action key as the field ID. Default is false.
The effect of this property can vary with the MaxBatch value.
2.5 and later
Source property: Controls how many records the server is asked to send at one time. The default is 200 and the maximum is 2000.
Target property: Controls how many records are sent in one group for each insert, update, or delete operation. The default is 200 and the maximum is also 200.
Note:  The maximum value for the MaxBatch source property in Salesforce API versions 5.0 and earlier is 500.
If you use a large number in this setting, you may see faster transformation run times. However, larger numbers may increase the need for memory. If you experience memory problems, lower the number.
For more information, see MaxBatch.
16.0 and later
Contains your proxy user IDs and passwords. Separate the entries with a colon, as in userid:password.
16.0 and later
Contains your proxy server name. You can append a port number by separating it with a colon, such as name.of.proxyserver:80.
8.0 and later
Displays the Salesforce records as either partial or fully qualified record names. The default is partial. The full option displays each child record with its full name separated by a period. For instance, if Contact is a child of the parent Account, the child record name is Account.Contact.
For duplicate record type names, set this property to full to see the hierarchy of parent-child relationships of all record types, including different child record types with the same names.
Note:  This property is applicable only when the source connection is a query statement or a file.
16.0 and later
Specifies that the 'queryAll' REST method should be used, rather than the 'query' method. This will retrieve all archived and deleted records, in addition to the records that would be retrieved with the 'query' method. If a query statement is entered that includes the ALL ROWS clause, the query will be sent using the 'queryAll' method, regardless of the setting of this property.
2.5 and later
Determines whether to resend request message on error. To resend even if an error occurs, set to true. If the resent message also results in failure, no entries are added to the batch response file for the failed records.
When set to false (default), if a TCP error or timeout occurs when receiving a response, the request message is not resent. Instead, the HTTP session returns an error.
In addition, if batch response is enabled and an error occurs while sending an insert, update, delete or upsert request, each record in the failed batch is listed in the batch response file with this error message: "Error or timeout reading response from Salesforce".
16.0 and later
Sets the connection session timeout value. Default is 2 hours. Options include, none, 30 minutes, 1 hour, 2 hours, 4 hours, and 8 hours.
Set the session timeout property to match the value that appears in the Setup tab in Salesforce.
This property is supported for user ID and password connections only. If you are using a session token to connect, there is no session timeout, and this property is ignored.
8.0 and later
Triggers autoresponse e-mail rules for lead and case transactions. Default is false. For more information, see Automatic E-mail Properties.
8.0 and later
Triggers an external e-mail message when a case contact is edited. Default is false. For more information, see Automatic E-mail Properties.
8.0 and later
Triggers an e-mail message to internal users in the organization. Default is false. For more information, see Automatic E-mail Properties.
2.5 and later
Allows you to decide whether nulls or empty strings are sent to the server. The following options are available:
Always (default) Nulls and empty strings are always sent to the server to set fields to null.
NullOnly Null values are sent to the server, but empty strings are not sent.
Never Null values and empty strings are never sent to the server.
2.5 and later
Points to mirror test database for client sandbox testing. Allows you to easily switch between a sandbox server and a production server.
The available options are:
False: Indicates a sandbox should not be used. This is the default setting.
True: Connector constructs a URL to connect to Salesforce test areas.
<Paste Macro>: Use this option to specify a macro value. This value must evaluate to either true or false.
For more information, see the Salesforce documentation.
2.5 and later
Provides a pass-through mechanism for SQL connectors where advanced users can construct the Where clause of the SQL query themselves. It can be used as an alternative to writing a lengthy query statement. You may use this to instruct the SQL database server to filter the data based on a particular condition before sending it to the integration platform. There is no default value for this property.
Note:  This property is not applicable when the source connection is a query statement or file. This property enables data filtering when you select a table.
Automatic E-mail Properties
When you insert, update, upsert or delete records on the Salesforce server, you can add an extra header to outgoing SOAP messages. If you set any of the target e-mail properties to true, the extra header is added to the SOAP message, indicating that automatic e-mail rules should be triggered. Any properties whose value is false are omitted in the EmailHeader. If all properties are set to false (default), the EmailHeader is omitted from the SOAP message. Configure automatic e-mail rules on Salesforce for your organization.
You can set the MaxBatch property to determine what size batch to send to the server. The server also submits the maximum batch size it allows. The integration platform uses the smaller of these two values.
For example, if you set the MaxBatch property to 50 and the server tells the integration platform that 200 are allowed, the application uses 50 (because it is the smaller number). If you set the MaxBatch property to 200 and the server indicates 100, then 100 is used.
Tip...  If you use a large number in this setting, you may see faster transformation run times. However, larger numbers may increase the need for memory. If you experience memory problems, lower the number.
To retrieve the ID of a newly inserted record
If the ID field is present in your record layout, and you want Salesforce to retrieve IDs for newly inserted records, do the following:
Set the MaxBatch property to the value of 1; then the ID of the new inserted record is retrieved from Salesforce at run time and is placed in the ID field. If MaxBatch is not set to 1, the ID field is ignored.
To obtain the correct number of errors
Set the MaxBatch property to the value of 1. This ensures the correct error count is returned.
To avoid interleaving of child record types
If the number of records returned from a query is greater than the batch size set by the MaxBatch property, the returned record set is divided into batches. If subqueries return multiple child record types, the first batch contains a representation of the entire hierarchy with a partial number of child records from each subquery interleaved in the result.
An interleaved result with three subqueries presents the parent record and then some of the first children, some of the second children, some of the third children, then the rest of the first children, the rest of the second children, and the rest of the third children in the following batches. All records are returned but not in sequential order.
If this interleaving is not wanted, try to set MaxBatch high enough so that the parent and all of its children can be delivered in one response without their needing to be split into batches. The maximum MaxBatch value is 2000.
Data Types
Salesforce offers the following data types:
Multipicklist (see note below)
Text Area
The Multipicklist data type is the same as the standard Picklist data type field, except that you can select multiple values instead of only one.
Additional Information
This section includes the following:
Performance Notes
Session Tokens
Security Tokens
Importing Records
SOQL Parsing
Cross-Reference IDs
Direct Updates and Deletes
Updating Salesforce Account Ownership
Date Formatting
Filtering Salesforce
Connecting to Alternate Servers
Connecting to Alternate Endpoints
Unmapped Fields
Performance Notes
Time-consuming operations may cause the server to become slow for your organization. The effect on performance is related to the complexity and number of requests, as well as HTTP transmission rates, and loads on Salesforce servers. In rare cases, a server may become blocked and you may need to wait for it to clear.
You can improve the performance in these cases by reducing the impact of the transactions:
Only update records that are required. For instance, if you are updating 100 records with new information, do not include additional records in the update that have no effect.
Reduce the size of queries. Restrict queries by using filters to minimize the number of records returned. In particular, you may use the Last Modified Date to get only new records.
Use Direct Updates. "Normal" nondirect updates do an implicit query, usually of the whole table. Use direct updates when you already have the Salesforce ID. In cases where you are matching on other fields, you may want to manually do a more restricted query to obtain the necessary Salesforce IDs. Similarly, use direct deletes when possible.
If you are updating existing Salesforce records, querying them first, modifying them offline and then updating them with the integration platform, the best method is to query the Salesforce ID and use Direct Updates and Deletes to update the records.
Session Tokens
Session tokens enable you to connect using a session token instead of logging in using a user name and password. This allows you to log in once by an external method, and reuse the session connection information for multiple instances or components.
Reusing the session information is more convenient and provides better performance than repeatedly sending a user ID and password information for each connection.
Tip...  Session tokens expire after two hours by default. You can change the session token timeout in Salesforce under Security > Controls.
A session token consists of a sessionID and serverURL. The session token must be in the following format:
where sessionID is a unique ID associated with your session and serverURL is the URL of the webservice that processes subsequent URI calls.
If you are calling a map from within a process, create the session token as a macro. Enter the macro in the User ID field in the session window.
To obtain a sessionID and serverURL for a session token, use the Salesforce Login Invoker.
Security Tokens
For added security, Salesforce only permits access from a specified range of IP addresses within an organization. Access from a computer with an IP outside the range requires an additional security token. This token can be e-mailed to the principle e-mail address associated with an organization and used from any computer. The token takes the form of a login name, and uses the original password for the account. Do not share the token with other users.
For information on obtaining and using a security token, see the Salesforce documentation.
Importing Records
The following example discusses the proper way to import Accounts and Contact records into Salesforce using new data, as well as existing data from a legacy system or prior software, based on the information about Lookups.
For this example, assume that you have two tables in some local database, one for Accounts and one for Contacts. Further, the Contacts table indicates the Accounts that each Contact is one. The linkage of Contacts to Accounts is through some field, or combination of fields, in the Account and Contact tables.
That linkage could be through the Account name. The Contact table could have a column named "Account Name" that indicates the Account Name that each Contact is associated with. Note that you cannot directly insert the Account Name into the Contact table.
The linkage may be through some combination of fields, such as the Account name and address.
The linkage may be through some third-party ID field, such as your own internal Account Number. In those cases, you should define a custom field on the Account table for that external ID field. When you insert the Account records, make sure to map that field and insert those IDs into the custom field in Salesforce. You can delete the custom field later, when the import is complete.
Insert the Accounts into the Account table, including any columns needed to link the Account and Contact tables.
Query the Account table for the Account ID field, plus any columns needed to link the Account and Contact tables, such as the Account Name or external ID custom fields. Store that query in a temporary local DB.
Note:  You cannot perform direct lookups on the Salesforce database within a transformation. To use the return of a Salesforce query in a transformation, store the return in a local database and use this temporary database in your transformation.
Insert the Contact records using an integration platform lookup function for the Account ID field to cross-reference the Contact and Account tables. Use the incore lookup both for speed and to preserve case-sensitivity on the lookup data.
SOQL Parsing
The Salesforce Object Query Language (SOQL), is used to construct query strings for the queryString parameter in the Salesforce query call. According to Salesforce, "SOQL allows you to specify the source object (such as Account), a list of fields to retrieve, and conditions for selecting rows in the source object."
This connector supports multiple record types when connecting to a data source using a relationship SOQL query. The SOQL feature was added to support relationship join queries. When retrieving source records, the connector finds the record type related to the query and populates it. The results of relationship queries are displayed using partially-qualified record names.
The following code examples take advantage of the SOQL query grammar that allows relationship joins. You can type these queries in the Query Statement or Query File parameters in a session.
Examples of SOQL Relationship Queries
Child-to-Parent Relationships
SELECT Id, Name, Account.Name FROM Contact WHERE Account.Industry='Retail'
Parent-to-Child Relationships
SELECT Account.Name, Account.Id, (SELECT Contact.FirstName, Contact.LastName from Account.Contacts) From Account where Account.Name like 'DJ1%'
Alias Notation
SELECT a.Name, a.Id, (SELECT c.Id, c.FirstName, c. LastName, c.AccountId FROM a.Contacts c) FROM Account a where Name like 'DJ1%'
Field Name Notation
SELECT Name, (SELECT CreatedBy.Name FROM Notes) FROM Account where Name like 'DJ1%'
Where Clauses in a Subquery
SELECT Name, (SELECT LastName FROM Contacts WHERE Title like 'QE') FROM Account WHERE Industry='Retail'
If the ALL ROWS clause appears in the SOQL query, it will be ignored while parsing the query statement, and will be removed when sending the query to Salesforce. In this case, the query will be sent using 'queryAll'.
More Information on SOQL
See the Salesforce API documentation for specifics on relationship join queries on the Salesforce web site.
Cross-Reference IDs
Fields ending with "ID" in Salesforce are cross-referencing IDs. The value in a cross-reference ID field must be a valid Salesforce entity ID that the user has access to and it must be of the appropriate type.
IDs in Salesforce are case-sensitive, alphanumeric values. Be careful when comparing or looking up Salesforce IDs in some other system to ensure that it is done in a case-sensitive manner. For more information, see Lookups.
You can determine the cross-reference entity ID by querying the appropriate Salesforce table using the integration platform, or from within Salesforce using reports.
Entity IDs can be generated through the Reports tab in Salesforce by selecting to display the particular column in either step 2 or 3 of the Report Wizard. The step number depends on whether you are running a tabular or summary report.
Some cross-reference fields in Salesforce allow for an empty cross-reference. In these cases, you can clear the cross-reference field by setting it to a string of 15 zeroes (000000000000000). For more information, see Direct Updates and Deletes and Lookups.
Direct Updates and Deletes
Records in Salesforce are referenced by unique entity IDs. Using the integration platform, you can update or delete records using other keys and the integration platform determines the appropriate entity IDs for you by doing an implicit query of the table and matching the keys.
When you already have the Salesforce entity IDs for the records that you want to update or delete, it is faster to use "Direct Updates" (or deletes).
To use direct updates or deletes
1. Map the ID of the entity that you want to update or delete.
2. Specify target keys for the update or delete only the ID column.
3. Within Target Keys and Output Mode Options, select the following options:
Update Mode: Update FIRST matching record and drop non-matching records.
Update Fields: Update only mapped fields.
Note:  If you select the Insert ONLY Non-matching Records Update Mode, the Update Fields option changes to Update ALL Fields. This is the expected behavior.

This configuration generates an error message advising you that the Update All Fields option is not supported. Due to limitations or restrictions in the Salesforce API, Update ALL Fields cannot be implemented and is not a supported option. The error message is the only method available at this time to communicate this limitation.
Updating Salesforce Account Ownership
In connections to Salesforce 16.0, it is possible to update account ownership in the OwnerID field if you have the Transfer Record permission granted by an administrator login in Salesforce.
The integration platform can automatically determine the appropriate Salesforce entity ID when updating or deleting records and matching on a field other than the ID field. When joining data across tables in Salesforce, though, you must either already have the proper cross-reference entity ID, or you must use a the integration platform lookup function to obtain it.
The ILookup Function instructs the integration platform to look for specific data in a field in the source file and replace that data in the target file with values from an external table.
To perform lookups
1. Insert the Account records, or whichever records do not require any cross-reference IDs for insert.
2. Query the records you just inserted using the integration platform. Query the ID field, plus any fields that you need to uniquely identify the records, such as the name, address, or some external ID and store the result in a temporary table.
3. Insert the Contact records. For the Account ID field on the Contacts record, use an integration platform lookup function to look up the appropriate Account ID for each Contact record.
Salesforce entity IDs are case-sensitive. Take this into account when linking the lookup table within a map. You may need an expression to deal with case based on your source. Applications such as Excel are not case-sensitive and may cause import errors or bad data in the system. Remember also that incore lookups have better performance. See the mapping help topics for details on creating lookups in maps.
Date Formatting
Some fields in Salesforce are time stamp or date fields that need time stamp or date values when inserting or updating those fields. The integration platform can help you transform data as necessary.
Some other data sources have an explicit notion of a time stamp or date field also, while some deal with these as strings. For example, Oracle and SQL Server have an internal notion of a time stamp or a date, while Excel, ASCII, and Unicode delimited files do not. For text-based files, such as Excel or ASCII/Unicode text files, use the CDate() or DateValMask() functions to transform the dates to the internal time stamp or date type.
The DateValMask Function is used to convert formatted date strings into real date values based on a date edit mask.
DateValMask(Fields("Field Name"), "mm/dd/YY1950")
The CDate Function coerces a date string into a Date data type.
CDate((Fields("Field Name"))
Filtering Salesforce
If you are using Salesforce as a source connector, be aware that an expression filter in SourceFiltering works in a different way than other connections. If an expression complies to specific syntax, the query is sent to Salesforce with the Salesforce API and the filtering is done there, prior to the records being retrieved across the network.
This can greatly improve the speed of a transformation.
If a query does not meet the limitations, but is still a valid filter for the integration platform, all the records are retrieved and the filtering is performed locally.
To be transmitted to Salesforce, the expression must be in the following format:
field <comparison> value
Only numbers, strings, field references, TRUE and FALSE, and the DATEVALUE() and DATEVMASK() functions are permitted. These can be combined using conditional operators, such as greater than, less than, and equal to. The IF… THEN… ELSE statement can also be used with the limitation that the IF condition must be TRUE. See the following example:
If Fields("Location") == "TX" And Fields("Type") <>"Rent" Then
End If
The above is filtered at Salesforce and only the records that have a Location of "TX" and a Type other than "Rent" are retrieved.
A query that uses other expressions, such as the following, requires all the records to be retrieved over the network and then filtered locally:
Left(Trim(Fields("First Name")),1) == "J"
Note:  Local filtering is performed on all Source records whether valid filtering takes place at Salesforce or not, but as it is the same query this does not have any effect.
Connecting to Alternate Servers
To connect to a server besides Salesforce, use the environment variable DJ_SFDC_LOGINSERVER.
1. Before launching the integration platform, open the System Control Panel and select the Advanced tab and then Environment Variables.
2. In the System Variables section, click New.
3. Enter DJ_SFDC_LOGINSERVER in the Variable name field.
4. Enter the name of the server in the Variable value field.
Connecting to Alternate Endpoints
To connect to a different endpoint, use the environment variable DJ_SFDC_ENDPOINT.
1. Before launching the integration platform, open the System Control Panel and select the Advanced tab and then Environment Variables.
2. In the System Variables section, click New.
3. Enter DJ_SFDC_ENDPOINT in the Variable name field.
4. Enter the endpoint in the Variable value field.
Connecting to Alternate Salesforce Instance URL
To connect to a different Salesforce Instance URL, use the environment variable DJ_SFDC_INSTANCE_URL.
1. Before launching the integration platform, open the System Control Panel and select the Advanced tab and then Environment Variables.
2. In the System Variables section, click New.
3. Enter DJ_SFDC_INSTANCE_URL in the Variable name field.
4. Enter the URL of the Salesforce instance that you want to connect to in the Variable value field.
For debugging Salesforce transformations on Windows systems, use the environment variable DJ_SFDC_DEBUG. It enables the writing of request and reply files of the XML data sent to and received from the Salesforce server. These files, named post.request.n and post.reply.n, are written to the current working directory.
The creation of these files has a performance cost, so running them in a production environment is not recommended. However, they can be helpful for troubleshooting issues when working with technical support engineering.
1. Before launching the integration platform, open the System Control Panel and select the Advanced tab and then Environment Variables.
2. In the System Variables section, click New.
3. Enter DJ_SFDC_DEBUG in the Variable name field.
4. Enter Yes in the Variable value field.
Unmapped Fields
If you run a map that includes unmapped fields and connects to Salesforce, the integration platform does one of the following:
If the map was created in version 9, all unmapped fields are marked as NULL.
If the map was created in version 10 and you did not specify a batch response file, all unmapped fields are ignored unless all of the following conditions apply:
The fields are creatable (metadata value is true).
The fields are not nillable (do not allow a nil or null value).
The fields do not have a default value.
If these three conditions exist for a field, the integration platform returns an error message stating that the field requires a value.