DevRev's ServiceNow import allows you to perform a sync from ServiceNow to DevRev. The ServiceNow AirSync focuses on ITSM and CSM products of ServiceNow.

Supported objects

The following is a list of ServiceNow objects and their corresponding DevRev equivalent.

All subtypes of task are imported as tickets. The task table in ServiceNow can be extended to create custom table types.

Below is a list of common task subtypes that are supported for import. The format shown is ServiceNow Label / DevRev Subtype Name (servicenow_table_name),

where the first part is how it appears in ServiceNow, the second part is how it will appear in DevRev, and the table name in parentheses is the ServiceNow database table name*:

• Problems (problem)

• Request Subtasks/Sn Creatorstudio Child Task (sn_creatorstudio_child_task)

• Tasks/Sn customerservice Task (sn_customerservice_task)

• Asset Tasks (asset_task)

• Requests/Sc Request (sc_request)

• Catalog Tasks/Sc Task (sc_task)

• Stale CI Remediation (stale_ci_remediation)

• Cases/Sn Customerservice Case (sn_customerservice_case)

• Change Task (change_task)

• Guidance Tasks/Help Guidance Task (help_guidance_task)

• Roster schedule entry proposal (roster_schedule_span_proposal)

• Requested Items/Sc Req Item (sc_req_item)

• Developer Collaboration Tasks/Sn Collab Request Dev Collab Task (sn_collab_request_dev_collab_task)

• Tickets (ticket)

• Follow On Tasks/Cert Follow On Task (cert_follow_on_task)

• Knowledge Feedback Tasks/Kb Feedback Task (kb_feedback_task)

• KB Submission (kb_submission)

• Escalations/Sn Customerservice Escalation (sn_customerservice_escalation)

• Service Tasks (service_task)

• Guided Setup Task (gsw_task)

• Renew Lease Tasks/Statemgmt Renew Lease Task (statemgmt_renew_lease_task)

• Transfer Order Line Tasks/Alm Transfer Order Line Task (alm_transfer_order_line_task)

• Deployment Requests/Sn Deploy Pipeline Deployment Request (sn_deploy_pipeline_deployment_request)

• Change Phases (change_phase)

• Change Requests (change_request)

• CMDB Multisource Recomp Tasks (cmdb_multisource_recomp_task)

• Asset Reclamation Requests (asset_reclamation_request)

• Zero Touch Refresh Fulfillment Requests/Sn Itam Ztr Fulfillment Req (sn_itam_ztr_fulfillment_req)

• Feature Tasks/Release Task (release_task)

• Request Tasks/Sn Creatorstudio Task (sn_creatorstudio_task)

• New Application Tasks/Sn Creatorstudio New Application Task (sn_creatorstudio_new_application_task)

• Required Field Remediations (required_field_remediation)

• Alm Transfer Order Line Subtasks (alm_transfer_order_line_subtask)

• Upgrade History Tasks (upgrade_history_task)

• Private Tasks/Vtb Task (vtb_task)

• Remediate Duplicate Tasks (reconcile_duplicate_task)

• Reclassification Tasks (reclassification_task)

• Problem Tasks (problem_task)

• Release Phases (release_phase)

• Report Access Requests/Sys Report Access Request (sys_report_access_request)

• Business Application Requests/Business App Request (business_app_request)

• Scan Tasks (scan_task)

• Orphan CI Remediations/Orphan CI Remediation (orphan_ci_remediation)

• Recommended Field Remediations/Recommended Field Remediation (recommended_field_remediation)

• Standard Change Proposals (std_change_proposal)

• CMDB Data Management Task Control/CMDB Data Management Task (cmdb_data_management_task)

• Group approvals/Sysapproval Group (sysapproval_group)

• Chat Queue Entries/Chat Queue Entry (chat_queue_entry)

To ease the transition from ServiceNow ITSM/CSM to DevRev, you can choose to
import your ServiceNow data into DevRev. The import is a 1-time bulk import of
your ServiceNow data into DevRev. Once this import is complete, several options
are made available for that project.

Setting up the ServiceNow connection

When creating a connection to ServiceNow, you'll need:

• Your ServiceNow instance URL (e.g., https://yourinstance.service-now.com)

• Valid credentials with appropriate permissions.

• ServiceNow Customer Service Management (CSM) plugin must be installed and activated on your instance.

Project import

If you do not want to import all the objects, you can select the objects you want to import in the Mappings required phase.

Import duration and tracking

The duration of the import depends on several factors:

• Small imports (< 100 items): Typically complete in minutes to seconds

• Medium imports (100-10,000 items): May take 30 minutes to a few hours

• Large imports (10,000+ items with attachments): Can take several hours to days

DevRev respects ServiceNow API rate limits and automatically handles back-off and retry logic.

You can monitor the import progress in the AirSync dashboard, which shows:

• Current phase (Extraction, Transformation, Loading)

• Any errors or warnings

To import from ServiceNow, navigate to Settings > Integrations > AirSyncs then select
AirSync (or Start AirSync if it's your first). From there, create a new connection to a
ServiceNow site or use an existing connection if you already have one. Once the
connection is established, you can start the import. At this point, you are
prompted to configure how to import your ServiceNow data.
This includes the ability to set a time-scoped sync, allowing you to import data from only the last 7 days, the last 1 month, or a custom start date.

Time-Scoped Sync

To optimize performance and only bring over relevant data, you can filter your import based on when the data was updated. During configuration, you can choose to sync:

• Recent Data Only: Limit the import to the last 7 days or last 1 month of data.

• Custom Start Date: Specify a custom historical start date to import all data from that specific day forward.

Periodic Sync

Periodic sync automatically keeps your DevRev and ServiceNow data synchronized on a recurring schedule. This is ideal for organizations that want to maintain ongoing bi-directional sync without manual intervention.

Setting up periodic sync

1. Complete an initial import

2. Navigate to Settings > Integrations > AirSyncs

3. Locate your imported project

4. Select ⋮ > Set Periodic Sync

5. Configure sync settings:

   1. Sync direction: Choose bidirectional, ServiceNow to DevRev only, or DevRev to ServiceNow only

   2. Frequency: Default is once per hour

How periodic sync works

• Runs automatically at the configured interval

• Only syncs changes since the last successful sync

• Processes new items created or updated in either system

• Updates existing items that have been modified

• Logs all sync activities in the View Report

Disabling periodic sync

To stop automatic syncing:

1. Go to Settings > Integrations > AirSyncs

2. Locate the project

3. Select ⋮ > Set Periodic Sync

4. Press Stop button

You can still perform manual syncs after disabling periodic sync.

Post import options

After a successful import, you have the following options available for the imported project:

• Sync to DevRev:

  • This option allows you to synchronize any modifications made in ServiceNow with the corresponding items previously imported into DevRev.

  • It also creates new items in DevRev for any new items created in ServiceNow after the last sync or import. This is a one-time operation.

• Sync to ServiceNow:

  • This option synchronizes any changes made in DevRev to previously synced ServiceNow supported items back to ServiceNow.

  • It also creates any items marked in DevRev for creation in ServiceNow. This is a one-time operation.

• Periodic Sync:

  • By enabling this option, you can automatically sync new changes from ServiceNow to DevRev on a periodic basis. The default frequency is once an hour.

• View Report:

  • This option allows you to access detailed information about the initial import and any subsequent syncs performed.

• Delete Import:

  • If you wish to remove the import and all items that were imported from ServiceNow into DevRev, you can use this option.

• Edit Connection

  • Use this option to change the connection used for any subsequent actions. It can be helpful if a connection becomes inactive or the user who established it is no longer available.

Setting up the import recipe

A ServiceNow import is highly configurable, and the configurations for a specific import are referred to as the recipe. Here are some guidelines on what to expect:

• What type of work to create in DevRev?

  • You have the option to import ServiceNow objects as DevRev tickets and as DevRev incidents.

• What ServiceNow types to import?

  • ServiceNow contains various types of objects. All are subtypes of Tasks or Incidents type.

  • You can select which ServiceNow objects you want to import.

• How to map ServiceNow fields to DevRev fields?

  • DevRev tries to automatically and sensibly map your ServiceNow fields to corresponding fields in DevRev, but it may prompt you on how you want to map certain fields.

  • Some stages will have to be mapped by user.

Field mapping

DevRev automatically maps common ServiceNow fields to DevRev equivalents:

• short_description → Title

• description → Description

• state → Stage

  • Note: For extended task tables, ServiceNow may use table-specific state fields following patterns like {tablename}_state or {partial_tablename}_state. Examples:

  • incident_state for incidents table

  • problem_state for problems table

  • request_state for sc_requests table

• priority → Priority

• assigned_to → Owned by

• created_by → Created by

• Custom fields can also be mapped during the import configuration

Attachments

We support attachments on the top‑level record (ticket/incident/cases - task subtype), those will sync between systems when allowed.

• Inline attachments inside comments (in ServiceNow or DevRev) are not supported for sync and will not be synced between systems.

• Workaround: attach files to the ticket/task rather than embedding them in comments.

Sync from ServiceNow to DevRev

After a successful import from a ServiceNow account, you can choose to sync the imported data with DevRev. This feature replicates any new items and any changes made to previously imported items from ServiceNow.

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

1. Go to Settings > Integrations > AirSyncs.

2. Locate the previously imported project.

3. Select ⋮ > Sync ServiceNow to DevRev.

Sync from DevRev to ServiceNow

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

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

1. Go to Settings > Integrations > AirSyncs.

2. Locate the previously imported project.

3. Select ⋮ > Sync DevRev to ServiceNow.

Mark a DevRev ticket for syncing

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

For example, if you want to sync a new case to a ServiceNow account, this would show as ServiceNow / case.

After a DevRev work item has been marked for syncing, it's created in the specified ServiceNow account the next time the Sync from DevRev to ServiceNow 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 ServiceNow.

ServiceNow permissions

Required ServiceNow permissions

To successfully perform a ServiceNow AirSync, the user should have admin permissions.

Mandatory table access (Read):

• sys_db_object

• sys_dictionary

• sys_choice

• sf_state_flow

Required for data import:

For all other tables you wish to import (incidents, tasks, accounts, etc.), the user must have read access or that data will not be imported.

ServiceNow is highly customizable and is it possible to add which role should have access to which table. If you create a new role only for extraction and add permission to read mandatory tables, then you can import data without admin permissions.

Recommended ServiceNow permissions for successfully importing a ServiceNow import

To successfully import a ServiceNow import, user should have admin permissions.

Required ServiceNow roles for successfully importing a ServiceNow import

Users that we want to import as DevUsers should have following roles:

• sn_internal: This tells that the user is internal to the organization and not a customer.

Recommended ServiceNow roles for successfully importing a ServiceNow import

Recommended roles for users that we want to import as DevUsers:

• admin: This tells that the user is an administrator of the ServiceNow instance.

• sn_internal: This tells that the user is internal to the organization and not a customer.

• sn_customerservice_agent: This tells that the user is an agent for the customer service.

• sn_customerservice_manager: This tells that the user is a manager for the customer service.

• sn_customerservice.consumer_agent: This tells that the user is an agent for the consumer.

Importing ServiceNow Permissions

When importing data from ServiceNow, DevRev also imports access control permissions so that the same security model is reflected in DevRev. This section explains which permissions are imported, how they are resolved, and what is currently out of scope.

In-scope Permissions

Not all ServiceNow ACLs are imported. An ACL is included only if all of the following are true:

• Type is record — only record-level ACLs are imported. Processor and client-callable script include ACLs are excluded.

• Operation is CRUD — only read, write, delete, and create operations.

• Record type is in scope — currently only record types in the Tasks and Incidents categories are supported. Permissions for other tables (e.g., CMDB, Knowledge Base, custom tables) are not imported at this time.

• ACL has at least one role assigned — ACLs with no roles are skipped, since there are no users to resolve.

How Allow if and Deny unless work

ServiceNow ACLs have a decision_type field that is either allow or deny. We handle them as follows:

• allow — grants the resolved users access to the specified operation on the record type.

• deny— acts as a restricting filter. If multiple deny ACLs exist for the same operation + record type combination, a user must appear in all of them (intersection) to remain eligible.

The final policy for a given operation + record type is built by:

1. Collecting all deny ACLs and intersecting their user sets.

2. Collecting all allow ACLs and their resolved users.

3. If a deny exists for the same operation + record type, only users who pass both the allow and the deny intersection are included in the final policy.

A user only needs to pass at least one allow ACL for a given operation + record type to be granted access. However, they must pass all deny ACLs for that same combination first. In other words: deny gates are conjunctive (AND), while allow grants are disjunctive (OR).

How Permissions Are Resolved

Permissions are imported and assigned per individual user.

Note on role hierarchy: ServiceNow supports role inheritance, where a parent role automatically includes the permissions of its child roles. This hierarchy is not currently respected during import. A user must be directly assigned the specific role referenced by an ACL — having a parent role that contains that role is not sufficient to be included in the permission.

Note on ACL conditions: Only role-based conditions are evaluated. Script conditions and data-based conditions on ACLs are not evaluated during import. This means if a user holds the required role, they will be granted the permission in DevRev even if they would not pass additional script or data conditions that are configured on that ACL in ServiceNow.

Operation Mapping

ServiceNow operations are mapped to DevRev privileges:

What Is NOT Imported

• Field-level permissions - Not imported

• Conditional access rules (scripts, conditions) - Not imported

• execute operation ACLs - Not imported

• Non-record ACL types (processor, script include) - Not imported

• Record types outside Tasks and Incidents - Not imported yet

AirSync ServiceNow scope and limitations

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

Comments:

• ServiceNow comment attachments are not transferred to the tickets.

• When syncing comments from DevRev to ServiceNow, attachments on comments are not transferred to ServiceNow comments.

Updates:

• Changes to certain custom fields in DevRev may not properly sync back to ServiceNow if they are read-only or not editable in ServiceNow.

• If there is no direct transition from the current ticket state to the next state in ServiceNow, the state in ServiceNow is not changed.

Closing incidents: Attempting to close incidents from DevRev may fail if ServiceNow requires mandatory closure fields (such as closure notes, resolution code, or closure category) that are not populated in DevRev. These fields must be either mapped to DevRev fields and filled, or the incident must be closed directly in ServiceNow.

Custom Tasks and Incidents:

ServiceNow is highly customizable. DevRev supports importing custom objects from ServiceNow. However, there are some limitations to keep in mind:

• We can't import tasks and incidents from custom objects.

• If custom objects wanted to be imported as tasks or incidents, then in ServiceNow we should create a table, that extends main Task table. If we want to create a custom incident table, then we should create a table, that contains incident name in it.

Troubleshooting

Import fails during extraction

• Verify the user has admin permissions or read access and/or write access to all mandatory tables

• Check that the ServiceNow connection is still active

Data Sync Issues

Items not syncing

• Ensure the short description field is not empty for tasks/incidents

• Verify field mappings are correctly configured

• Check the View Report for specific error messages

• Confirm the connection user still has appropriate permissions

Stage/state not updating

• Verify there is a valid transition path in ServiceNow workflow

• Check if the target state exists in the ServiceNow workflow

• Review custom workflow restrictions in ServiceNow

Attachments not syncing

• Check file size limits

• Verify attachment table permissions

• Ensure sufficient storage in both systems

Historical AirSyncs

To view currently running and previous AirSyncs from various sources, do the following:

1. Go to Settings > Integrations > AirSyncs.

2. Select the import you want to view.

3. Select the context menu (⋮) > View Report.

Delete import

An import and all the content it creates can be deleted from DevRev. This can be useful when running POCs or to change the recipe used during the import. Once an import has been deleted, all the content it created gets deleted, even if they were modified in DevRev. It's possible to import the project again after its deletion.

To delete an import and all the content it created, go to Settings > Integrations > AirSyncs, find the previously imported project, and select ⋮ > Delete Import.