ServiceNow Incident table extraction with V2 Connectors

Question

Using the new ServiceNowV2 connectors in Azure Data Factory, we are trying to extract the incident table. When setting up a copy activity, we receive the error message below. I have tried to limit the number of records by providing a filter to small subset of records without success. Doesn't seem to be any documentation from Microsoft or any properties I can set on the Linked Service, Data set, or copy activity where I can set what is suggested by the error message. Anybody have any idea on how to solve this with a copy Activity or is this a bug in Microsoft's implementation with ServiceNow. I'm trying to get the objects dynamically in to the copy data

The API request to ServiceNow failed. Request Url: https://oneliquidsupport.service-now.com/api/now/table/incident?sysparm_limit=10&sysparm_fields=reopened_by%2cu_voice_tags%2cu_actual_start_time%2cu_peering_category%2cu_incident_fix_time%2cu_tier_type%2cu_rpt_incident_age%2cu_string_1%2cu_oem_vendor_name%2cu_first_close%2cwork_start%2cu_csm_incident%2cu_service_flag%2cu_fms_severity%2cu_sla_trigger%2cu_alert_id%2cu_customer_service_id%2cwork_end%2cbusiness_impact%2cuniversal_request%2cescalation%2cadditional_assignee_list%2cu_case%2cstate%2cclosed_by%2cu_vendor_subject%2cassigned_to%2ctime_worked%2ccorrelation_id%2corigin_table%2cu_customer_ticket_reference%2cu_incident_type%2cactive%2cwork_notes%2cfollow_up%2cu_event_counter%2csys_updated_on%2croute_reason%2csys_domain%2cu_vendor_communication%2cu_responded%2cchild_incidents%2cu_customer_category%2cu_please_provide_resolution_service_details%2cu_peering_customer%2cu_traffic_direction%2cu_owner%2cproblem_id%2crfc%2ccaused_by%2cu_ne_name%2ctask_effective_number%2cskills%2cu_incident_downtime%2cu_alert_type%2cu_service_id_received%2cu_vendor%2ccaller_id%2cnotify%2cincident_state%2ccategory%2csubcategory%2cseverity%2cupon_reject%2cu_net_service_flag%2cu_symptom%2cu_oem_vendor_case_number%2cimpact%2cgroup_list%2cwork_notes_list%2ccompany%2copened_by%2cmade_sla%2cdescription%2cclosed_at%2cactivity_due%2ccalendar_stc%2cbusiness_stc%2csys_id%2cshort_description%2capproval_set%2ccontact_type%2cu_service_order%2ccontract%2cu_sentinel_workspace_id%2csys_updated_by%2cu_resolution_service_component%2cu_knowledge_article%2csys_mod_count%2cu_please_provide_resolution_symtom_details%2cu_destinations%2cu_sla_pause%2cvariables%2cservice_offering%2creopened_time%2cclose_code%2cu_remedy_incident_number%2cu_amo_search%2cu_alert_name%2cu_inms_name%2crejection_goto%2cresolved_by%2cu_first_occurence%2cu_resource_type_search%2cdelivery_task%2corigin_id%2curgency%2cwatch_list%2cu_internal_peering_request%2cx_moogs_incident_m_moog_situation_id%2cu_resolution_symptom%2ccmdb_ci%2cbusiness_duration%2cuser_input%2chold_reason%2ccomments%2copened_at%2csla_due%2ccomments_and_work_notes%2cnumber%2capproval_history%2clocation%2cu_updated_by%2cu_vendor_list%2cwf_activity%2cu_opco%2csys_domain_path%2creopen_count%2csys_created_on%2cbusiness_service%2cu_alert_category%2cu_alert_subcategory%2cu_owner_group%2cu_mttrinhrs%2cdelivery_plan%2cu_linked_incident%2cu_amo%2cu_nms_name%2cu_probable_cause%2cu_service_component%2cupon_approval%2cexpected_start%2cresolved_at%2cpriority%2creassignment_count%2cu_stc_end_time%2cassignment_group%2ccalendar_duration%2ccorrelation_display%2cu_case_number%2cu_netcool_user%2cu_updated_by_customer%2cu_resolution_business_service%2cparent%2cclose_notes%2cdue_date%2cu_escalated%2ccause%2cu_vendor_ticket_reference%2cu_peering_exchange%2csys_class_name%2capproval%2cknowledge%2cu_sentinel_incident_id%2cu_ticket_type%2cparent_incident%2corder%2cu_agent_comments_added%2csys_created_by%2cu_please_provide_business_service_details&sysparm_offset=0, Status Code: BadRequest, Error message: {"error":{"message":"Pagination not supported","detail":"The requested query is too long to build the response pagination header URLs. Please do one of the following: shorten the sysparm_query, or query without pagination by setting the parameter 'sysparm_suppress_pagination_header' to true, or set 'sysparm_limit' with a value larger then 862605 to bypass the need for pagination."},"status":"failure"}

Answer 1

Hi Joshoua Simon The "pagination not supported" error usually happens when the request URL gets too long, often because too many fields are included in the sysparm_fields parameter. ServiceNow struggles to generate pagination headers when the URL exceeds a certain length.

Try adding this parameter to your request:

sysparm_suppress_pagination_header=true

In Azure Data Factory, you can set this either in the linked service or source dataset under Additional Parameters (depends on how you're configuring it). This tells ServiceNow not to include pagination headers in the response, which avoids the error altogether.

Also, even though you’re already using sysparm_limit=10, you might still hit issues if the number of fields is large. I’d recommend starting with a smaller set of fields (maybe 10–15), confirm the copy activity works, then expand from there in chunks if needed.

Lastly, if you're dynamically loading tables, you might want to look into the sys_dictionary table in ServiceNow. It gives you the schema info, which can help if you're trying to generate mappings or source definitions on the fly.

---

I hope this information helps. Please do let us know if you have any further queries.

Kindly consider upvoting the comment if the information provided is helpful. This can assist other community members in resolving similar issues.