/ /
AirSync learns the external system's schema during the source-to-DevRev sync and offers those fields for mapping. This single fact explains most mapping confusion.
Field mapping
Fields that exist only in DevRev (custom fields you created in DevRev) do not appear as mappable options for a Salesforce, ServiceNow, or Jira sync and cannot be reverse-synced out. The external system drives the schema. Unmapped external fields are imported into an auto-created subtype unless you choose to omit them. For Accounts and Contacts, Salesforce custom fields arrive as app fragment fields.
Custom field missing from the mapping UI
If a custom field is missing from the mapping screen, the field does not yet exist in the source system or has not been seen by a sync.
Correct flow (Salesforce to DevRev):
Create the field in Salesforce first.
Run a Salesforce-to-DevRev sync so AirSync extracts the field metadata and creates the corresponding custom field on the DevRev subtype.
Confirm the field now appears in the mapping screen, where it can participate in two-way sync.
The same principle applies to ServiceNow and Jira: only fields that exist and are visible to the integration user in the source system become mappable.
📝 Note: Importing custom fields for users is not supported. Plan your field strategy around this limitation.
Native fields visible in the mapping UI but not on the record
AirSync exposes fields defined in the underlying DevRev object schema, including certain composite or stock fields (for example, Account Industry and Phone Numbers) that are not yet rendered in the object-customization UI. You can map to these fields and data syncs to them, but they may not appear on the object details page.
If a mapped native field is not visible on the record, this is a UI display limitation rather than a sync failure, the data has mapped. Contact DevRev support or your admin to have the field surfaced rather than assuming the import did not work.
Map fields, not values
Map a field to a field, for example, Salesforce Case Priority to DevRev Priority. If the mapping picker shows individual values such as High or Low, you have selected into a picklist's values instead of the field itself. Go back up one level and select the field.
AirSync's transformation methods operate field by field and require compatible types. If a mapping option is not offered, the source and target field types are usually incompatible.
Attachment and notes migration
Supported attachments
Salesforce: attachments on Case, Task, Problem, and Incident records sync to attachments on the DevRev ticket (import direction only).
The standard limits below apply to all AirSync sources.
Known limits
Attachments larger than 250 MB are not transferred.
Attachments of certain prohibited file types (for example,
binary/octet-stream) are not transferred.
Resolve attachment migration failures
A common symptom is a run that collects a number of attachments but migrates only a subset, with upload or content-retrieval errors in the logs.
Check the following, in order:
Verify the file size against the 250 MB limit and the file type against the prohibited types list.
Confirm the connection user has read access to the source attachment objects (in Salesforce, the Attachment and ContentDocument objects).
Open the sync run's View Report and review per-record errors and skipped records.
If a large share of attachments fails, this is often a platform-side issue rather than a configuration mistake. Note the connection name and sync run ID, then open a support ticket for investigation.
Location of imported attachments
Imported attachments are associated with their target record (for example, the ticket) and appear in that record's attachments section. If a run reports attachments created but you cannot find them, confirm which records they were attached to and check record-level access before concluding they are missing.
Notes migration
Salesforce notes migration requires the Notes object to be explicitly selected in the AirSync configuration. A migration summary showing "0 Notes collected / 0 migrated" indicates the Notes object was not enabled in the mapping.
If notes still do not import after the object has been selected, note the connection name and sync run ID and open a support ticket for investigation.
Authentication troubleshooting
ServiceNow: "User is not authenticated" (401)
Setting up a ServiceNow connection can fail at the connection-test step with the following error:
server responded with a status code 401 ... "User is not authenticated"Root cause: ServiceNow is phasing out Basic Authentication and restricts standard API access for interactive user accounts. This is not typically a wrong-password problem.
Resolution: Create a dedicated integration user for the API connection:
Assign it administrative permissions.
Set its Identity Type to Machine (this automatically enables Web Service Access Only), or check Web Service Access Only manually.
Do not modify existing admin accounts. Setting an existing admin to Machine or Web Service Access Only permanently disables their interactive UI login.
Validate the credentials from a terminal before retrying:
curl -i -u 'INTEGRATION_USER:PASSWORD' \
'https://<subdomain>.service-now.com/api/now/table/incident?sysparm_limit=1'A 200 response confirms the credentials are valid; a 401 indicates the same authentication failure.
Additional ServiceNow checks: confirm the instance is awake (developer instances hibernate), the user is active, and the user has read and write access to all required tables.
Connection user access (all sources)
Every action on the external source is performed by the user who established the connection. If that user lacks access to an object or field, it does not sync regardless of the mapping configuration.
Sync status and failure notifications
If a link between an external record and DevRev is visible on one record but not another, first confirm the sync from the external system is actually succeeding. An extraction error stops new links from appearing.
Sync failure notifications are not enabled per user by default. Subscribe the relevant users to the AirSync so they are alerted when a sync fails or is blocked.
Pre-migration checklist
Create any required custom fields in the source system first, then run one sync so they become mappable in DevRev.
Confirm the connection user has API access and read permission (and write permission, if reverse-syncing) for every object and field in scope.
For ServiceNow, use a dedicated Machine / Web-Service-Access-Only integration user.
Explicitly select every object you need, including Notes and Attachments in the mapping. Do not assume defaults.
Note the 250 MB attachment limit and prohibited file types.
Subscribe the appropriate users to the AirSync for failure notifications.
Post-migration verification checklist
Open the View Report for the run and review failed, skipped, and staged records.
Spot-check mapped fields on a sample of migrated records and confirm you mapped fields rather than values.
Confirm attachments and notes are present on their target records.
Reconcile source and DevRev counts for records, attachments, and notes.
For anything that should have synced but did not, note the connection name and sync run ID before opening a support ticket.
Worked examples
Salesforce custom field: Create Account Tier in Salesforce, run a Salesforce-to-DevRev sync, confirm the field appears on the DevRev Account subtype, then map it. Do not create it only in DevRev and expect it to appear in the Salesforce mapping.
ServiceNow authentication: Create an integration user with the admin role and Identity Type set to Machine, then retry the connection. The 401 error clears.
Missing external link: Check the AirSync status, clear the extraction error and re-run, then subscribe the owner to failure notifications.
Was this article helpful?