Airdrop

With DevRev's Airdrop, you can migrate data from various platforms or keep data in sync between DevRev and external sources. Whether you perform a one-time import, set up a one-way sync, or establish a two-way sync, Airdrop supports a flexible data migration or co-existence strategy.

Airdrop features

The Airdrop features available vary per external source but support one or more of these:

• 1-time import: Migrate data from an external source to DevRev.
• 1-way sync: Keep data in sync from an external source to DevRev.
• 2-way sync: Synchronize data bidirectionally between DevRev and an external source.
• Recipe manager: Select the types and fields you want to import or sync from an external source.

General process

Setting up a new import or sync

For best results, imports should be done using an administrator account on the external source. This ensures all necessary permissions are available to complete the import successfully.

Whether you want to perform only a one-time import or set up an ongoing sync, performing an initial import is required.

1. Navigate to Imports: Go to Settings > Imports and click Start Import or Import.

2. Choose Source: Select the external platform (for example, Jira, Zendesk) from which you want to import data.

3. Initiate the import process, which brings in enough data and metadata to allow you to configure the rest of the process.

4. Configure the Import: Configure the import settings, such as selecting specific objects and mapping fields.

For source-specific instructions, see Available Sources.

Post-import options

After a successful import, you have several options to manage and sync your data:

• Sync to DevRev: Synchronize new items created and modifications made in the external source to corresponding items in DevRev.

• Sync to External Source: Synchronize new items created in DevRev and modifications made in DevRev to the external source.

• Periodic Sync: Enable automatic periodic sync to keep data updated between DevRev and the external source.

• View Report: Access detailed information about the initial import and subsequent syncs.

• Delete Import: Remove the import and associated items from DevRev.

• Edit Connection: Modify the connection settings for future actions. This can be used if the connection goes stale or the connection owner leaves the company.

Historical imports

You can view information about currently running and previous imports from various sources, providing insights into migration activities.

To view existing imports, follow these steps:

1. Go to Settings > Imports.

Apply sync filters to imports

• Sync status:

After an import, you can view the sync status of the imported items. The sync status indicates whether an item is in sync with the external source or if there are any discrepancies. You can apply the following sync status filters to the records:

• Succeeded: The import was successful, and the record is in sync with the external source/DevRev.

• Modified: Minor modifications were made to the record, but no constraints were violated.

• Staged: Data model constraints were violated, such as contact and account mismatch.

• Failed: The record was not synced.

• Sync date:

  You can filter the records based on the sync date. This filter helps you retrieve the records that were synced in or out at a specific time.

• Sync origin status:

  You can filter the records based on the sync origin status. This filter helps you retrieve the records that were synced in or out from the external source. For example, items synced in from Jira, Zendesk, and Salesforce Service.

• Sync unit:

You can filter the records based on the sync unit. This filter helps you retrieve the records that were synced in or out from a specific sync unit in the origin system, such as syncing from a specific project in Jira.

Record view

Airdropped items now have an icon at the top of the record, next to the display ID and subtype which indicates:

• Source origin system
• Sync Status
• Sync Date
• A convenient link back to this item in the external source

You can identify the imported items by the identifier right next to the display ID in the vista view without switching. You can use sync filters in vista view too.

Dev user deduplication

When migrating data, ensuring the accuracy and consistency of the data is paramount. This section describes how Airdrop handles potential duplicates and the processes that can be used to clean up duplicates.

Dev users are team members, specifically, they're considered members of the DevRev organization. Examples of Airdrop-created dev users include engineers working on imported Jira issues, support agents who own imported Zendesk tickets, and account owners for imported Hubspot accounts.

When importing external dev users, the email address is used as a means of deduplication.

Dev user deduplication logic

User has no email or it's not accessible

A new dev user is created in DevRev. This user is marked as Unassigned. Unassigned users can't log in and have no access to DevRev. All work, comments, and assignments imported from the external source and associated with the external user are associated with the unassigned DevRev user.

This user can be manually merged with an existing user.

User has an email but doesn't match any existing DevRev user email

A new dev user is created in DevRev. This user is marked as Shadow. Shadow users cannot log in and have no access to DevRev. All work, comments, and assignments imported from the external source and associated with the external user are associated with the shadow DevRev user.

If a new user joins DevRev and that user's email matches the email of the shadow user, the person joining assumes the existing shadow user. The shadow user is marked as active and can access DevRev. All the work, comments, and assignments remain with the now-active user.

This user can be manually merged with an existing user.

User has an email that matches an existing DevRev email

No new dev user is created in DevRev. All work, comments, and assignments imported from the external source are associated with the existing DevRev user with the matching email.

Manual dev user merging

There are cases where the automatic Airdrop dev user deduplication logic doesn't catch duplicates. This can happen when an imported user has no email address or the email address doesn't match that of an existing user in DevRev. In these cases, a DevRev admin can manually resolve these duplicate entries after the Airdrop import.

To do this, find the duplicated Airdrop-created user and merge it with the desired active DevRev user.

1. Be a DevRev admin.
2. Find the duplicated Airdrop-created user.
3. Merge the duplicated Airdrop-created user with the desired active DevRev user.

Find duplicated Airdrop-created user

You can find Airdrop-created users that weren't deduplicated into an existing user with a few different methods:

1. Perform a dev user search (CMD-K/Ctrl-K). You can search by name or email and in some cases by unique external ID (such as Jira user ID).

• Select the user in imported records.
  • You can click on users on records, such as an imported issue they own.
• Find the user in the dev users list.
  • You can go to Settings > User Management > Users and filter by Unassigned and Shadow users.

Merge duplicated user

The merge dev user option is only available from Unassigned and Shadow users with Active users and must be performed by a DevRev admin. The merge option will move all records owned by the unassigned/shadow user to the active user. The unassigned/shadow user will be deactivated, and any future imported items will be assigned to the active user.

Timeline events, such as comments made or actions taken in existing records, aren't updated and continue to reference the now-deactivated user.

To perform a merge:

1. Open the list of Unassigned or Shadow users.
2. Select the action ⋮ menu > Merge User.
3. Find the Active user you wish to merge with.

Account deduplication

DevRev accounts help you keep track of your customers. Airdrop can import accounts from various external sources. Accounts from external sources can have varying names, such as companies in Hubspot, organizations in Zendesk, or accounts in Salesforce.

An Airdrop doesn't deduplicate imported accounts; rather, it modifies them so that new accounts don't violate DevRev constraints. These accounts can be merged after the import has been completed. Since DevRev has several constraints on the uniqueness of different DevRev account fields, Airdrop avoids breaking these constraints by following these rules when another account is already using the unique value:

Manual account merging

Accounts, whether natively created in DevRev or migrated via Airdrop, can be merged by a DevRev administrator.

To perform a merge:

1. Open the account you want to merge from.
   • This account will be the one that will be deleted.
2. Select Merge from the account action menu (⋮).
3. In the Merge dialog, select the account to merge into.
   • All associated discussions with the account you want to merge from will be deleted.
   • All associated users, conversations, tickets, and workspaces are preserved in the account to be merged with.
   • Any future items synced via Airdrop (such as new users or tickets) associated with the account you want to merge from will be associated with the account to be merged with.
4. Click Merge.

Contact deduplication

DevRev contacts help you keep track of your customers. Contacts are the individual users, which may or may not be associated with an account. DevRev contacts aren't globally unique. The same user may have multiple contact records.

Airdrop imported contacts are deduplicated against existing contacts. The user email is used as the deduplication field. The deduplication happens at the account level. Contacts without an account are treated as being in the same pseudo-account. When a contact is deduplicated, the records and comments of the incoming contact are associated with the existing contact.

The following scenarios illustrate how this Airdrop contact deduplication mechanism works:

Work deduplication

Airdrop doesn't deduplicate work objects (issues, tickets, opportunities). Unlike identity objects (users, accounts), these objects do not typically have duplicates in other systems.

Airdrop scope and limitations

Airdrop does its best to bring over as much data as possible as accurately as possible but there are some limitations due to data model or platform differences. The following is a list of Airdrop scopes and limitations to keep in mind when performing an Airdrop. These are generic limitations that apply to all Airdrop sources, source specific limitations can be found under the specific source.

Attachments

• Attachments bigger than 250 MB are not transferred to DevRev.
• Attachments of certain prohibited file types (for example binary/octet-stream) are not transferred to DevRev.

Concurrency

• Multiple sync units from the same source don't run concurrently.
  • Examples include multiple projects from the same Jira site or multiple GitHub repositories from the same organization.
  • These "sync units" from the same source are automatically synchronized (one after another) as they cannot overlap.

Connection

• All actions on the external source are performed by the user that established the connection in DevRev for that source.

Data model constraints

• Links
  • Parent/child relationships deeper than 3 levels are not created in DevRev.
  • Links from external systems are mapped to the closest equivalent in DevRev.
  • Links with no plausible DevRev equivalent are dropped, such as links between tickets.
• Contacts
  • DevRev does not support contacts in multiple accounts. Contacts imported that belong to multiple accounts are only created under one account in DevRev, the relationship to other accounts is dropped.
  • Contact changes of Account in an external system are not reflected in DevRev after the initial sync.

Dates

• Creation and Modified dates of synced items will not match those of the source. Source creation and modified dates are preserved and available in DevRev in the field external_source_data.

Deletion

• Deletion of synced items is not propagated. This includes works (issues or tickets), accounts, users, links, and other types. When an item is deleted (either in DevRev or at the source) and that item exists at the other end, it will not be deleted but no further updates to it will be made.

References

• In-text references (such as @mentions) will not be remapped.

Schema changes

• If a new type is added to the external source after the initial sync, it will not be automatically picked up by Airdrop.

Available sources