/ /

Salesforce AirSync

DevRev's Salesforce AirSync allows you to perform a bulk migration, ongoing 1-way sync, or ongoing 2-way syncs. A bulk import is a prerequisite to setting up a sync.

For more information, refer to the Salesforce AirSync snap-in on the DevRev marketplace.

Supported objects

The following is a list of Salesforce objects and their corresponding DevRev equivalent. Those marked as Sync to DevRev are eligible for import/sync to DevRev from Salesforce. Those marked as Sync to Salesforce are eligible to be synced to Salesforce from DevRev.

Salesforce Object

DevRev Object

Sync to DevRev

Sync to Salesforce

Case

Ticket

✅

✅

Problem

Ticket

✅

✅

Incident

Ticket

✅

✅

Comment on Case/Task/Problem/Incident

Comment on Ticket

✅

✅

Attachment on Case/Task/Problem/Incident

Attachment on Ticket

✅

❌

Product

Product

✅

❌

Account

Account

✅

❌

Contact

Contact

✅

❌

Opportunity

Opportunity

✅

✅

Lead

Contact

❌

❌

Knowledge Article

Article

✅

❌

Custom Object

Custom Object

✅

❌

Business Hours

Custom Object

✅

❌

Asset

Custom Object

✅

❌

Order

Custom Object

✅

❌

Quote

Custom Object

✅

❌

Event

Custom Object

Opportunity History

Custom Object

✅

❌

Task

Custom Object

✅

❌

Opportunity Contact Role

Custom Object

✅

❌

Messaging Session

Custom Object

✅

❌

Messaging End User

Custom Object

✅

❌

Permission import from Salesforce

When permission extraction is enabled, Salesforce AirSync imports supported access information alongside the selected records. Permission changes sync from Salesforce to DevRev, not back to Salesforce.

Salesforce permission data

How it is used in DevRev

Profiles and licenses

Imported as groups. User memberships in those groups are kept in sync.

Permission sets and assignments, object permissions, and field permissions

Used to create authorization policies for supported object- and field-level access.

Organization-wide defaults

Used to set baseline access for internal and external users on supported object types.

Sharing rules

Supported criteria-based and guest sharing rules are converted to conditional access policies.

Record-sharing tables and Account Team Members

Used to grant users or groups read or edit access to individual imported records. This includes supported standard share tables and custom-object __Share tables.

Roles and role-related groups

Used to maintain the group memberships required for role-based record sharing.

Limitations: Not every Salesforce permission can be reproduced. Some sharing rules cannot be translated; field-level permissions on imported Account and Contact app-fragment fields are not supported. Record-sharing updates are synchronized only while the corresponding parent record type is enabled for extraction.

Importing from Salesforce

Follow the steps below to import from Salesforce:

Only Salesforce editions with API access are supported. Supported editions include Enterprise, Unlimited, Developer, and Performance. Additionally, the Professional edition is supported if API access has been purchased as an add-on. Both sandbox and production instances are supported.

Resolve OAuth approval errors

Salesforce restricts the use of uninstalled connected apps. This can prevent a user from authorizing a new Salesforce AirSync connection. The user may see “We can’t authorize you because of an OAuth error. For more information, contact your Salesforce administrator.” Salesforce may also return OAUTH_APPROVAL_ERROR_GENERIC.

Ask your Salesforce administrator to check the permissions of the user who authorizes the connection:

  1. Confirm that API Enabled is granted.

  2. Check whether Approve Uninstalled Connected Apps is available and granted. Salesforce's required permissions depend on the organization's API Access Control settings.

  3. If the organization needs API Access Control and that feature is not available, open a case with Salesforce support to enable it.

  4. Once API Access Control is enabled, open the connecting user's profile or permission set, go to System Permissions, and grant Use Any API client.

  5. Retry the connection. If authorization still fails, recheck Approve Uninstalled Connected Apps and API Enabled with the Salesforce administrator.

For more information about this Salesforce restriction, see Prepare for Connected App Usage Restrictions Change.

Connect and import

  1. Go to Settings > Integrations > AirSyncs and select AirSync (or Start AirSync if it's your first).

  2. Create a new connection to your Salesforce account, or use an existing connection if you already have one.

  3. Once the connection is established, select the Salesforce account you want to import and specify the DevRev part that should be used for any imported cases without a product. This initiates a bulk import of the selected account.

  4. DevRev makes an effort to automatically map the fields from Salesforce to corresponding fields in DevRev. However, you may be prompted to manually map certain fields if needed. You can track the migration and perform any required mapping under Settings > Integrations > AirSyncs.

View All Data requirement for comments

Verify that the Salesforce user who authorizes the connection has View All Data, not only View All on individual objects. AirSync reads FeedComments that belong to FeedItems such as CaseCommentPost and EmailMessageEvent. It must query the parent FeedItems to get those comments. Salesforce can reject a broad FeedItem query with Malformed query, FeedItem requires a filter by Id if the user lacks View All Data. In that case, the FeedComments cannot be imported even if the user can view some individual cases.

Salesforce's FeedItem documentation shows a direct query with View All Data. The following is Salesforce's example, not the AirSync query:

SELECT ID, CreatedDate, CreatedById, CreatedBy.FirstName, CreatedBy.LastName,
       ParentId, Parent.Name, Body,
       (SELECT ID, FieldName, OldValue, NewValue FROM FeedTrackedChanges ORDER BY ID DESC)
FROM FeedItem
WHERE CreatedDate > LAST_MONTH
ORDER BY CreatedDate DESC

The Salesforce Chatter data model shows the FeedItem–FeedComment relationship. A separate Apex class marked Without Sharing is another way to run some direct FeedItem queries, but this guide does not establish that as a supported replacement for the Salesforce connection user's View All Data permission in AirSync. Ask DevRev support before relying on that alternative.

The duration of the import depends on the size of the Salesforce account and the data being imported. It can take seconds for an account with only a few dozen cases to a few hours for an account with tens of thousands of cases with many attachments. DevRev honors the Salesforce API rate limits and back-off and resumes automatically.

Reported by and account on imported tickets

When AirSync imports or updates a Salesforce case as a DevRev ticket, it checks Reported by and Account together. First, it finds external contacts in Reported by and uses the first account-linked contact to identify an account. Then it checks for internal users in Reported by and compares the contact's account with the Account already on the ticket. AirSync favors contacts linked to an account over internal users and keeps reporters from only one account. This prevents a ticket from showing reporters who belong to another customer account.

Reported by before validation

Account before validation

Account after validation

Reported by after validation

Contacts linked to Account A

Account B or no account

Account A

Contacts from Account A remain; other contacts and internal users are removed.

Contacts with no account

Account B

No account

Contacts with no account remain; internal users are removed.

Internal users only

Account B

Account B

Internal users are removed; Reported by is empty.

Contacts linked to Account A and internal users

Account B

Account A

Contacts from Account A remain; internal users are removed.

If contacts from different accounts are listed, AirSync uses the account of the first account-linked contact it finds and removes reporters linked to other accounts. If a contact has no account, AirSync can clear the ticket Account rather than keep an unrelated account. Review Reported by and Account after import when source cases mix accounts, account-less contacts, or internal users.

App fragment fields

Custom fields from Salesforce Accounts and Contacts are synced into DevRev as app fragment fields. These differ from custom fields created in Object Customization:

  • App fragment fields do not appear on the Object Customization page and cannot be managed there.

  • They are visible on individual Account and Contact records in the UI once the Salesforce sync has created or updated those records.

  • App fragment fields cannot be used as filters in DevRev, including in views and vistas. Field-level permissions are also not supported for app fragment fields, so field-level access control configured in Salesforce is not replicated in DevRev.

For more on how app fragments work, see the developer documentation.

Sync to Salesforce

After a successful import from a Salesforce account, you can sync changes made in DevRev to the previously imported cases back to Salesforce. Additionally, any new DevRev tickets marked for sync is created as new Salesforce items.

To perform a one-time sync to Salesforce, follow these steps:

  1. Go to Settings > Integrations > AirSyncs.

  2. Locate the previously imported project.

  3. Select ⋮ > Sync DevRev to Salesforce Service.

This may override fields in Salesforce of previously imported items, even if they were modified in Salesforce.

Mark a DevRev ticket for syncing

Using the Sync to Salesforce feature, it's possible to sync DevRev tickets to Salesforce. In order to sync a DevRev ticket to a specific Salesforce type, it must be marked for syncing. Marking a DevRev ticket for syncing can only be done during the creation of a new ticket. During ticket creation, open the dropdown Select Subtype, set it to the type the ticket should be synced to. The format is as follows: SalesforceService / {type}.

For example, if you want to sync a new ticket in DevRev to a case type in Salesforce, this would show as SalesforceService / cases.

After a DevRev work item has been marked for syncing, it's created in the specified Salesforce account the next time the Sync from DevRev to Salesforce runs. This can be triggered manually or automatically through a Periodic Sync. Future syncs keeps this item updated on both sides after it has been created in Salesforce.

AirSync Salesforce scope and limitations

The following is a list of AirSync Salesforce scopes and limitations to keep in mind when performing a Salesforce AirSync. In addition to these Salesforce-specific limitations, there are also some generic AirSync scopes and limitations.

Comments

Threaded case comments are not synced back to Salesforce.

Updates

Updates to Picklist_MultiSelect fields from DevRev are not loaded/synced back to Salesforce.

Knowledge articles

Only published articles in the master language are imported from Salesforce to DevRev.

If the article has multiple rich text content fields, the article will be split into multiple DevRev articles, one for each rich text content field.

Sync groups as owners of tickets

A Salesforce case can be owned by a user or a queue/group. In DevRev, Owner can be a user only, so AirSync uses a separate Group field for queue ownership:

  • If the Salesforce case owner is a user, AirSync sets that user as the DevRev Owner.

  • If the Salesforce case owner is a queue or group, AirSync sets the DevRev Group to that queue or group and sets Owner to the fallback service account (shown as “unassigned” in the source guidance).

To assign the case to a Salesforce queue or group from DevRev, set Group to the matching Salesforce queue or group name and Owner to the fallback service account.

Known limitation: If only Group changes in DevRev, AirSync may skip the update to Salesforce without notifying the user. The outbound logic checks that Group changed and Owner is the fallback service account. The Owner field must also be present in the outbound update data for this check to run. An update that includes both fields can proceed; other field combinations may also work. If the Salesforce case owner does not change after a sync, check the Group and Owner values and whether Owner was included in the update. If you cannot include it, contact DevRev support rather than repeat the same sync.

Was this article helpful?