Field mappings define how data flows between the Onboarded™ API and Salesforce fields. The application comes with pre-configured mappings that you can customize.
Each field mapping defines:
| Property | Purpose | Example |
|---|---|---|
| Onboarded™ Object | The entity type in Onboarded™ | Employee, Employer, Task |
| Onboarded™ API Field | The field name in Onboarded's API | first_name, email, ssn |
| Salesforce Field | The target field in Salesforce | FirstName, Email__c, SSN__c |
| Field Type | Data type for proper conversion | Text, Date, Boolean, Number |
| Sync Direction | Which direction data flows | Inbound, Outbound, Bidirectional |
| Data Authority | Conflict resolution rule | See below |
Data flows from Onboarded™ to Salesforce only. This mapping is used during GET operations when fetching data from the Onboarded™ API.
Use Case: Most standard sync scenarios where Onboarded™ is the source of truth.
Data flows from Salesforce to Onboarded™ only. This mapping is used during POST/PUT/PATCH operations.
Use Case: When you want to push Salesforce data changes back to Onboarded™.
Data can flow in both directions. The mapping is used for both inbound and outbound operations.
Use Case: Fields that should stay synchronized regardless of where changes originate.
Onboarded™ can only populate this field on initial record creation. Subsequent updates from Onboarded™ are blocked. Salesforce is the authoritative source.
Use Case: Fields you want to manage exclusively in Salesforce after initial sync.
Onboarded™ always wins. Every sync will overwrite the Salesforce value, including setting it to null if Onboarded™ sends null.
Use Case: Fields where Onboarded™ is the system of record (e.g., task status, form completion).
If the Salesforce field already has a value, it's preserved. Onboarded™ can only populate empty/null fields.
Use Case: Fields where you may have enriched data in Salesforce that shouldn't be overwritten.
If Onboarded™ sends a non-null value, it overwrites Salesforce. Onboarded null values do NOT clear Salesforce data.
Use Case: Most standard data fields where Onboarded™ should update but not delete existing data.
The Field Mapper displays all Salesforce fields in the dropdown, including fields that are not writeable (such as formula fields, auto-number fields, and read-only fields). This is intentional — these fields may play a key role in Outbound sync operations where data is sent from Salesforce to your Onboarded™ account.
When mapping Onboarded™ fields to Salesforce for Inbound or Bidirectional sync operations, the application automatically checks whether the selected Salesforce field can receive data. Error and warning prompts are displayed to ensure you are aware when a mapping configuration will be problematic.
- Error: Indicates a configuration that would cause data loss or sync failures. The mapping cannot be saved until the configuration is changed.
- Warning: Indicates a configuration that may have limitations but is allowed. The mapping can be saved after acknowledging the limitation.
| Field Type | Indicator | Field Characteristic | Impact |
|---|---|---|---|
| Formula Field | Error | Field value is calculated by a formula | Cannot receive inbound data; formula overwrites any value. Save is blocked. |
| Auto-Number Field | Error | Field value is system-generated | Cannot receive inbound data; system assigns value automatically. Save is blocked. |
| Read-Only Field | Error | Field is not createable or updateable | Cannot be written to by the application. Save is blocked. |
| Create-Only Field | Warning | Field can only be set during record creation | Works for new records, but updates will not modify this field. Save is allowed. |
Why are non-writeable fields available? Fields like formula fields and auto-number fields are included in the dropdown because they may contain valuable data for Outbound sync operations. For example, you might want to send a calculated commission amount or an auto-generated employee ID to your Onboarded™ account.
Note: Errors and warnings only appear when the Sync Direction is set to Inbound or Bidirectional, as these are the operations that write to Salesforce. Outbound mappings only read from Salesforce fields, so no writeability validation is needed.
Use the Onboarded™ Setup interface to manage field mappings:
- Navigate to the Onboarded™ Setup tab
- Click on Field Mappings
- Review existing mappings or create new ones
- Configure the mapping properties as needed
- Save your changes
Pro Tip: Reference the Onboarded™ API documentation at
https://app.onboarded.com/api/v1/openapi.jsonto see all available API fields for mapping.
Important: The Create Mapping button is only visible when Enable Salesforce Record Creation is turned on for the Onboarded™ object. This feature is specifically designed for inbound API operations where Onboarded™ data is being created in Salesforce.
The Create Mapping feature allows you to configure preset inbound values for Salesforce fields that are required for successful record creation but may not be provided by the Onboarded™ API. This is essential for satisfying:
- Required Fields: Salesforce fields marked as required that have no corresponding Onboarded™ field
- Validation Rules: Fields that must contain specific values to pass validation rules
- Record Types: Assigning specific record types to records created from Onboarded™ data
- Picklist Values: Setting default picklist selections for categorization
- Lookup Fields: Populating lookups to parent records (e.g., default Account for all Contacts)
Use Create Mapping when:
- You've enabled Salesforce Record Creation for an Onboarded™ object
- Your Salesforce object has required fields or validation rules
- The Onboarded™ API does not provide all the data needed to satisfy your org's data requirements
- You need to set constant values for categorization, routing, or business logic
Common Scenarios:
| Scenario | Field to Map | Value to Set | Reason |
|---|---|---|---|
| Record Type Assignment | RecordTypeId | Employer Record Type Label | Ensure all Employer Accounts use the "Employer" record type |
| Validation Rule | Account.Type | "Customer" | Validation rule requires Type to be set on Account creation |
| Required Picklist | Contact.LeadSource | "Onboarded™ Integration" | LeadSource is required but not provided by Onboarded™ API |
| Checkbox Default | Employee__c.Active__c | TRUE | Mark all newly synced employees as active |
| Owner Assignment | OwnerId | Integration User ID | Assign all records to a specific user or queue |
Business Requirement: Your Salesforce org uses the standard Account object for both Customers and Employers. You have a custom "Employer" record type that must be assigned to all Accounts created from Onboarded™ Employer data to ensure the correct page layout, picklist values, and business processes are applied.
Configure Object Mapping. In Onboarded™ Setup → Object Configuration, map the Employer object to the standard
Accountobject and save.Enable Salesforce Record Creation. In the Employer configuration section, toggle Enable Salesforce Record Creation to Enabled. This will reveal the "Salesforce Inbound" accordion section in the Field Mappings area.
Why This Matters: The Create Mapping button only appears within the "Salesforce Inbound" section, which is only visible when record creation is enabled. Without this setting, you won't see the option to create preset value mappings.
Navigate to Field Mappings Tab. Click the Field Mappings tab in the Onboarded™ Setup interface and locate the Employer section.
Open the Salesforce Inbound Accordion. Expand the "Salesforce Inbound" accordion section. You should see a Create Mapping button at the top of this section.
Click Create Mapping. A modal dialog will appear with the following options:
- Source Type: Choose between "Map from Onboarded™ API Field" or "Set Constant Value"
- Salesforce Field: Dropdown listing all available fields on the Account object
- Value Input: Text input for entering the constant value (only visible when "Set Constant Value" is selected)
Select "Set Constant Value". Choose the "Set Constant Value" radio button. This tells the application that you want to hardcode a specific value for a Salesforce field rather than mapping it from an Onboarded™ API field.
Select RecordTypeId Field. In the Salesforce Field dropdown, select
RecordTypeId.Special Behavior for Record Types: When you select
RecordTypeId, a checkbox labeled "Use Record Type Label Instead of ID" appears. This is highly recommended because Record Type IDs differ between Salesforce orgs (sandbox vs production), but labels remain consistent.Enable "Use Record Type Label". Check the "Use Record Type Label Instead of ID" checkbox. The value input field label changes to "Record Type Label".
Enter the Record Type Label. In the Record Type Label field, type
Employer(or whatever your record type is named).Pro Tip: Record Type Labels are case-sensitive and must match exactly. To verify your record type label:
- Go to Setup → Object Manager → Account → Record Types
- Find your Employer record type and copy the exact label
- Paste it into the field (do not type manually to avoid typos)
Save the Mapping. Click Save. The modal closes and your new inbound mapping appears in the "Salesforce Inbound" section with:
- Onboarded™ API Fields: Shows "CONSTANT_VALUE" (no API field mapped)
- Sync Operation: Automatically set to "Inbound"
- Salesforce Fields: Shows "RecordTypeId"
- Data Authority: Set to "Salesforce Controlled" (cannot be updated from Onboarded™)
Test Record Creation. Create a test Employer in Onboarded™ or trigger a manual sync. Verify that the newly created Account in Salesforce has the correct record type assigned by checking the Account detail page or running this SOQL query:
SELECT Id, Name, RecordType.Name FROM Account WHERE Onboarded_Employer_Id__c != null LIMIT 10The
RecordType.Namefield should display "Employer" for all Accounts synced from Onboarded™.
When the Onboarded™ sync process encounters a Create operation for an Employer:
Standard Field Mappings Applied: The sync process maps Onboarded™ API fields (name, address, phone, etc.) to their corresponding Salesforce fields based on your Bidirectional and Inbound field mappings.
Inbound-Only Mappings Applied: The sync process applies any Create Mapping entries marked as "Salesforce Inbound".
Record Type Resolution: If you used "Record Type Label", the application queries Salesforce for the Record Type ID matching that label for the Account object:
SELECT Id FROM RecordType WHERE SObjectType = 'Account' AND DeveloperName = 'Employer' LIMIT 1Record Created: The Account record is inserted with all mapped fields AND the RecordTypeId populated.
Data Authority Enforced: Because the mapping is set to "Salesforce Controlled", future sync operations will NOT overwrite the RecordTypeId — it's set once on Create and never changed by Onboarded™.
Cause: The "Enable Salesforce Record Creation" toggle is not turned on for this Onboarded™ object.
Solution:
- Navigate to Onboarded™ Setup → Field Mappings
- Find the Onboarded™ object you're configuring
- Look for the "Enable Salesforce Record Creation" toggle above the field mapping accordions
- Toggle it to "Enabled"
- The "Salesforce Inbound" accordion section will appear with the "Create Mapping" button
Possible Causes:
- Record Type Label is misspelled or case doesn't match
- Record Type is not assigned to the integration user's profile
- Record Type has been deactivated
Solution:
- Verify the exact Record Type Label in Setup → Object Manager → [Object] → Record Types
- Check that the integration user's profile has access to the record type
- Check sync error logs (
Onboarded_Error_Log__c) for specific error messages - If using Record Type ID instead of Label, verify the ID is correct for this org (IDs differ between sandbox and production)
Cause: The constant value you set doesn't satisfy the validation rule's criteria.
Solution:
- Review the validation rule in Setup → Object Manager → [Object] → Validation Rules
- Understand the exact criteria (formula logic, picklist values accepted, etc.)
- Update your Create Mapping constant value to satisfy the validation rule
- Test with a manual sync to verify the rule passes
Example: If the validation rule requires Account.Type to be either "Customer" or "Partner", ensure your constant value exactly matches one of these picklist options (case-sensitive).
Inbound-only mappings created via the "Create Mapping" button CAN be deleted (you'll see a delete icon next to the mapping row). If you don't see the delete button:
- The mapping might be in the wrong accordion section (Bidirectional or Outbound sections don't allow deletion)
- You might be trying to delete a standard mapping that came with the package (only custom inbound mappings can be deleted)
When an HR user clicks the Employer Task button on an I-9 task in the Employee Onboarded or Workflow Onboarded component, the application can opportunistically write the latest Work Authorization Expiration date from Onboarded™ to a Date field on your Task object.
To enable this enrichment, add a Field Mapping to your Task object with:
- Onboarded API Field:
authorized_until - Salesforce Object: your Task object
- Salesforce Field: a Date field on your Task object that will store the expiration date
- Sync Direction: Inbound (or Bidirectional)
If both Object and Field are populated, the application reads form.alien_authorized_until from the task's fields endpoint and writes it to your mapped Date field when the user opens an I-9 employer task. If either side is blank, the enrichment silently no-ops. Failures are recorded in the Onboarded™ Error Log.
Salesforce and the Onboarded™ API use different standards for country codes. The Onboarded™ application automatically handles conversion between these formats to ensure seamless data synchronization.
| System | Standard | Format | Examples |
|---|---|---|---|
| Salesforce | ISO 3166-1 alpha-2 | 2 characters | US, CA, GB, DE, FR |
| Onboarded™ API | ISO 3166-1 alpha-3 | 3 characters | USA, CAN, GBR, DEU, FRA |
Salesforce offers an optional feature called State and Country/Territory Picklists that restricts address fields to standardized ISO values. When enabled:
- Country fields only accept valid ISO 3166-1 alpha-2 codes (e.g.,
US, notUSAorUnited States) - State/Province fields only accept valid subdivision codes for the selected country
- Invalid values cause DML errors with the message:
INVALID_OR_NULL_FOR_RESTRICTED_PICKLIST
Auto-Detection: During package installation, Onboarded™ automatically detects whether your org has State and Country Picklists enabled by checking for the
BillingCountryCodefield on the Account object. If detected, theCountry_Code_Enabled__csetting is automatically set totrue.
Country code conversion is always applied for inbound data, regardless of the Country_Code_Enabled__c setting. This ensures that country codes from the Onboarded™ API are converted to the format Salesforce expects.
USA→USCAN→CAGBR→GB- Valid 2-character codes pass through unchanged
- Invalid/unrecognized codes are excluded from the update to prevent errors
Country code conversion for outbound data is controlled by the Country_Code_Enabled__c setting:
- When enabled: Salesforce alpha-2 codes are converted to alpha-3 for the API (
US→USA) - When disabled: Country codes are passed through as-is (for orgs not using State and Country Picklists)
When syncing address data to the Onboarded™ API, the following fields are recognized as address components and are automatically nested under the address object:
| API Field | Required for Outbound | Description |
|---|---|---|
street | Required | Primary street address |
secondary | Optional | Apartment, suite, unit number |
city | Required | City name |
state | Required | State or province code |
zip | Required | Postal/ZIP code |
country | Required | Country code (converted automatically) |
full_address | Optional | Complete formatted address string |
Important: For outbound API calls, if ANY of the required address fields (
street,city,state,zip,country) are missing or blank, the entire address object is excluded from the request. This prevents partial address data from being sent to the API.
Check if State and Country Picklists are Enabled. Navigate to Setup → search for "State and Country/Territory Picklists". If enabled, you'll see configuration options for managing picklist values.
Verify the Country Code Setting. Check the
Country_Code_Enabled__cvalue in your Onboarded Settings:SELECT Country_Code_Enabled__c FROM OnboardedSettings__cThis should be
trueif your org has State and Country Picklists enabled.Test with a Sync Operation. Perform a manual sync on a record with address data and verify the country codes are correctly converted in both directions.
Cause: Your Salesforce org has State and Country Picklists enabled, but an incoming country code from Onboarded™ couldn't be converted to a valid ISO alpha-2 format.
Common Scenarios:
- The Onboarded™ data contains a full country name (e.g., "United States") instead of a code
- The country code is misspelled or uses a non-standard format
- The country is not recognized in the ISO 3166-1 standard
Solution:
- Check the error log (
Onboarded_Error_Log__c) for the specific country value that failed - Correct the data in Onboarded™ to use a valid country code (e.g.,
USAorUS) - Re-sync the record
Cause: The Country_Code_Enabled__c setting may not be configured correctly.
Solution:
Query your settings:
SELECT Country_Code_Enabled__c FROM OnboardedSettings__cIf the value is
falsebut your org has State and Country Picklists enabled, update the setting:OnboardedSettings__c settings = OnboardedSettings__c.getOrgDefaults(); settings.Country_Code_Enabled__c = true; update settings;Re-test your sync operations
Note: Inbound conversion (Onboarded™ → Salesforce) always applies regardless of this setting to prevent picklist errors.
Cause: One or more required address fields are missing or blank.
Required Fields: street, city, state, zip, country
Solution:
- Verify all required address fields have values in the Salesforce record
- Check your field mappings to ensure all address fields are mapped correctly
- If partial addresses are intentional, note that the entire address object will be excluded from outbound API calls
Cause: When State and Country Picklists are enabled, state/province values must match the configured picklist values for the selected country.
Solution:
- Navigate to Setup → State and Country/Territory Picklists
- Select the country in question
- Verify the state/province code exists in the picklist (e.g.,
CAfor California,ONfor Ontario) - If the state code from Onboarded™ doesn't match, you may need to:
- Add the missing state code to your Salesforce picklist, or
- Correct the data in Onboarded™ to use the expected code
The Onboarded™ application supports all countries defined in the ISO 3166-1 standard. This includes:
- 249 countries and territories with alpha-2 codes (2 characters)
- 249 corresponding alpha-3 codes (3 characters)
Common Examples:
| Country | Alpha-2 (Salesforce) | Alpha-3 (Onboarded API) |
|---|---|---|
| United States | US | USA |
| Canada | CA | CAN |
| United Kingdom | GB | GBR |
| Germany | DE | DEU |
| France | FR | FRA |
| Australia | AU | AUS |
| Mexico | MX | MEX |
| Japan | JP | JPN |
For a complete list, refer to the ISO 3166-1 standard.
Short Answer: Mostly no, but inbound conversion still applies.
Details:
- If your org uses free-text address fields, country values like
USA,US, orUnited Stateswill all be accepted - However, inbound sync will still convert
USAtoUSfor consistency - Outbound sync will pass country values as-is (no conversion) when
Country_Code_Enabled__cisfalse
Recommendation: Even without State and Country Picklists enabled, using standardized ISO codes provides cleaner data and ensures compatibility if you enable the feature in the future.