The ServiceNow Snowflake integration enables organizations to export ServiceNow operational data into Snowflake's cloud data warehouse for advanced analytics, reporting, and business intelligence. This integration solves the challenge of accessing ServiceNow data at scale for cross-platform reporting, data science initiatives, and compliance reporting that requires historical data retention beyond ServiceNow's standard limits. IT operations teams, data engineers, and business analysts rely on this integration to create comprehensive dashboards combining ServiceNow metrics with other enterprise data sources. The integration primarily involves unidirectional data flow from ServiceNow to Snowflake, triggered by scheduled jobs or real-time webhooks depending on the data freshness requirements. The implementation leverages ServiceNow's Integration Hub ETL capabilities, REST Message records for API calls, and Snowflake's REST API endpoints for data ingestion, with configuration managed through the Integration Hub Designer and Connection & Credentials framework.
Prerequisites
- •ServiceNow Rome or later with Integration Hub Professional license
- •Snowflake Standard edition or higher with ACCOUNTADMIN role access
- •ServiceNow user with admin role and integration_admin_user role
- •Snowflake database and warehouse with appropriate compute credits allocated
- •Network connectivity between ServiceNow instance and Snowflake account (MID Server if behind firewall)
- •SSL/TLS certificates properly configured for HTTPS communication
- •Snowflake SQL API and Partner Connect features enabled in your account
Architecture Overview
The ServiceNow Snowflake integration utilizes ServiceNow's Integration Hub ETL capabilities combined with custom REST Message records to interact with Snowflake's SQL API and PUT/GET file transfer endpoints. Authentication is established using Snowflake key-pair authentication or OAuth 2.0, with credentials securely stored in ServiceNow's Connection & Credential Aliases under the Connections & Credentials module. Data flows unidirectionally from ServiceNow to Snowflake through scheduled Integration Hub flows that extract data via GlideRecord queries, transform it into JSON or CSV format, and load it into Snowflake tables using the SQL API or bulk loading mechanisms. A MID Server is required when ServiceNow is hosted on-premises or when network security policies restrict direct internet connectivity to Snowflake's cloud infrastructure. Rate limiting considerations include Snowflake's API quotas of 100 requests per minute per user and data transfer limits, while ServiceNow's Integration Hub has execution time limits of 10 minutes per flow step that may require chunking large datasets.
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Implementation Steps
Configure Snowflake database objects and authentication
Log into your Snowflake web interface as ACCOUNTADMIN and create a dedicated database and schema for ServiceNow data using CREATE DATABASE SERVICENOW_DATA and CREATE SCHEMA SERVICENOW_DATA.OPERATIONAL_DATA. Create a service user specifically for the integration with CREATE USER SERVICENOW_INTEGRATION_USER PASSWORD='strong_password' DEFAULT_ROLE='SERVICENOW_ROLE'. Generate RSA key pairs for authentication using OpenSSL or Snowflake's key generation utility, then assign the public key to the user with ALTER USER SERVICENOW_INTEGRATION_USER SET RSA_PUBLIC_KEY='your_public_key_here'. Create appropriate roles and grants to ensure the service user can INSERT, UPDATE, and CREATE TABLE in the designated schema but cannot access sensitive data in other databases.
Create Connection and Credential Aliases in ServiceNow
Navigate to Connections & Credentials > Connections in ServiceNow and create a new HTTP(s) connection named 'Snowflake Production Connection' with the connection URL set to your Snowflake account URL format https://your-account.snowflakecomputing.com. In the Connections & Credentials > Credentials section, create a new Basic Auth credential named 'Snowflake Service Account' storing the Snowflake username in the User name field and either the private key content or OAuth token in the Password field. Associate this credential with your connection alias and test the connection using the Test Connection button to verify network connectivity. Set the connection timeout to 30 seconds and enable Use MID Server if your instance requires it, selecting the appropriate MID Server from the dropdown.
Create REST Message for Snowflake SQL API
Navigate to System Web Services > Outbound > REST Message and create a new REST Message record named 'Snowflake SQL API' with the endpoint https://${account}.snowflakecomputing.com/api/v2/statements. Create an HTTP method named 'executeQuery' with HTTP method POST and add required headers: Content-Type: application/json, Authorization: Bearer ${token}, and X-Snowflake-Authorization-Token-Type: OAUTH. In the HTTP Request tab, configure the request body template to include SQL statement, warehouse, database, and schema parameters as JSON payload. Set up variable substitution for ${account} and ${token} using the Connection Alias created in the previous step, and configure authentication to use the stored credentials.
var request = new sn_ws.RESTMessageV2('Snowflake SQL API', 'executeQuery');
request.setStringParameterNoEscape('account', 'your-account-name');
request.setStringParameterNoEscape('token', 'your-oauth-token');
var requestBody = {
'statement': 'SELECT CURRENT_TIMESTAMP()',
'warehouse': 'SERVICENOW_WH',
'database': 'SERVICENOW_DATA',
'schema': 'OPERATIONAL_DATA',
'bindings': {}
};
request.setRequestBody(JSON.stringify(requestBody));
var response = request.execute();
gs.info('Snowflake API Response: ' + response.getBody());Design ETL Flow in Integration Hub
Open Integration Hub > Designer and create a new flow named 'ServiceNow to Snowflake Data Export' with a trigger set to Schedule with your desired frequency (daily, hourly, etc.). Add a Flow Designer step to query ServiceNow data using the Look Up Record action, configuring it to retrieve records from your target table (e.g., incident, change_request) with appropriate filters for incremental loading based on sys_updated_on timestamps. Add a For Each step to iterate through the returned records and transform each record into the JSON format expected by your Snowflake table schema. Include error handling using Try-Catch blocks and configure the flow to log successful and failed record counts to the Flow Execution Details for monitoring purposes.
// Flow Designer Script Step for data transformation
(function process(inputs, outputs) {
var records = inputs.source_records;
var transformedData = [];
records.forEach(function(record) {
var snowflakeRecord = {
sys_id: record.sys_id,
number: record.number,
state: record.state.toString(),
priority: record.priority.toString(),
created_on: record.sys_created_on,
updated_on: record.sys_updated_on
};
transformedData.push(snowflakeRecord);
});
outputs.transformed_records = transformedData;
})(inputs, outputs);Configure Snowflake table creation and data loading
In your Integration Hub flow, add a REST step that uses your Snowflake SQL API REST Message to create the target table if it doesn't exist, using CREATE TABLE IF NOT EXISTS syntax with appropriate column definitions matching your ServiceNow data structure. Add a second REST step to execute MERGE or INSERT statements for upserting the transformed data into Snowflake, using Snowflake's variant data type for JSON payloads or individual columns for structured data. Configure the REST steps to use the Connection Alias created earlier and include proper error handling to catch Snowflake SQL errors and connection timeouts. Set up the data loading step to process records in batches of 1000 to avoid hitting Integration Hub execution time limits and Snowflake's statement complexity limits.
// Integration Hub REST Step configuration
var sqlStatement = "MERGE INTO incident_data AS target USING (" +
"SELECT * FROM VALUES " +
inputs.records.map(function(r) {
return "('" + r.sys_id + "','" + r.number + "','" + r.state + "')";
}).join(',') +
") AS source(sys_id, number, state) ON target.sys_id = source.sys_id " +
"WHEN MATCHED THEN UPDATE SET number = source.number, state = source.state " +
"WHEN NOT MATCHED THEN INSERT (sys_id, number, state) VALUES (source.sys_id, source.number, source.state)";
var requestPayload = {
statement: sqlStatement,
warehouse: 'SERVICENOW_WH',
database: 'SERVICENOW_DATA',
schema: 'OPERATIONAL_DATA'
};
outputs.sql_payload = requestPayload;Implement incremental loading and state management
Create a custom table in ServiceNow (e.g., u_snowflake_sync_state) to track the last successful sync timestamp for each table being exported to Snowflake, including fields for table_name, last_sync_time, and record_count. Modify your Integration Hub flow to query this state table at the beginning of each run and use the last_sync_time as a filter in your ServiceNow data queries to only export records modified since the last successful sync. Add a flow step at the end of successful executions to update the sync state table with the current timestamp and record count processed. Include logic to handle initial full loads versus incremental loads, and implement a configurable lookback period (e.g., 5 minutes) to account for potential clock skew between ServiceNow and your processing schedule.
// Script to manage incremental sync state
var syncStateGR = new GlideRecord('u_snowflake_sync_state');
syncStateGR.addQuery('table_name', 'incident');
syncStateGR.query();
var lastSyncTime = new GlideDateTime();
if (syncStateGR.next()) {
lastSyncTime.setValue(syncStateGR.last_sync_time.toString());
} else {
// First run - go back 24 hours
lastSyncTime.addDaysUTC(-1);
}
// Query incidents modified since last sync
var incidentGR = new GlideRecord('incident');
incidentGR.addQuery('sys_updated_on', '>', lastSyncTime);
incidentGR.orderBy('sys_updated_on');
incidentGR.query();
var records = [];
while (incidentGR.next()) {
records.push({
sys_id: incidentGR.sys_id.toString(),
number: incidentGR.number.toString(),
state: incidentGR.state.toString()
});
}
return records;Set up monitoring and error handling
Configure Integration Hub flow error handling by adding Try-Catch blocks around each major step and creating custom error logging that writes to a ServiceNow table with details about failed syncs, including error messages, affected record counts, and retry attempts. Set up email notifications for flow failures using ServiceNow's Event Management, creating events that trigger when Snowflake API calls return error status codes or when record counts fall outside expected ranges. Create a ServiceNow dashboard or Performance Analytics widget to monitor sync job success rates, data volume trends, and latency metrics by querying the sync state table and Integration Hub execution logs. Implement retry logic with exponential backoff for transient failures, and configure the flow to skip problematic records while logging them for manual review rather than failing the entire batch.
// Error handling and monitoring script
try {
var response = snowflakeAPI.execute();
var responseBody = JSON.parse(response.getBody());
if (response.getStatusCode() != 200) {
throw new Error('Snowflake API error: ' + responseBody.message);
}
// Update success metrics
var metricsGR = new GlideRecord('u_integration_metrics');
metricsGR.initialize();
metricsGR.integration_name = 'Snowflake Sync';
metricsGR.records_processed = recordCount;
metricsGR.execution_time = executionTime;
metricsGR.status = 'success';
metricsGR.insert();
} catch (error) {
gs.error('Snowflake integration error: ' + error.message);
// Log error for monitoring
gs.eventQueue('snowflake.sync.error', null, error.message, gs.getUserID());
// Update error metrics
var errorGR = new GlideRecord('u_integration_errors');
errorGR.initialize();
errorGR.error_message = error.message;
errorGR.integration_name = 'Snowflake Sync';
errorGR.insert();
}Test end-to-end integration and validate data
Execute your Integration Hub flow manually from the Flow Designer test interface and monitor the execution details for any errors or warnings during the data extraction, transformation, and loading phases. Verify in Snowflake that tables are created with the correct schema and that sample records match the expected format by running SELECT queries with COUNT and sample data validation. Set up data quality checks by comparing record counts between ServiceNow and Snowflake for the same time periods, and validate that key fields like sys_id, timestamps, and choice field values are correctly transformed and stored. Create a validation script that runs after each sync to check for data consistency, missing records, and duplicate entries, logging any discrepancies to a monitoring table for investigation and resolution.
// Data validation script for Snowflake sync
var validationResults = {
servicenow_count: 0,
snowflake_count: 0,
discrepancies: []
};
// Count records in ServiceNow
var snGR = new GlideRecord('incident');
snGR.addQuery('sys_created_on', '>=', yesterday);
snGR.query();
validationResults.servicenow_count = snGR.getRowCount();
// Query Snowflake for count (pseudo-code for REST call)
var countQuery = "SELECT COUNT(*) FROM incident_data WHERE created_on >= '" + yesterday + "'";
var snowflakeCount = executeSnowflakeQuery(countQuery);
validationResults.snowflake_count = snowflakeCount;
// Log discrepancies
if (validationResults.servicenow_count != validationResults.snowflake_count) {
gs.warn('Data count mismatch: SN=' + validationResults.servicenow_count + ', SF=' + validationResults.snowflake_count);
var discrepancyGR = new GlideRecord('u_data_validation_log');
discrepancyGR.initialize();
discrepancyGR.validation_date = new GlideDateTime();
discrepancyGR.servicenow_count = validationResults.servicenow_count;
discrepancyGR.snowflake_count = validationResults.snowflake_count;
discrepancyGR.insert();
}Common Use Cases
Incident Management Historical Analytics
Export incident records from ServiceNow to Snowflake for multi-year trend analysis and advanced reporting that exceeds ServiceNow's standard reporting capabilities. The integration captures incident lifecycle data, resolution times, assignment group performance, and customer satisfaction scores to enable predictive analytics and capacity planning. Business stakeholders use this data warehouse to create executive dashboards showing MTTR trends, recurring problem patterns, and service improvement opportunities across different business units and time periods.
Change Management Risk Analysis
Synchronize change request data with associated configuration item relationships to Snowflake for comprehensive change advisory board reporting and risk correlation analysis. The integration exports change records with their approval workflows, implementation results, and any related incident data to enable analysis of change success rates by type, timing, and affected services. Risk management teams leverage this consolidated dataset to identify high-risk change patterns and optimize change approval processes based on historical success rates.
Asset and CMDB Data Warehousing
Replicate Configuration Management Database (CMDB) data including hardware assets, software licenses, and dependency relationships to Snowflake for enterprise asset optimization and compliance reporting. The integration maintains historical snapshots of asset configurations, location changes, and lifecycle states to support financial planning and audit requirements. IT asset managers use this data warehouse to track total cost of ownership, identify underutilized resources, and ensure software license compliance across the organization.
Service Catalog Performance Metrics
Export Service Catalog request data including requested items, approval chains, fulfillment times, and user satisfaction ratings to Snowflake for comprehensive service delivery analytics. The integration captures the complete request lifecycle from submission through fulfillment, including SLA performance and bottleneck identification across different catalog categories. Service owners analyze this data to optimize catalog offerings, improve fulfillment automation, and demonstrate business value of IT services to stakeholders.
Cross-Platform Operational Intelligence
Combine ServiceNow operational data with monitoring tools, financial systems, and business applications in Snowflake to create unified operational intelligence dashboards that correlate IT performance with business outcomes. The integration exports key operational metrics, service availability data, and cost allocation information that gets joined with revenue data, customer metrics, and other business KPIs. Executive teams use these integrated datasets to understand the direct impact of IT service quality on business performance and make data-driven investment decisions.
Troubleshooting
Integration Hub flow fails with 'Connection timeout' error when calling Snowflake API
First check the System Logs > Outbound HTTP Requests to verify the actual HTTP status code and response details from Snowflake. If you see 504 Gateway Timeout errors, increase the REST Message timeout setting to 60 seconds and verify your Snowflake warehouse is appropriately sized and not suspended due to inactivity. For persistent timeout issues, check if your MID Server (if used) has sufficient memory and CPU resources, and consider implementing retry logic with exponential backoff in your flow design to handle transient network issues.
Data appears in Snowflake but with incorrect timestamps or missing choice field labels
This typically occurs due to timezone conversion issues and choice field value transformation problems during the ETL process. Check your Integration Hub flow's data transformation step to ensure GlideDateTime objects are converted to ISO format strings using getDisplayValue() instead of toString(), and verify that choice fields are extracting display values rather than internal database values. Review the Snowflake table schema to ensure timestamp columns are defined with appropriate timezone handling (TIMESTAMP_TZ vs TIMESTAMP_NTZ) and that VARCHAR columns for choice fields have sufficient length to store display values.
Snowflake SQL API returns '401 Unauthorized' despite valid credentials
Navigate to Connections & Credentials > Connections and test your Snowflake connection alias to verify basic connectivity, then check that your OAuth token hasn't expired if using OAuth authentication. For key-pair authentication, verify that the private key format is correct (PKCS#8 format) and that the public key was properly assigned to the Snowflake user account. Check the Integration Hub flow execution details for the exact error message, and ensure your Snowflake user has the necessary role assignments and grants on the target database and schema objects.
Records are duplicating in Snowflake despite MERGE statement usage
Examine your MERGE statement logic in the Integration Hub flow to ensure the ON condition uses a truly unique identifier like sys_id rather than potentially duplicated fields like number or name. Check the Snowflake query history to verify that your MERGE statements are executing as expected and not being converted to separate INSERT statements due to syntax errors. Review your incremental loading logic to confirm that the same records aren't being processed multiple times due to overlapping time windows in your last_sync_time filtering, and consider adding a DISTINCT clause to your source data selection if upstream ServiceNow queries might return duplicates.
Integration Hub flow execution time exceeds the 10-minute limit and terminates
Implement batch processing in your flow by modifying the data extraction step to process records in smaller chunks (1000-5000 records) rather than attempting to process entire tables at once. Add pagination logic using GlideRecord setLimit() and query() methods with offset handling, and consider splitting large tables into multiple parallel flows that process different data ranges. Monitor your Snowflake warehouse size and query performance, as slow INSERT/MERGE operations can contribute to timeout issues, and optimize your SQL statements by adding appropriate indexes and using Snowflake's COPY command for bulk loading when dealing with large datasets.
Snowflake tables show gaps in data for certain time periods despite successful flow executions
Check your incremental loading state management to ensure that failed executions don't advance the last_sync_time timestamp, leaving gaps in subsequent runs that skip over the failed time period. Review the Integration Hub execution history to identify any partially successful runs where some records processed but others failed, and implement transaction-like behavior where the sync state is only updated after complete success. Examine your ServiceNow source queries for potential issues with sys_updated_on filtering, especially around daylight saving time transitions or timezone changes, and consider adding overlap periods in your incremental queries to ensure no records are missed during edge cases.
Pro Tips
- →Implement a 'full refresh' capability alongside your incremental sync by creating a separate Integration Hub flow that can rebuild specific tables from scratch when data integrity issues are detected. This flow should truncate Snowflake tables and reload all historical data with proper error handling and progress tracking, serving as a recovery mechanism for data corruption or schema changes.
- →Use Snowflake's VARIANT data type to store complete ServiceNow record JSON alongside normalized columns, enabling future schema evolution without breaking existing reports while maintaining access to all original ServiceNow data fields. This hybrid approach allows immediate access to commonly used fields through SQL columns while preserving flexibility for ad-hoc analysis of any ServiceNow field.
- →Configure Snowflake's Time Travel feature with appropriate retention periods (7-90 days) to enable point-in-time recovery of your ServiceNow data warehouse, and implement automated daily snapshots using Snowflake's cloning capabilities to create cost-effective backup copies for testing and development environments without impacting production data pipeline performance.
- →Leverage Snowflake's stream objects to capture changes in your ServiceNow tables for real-time downstream processing, enabling event-driven analytics and alerts based on ServiceNow data changes. Set up streams on key tables like incidents and changes to trigger notifications or automated responses when critical records are created or modified, extending ServiceNow's workflow capabilities with cloud-scale data processing.
- →Optimize Snowflake warehouse auto-suspend and auto-resume settings based on your ServiceNow sync schedule patterns, using smaller warehouses (X-Small or Small) for regular incremental loads and automatically scaling to larger warehouses for full refresh operations. Monitor warehouse credit consumption and query performance to right-size your compute resources and minimize costs while maintaining acceptable data pipeline SLAs.
- →Implement data lineage tracking by adding metadata columns to your Snowflake tables that capture the Integration Hub execution ID, source ServiceNow instance, and processing timestamp for each record. This enables debugging of data quality issues, audit trail compliance, and impact analysis when ServiceNow schema changes affect downstream reporting and analytics applications built on the Snowflake data warehouse.
Known Limitations
- —Snowflake's SQL API enforces rate limits of 100 requests per minute per user account, which can constrain high-frequency sync operations or parallel processing of multiple ServiceNow tables. Large enterprises may need to implement request queuing or use multiple Snowflake service accounts to distribute API calls and avoid throttling during peak data loading periods.
- —Integration Hub flows have a maximum execution time of 10 minutes per step, requiring careful batch size tuning and pagination logic for large ServiceNow tables containing millions of records. Complex data transformations or slow network connectivity to Snowflake can further reduce the effective batch sizes, potentially requiring overnight processing windows for complete data synchronization.
- —ServiceNow's Integration Hub Professional license limits the number of concurrent flow executions and total monthly executions, which may restrict real-time data synchronization capabilities for organizations with high data volume requirements. The licensing model also limits advanced ETL features and may require custom scripting for complex data transformations that exceed built-in Integration Hub actions.
- —Snowflake storage and compute costs can escalate quickly with frequent data loads and retention of historical snapshots, especially when dealing with attachment data or long text fields from ServiceNow records. Organizations must carefully balance data freshness requirements against warehouse costs, potentially implementing data archiving strategies or selective field synchronization to optimize total cost of ownership.
- —Network latency and connectivity issues between ServiceNow instances and Snowflake cloud regions can impact data pipeline reliability and performance, particularly for organizations with strict network security requirements that mandate MID Server usage or VPN connections. Cross-region data transfer may introduce additional latency and costs that affect real-time analytics capabilities.
Frequently Asked Questions
Should I use Integration Hub ETL actions or custom REST Messages for Snowflake data loading?
Integration Hub ETL provides a more maintainable and user-friendly approach for standard data synchronization scenarios, offering built-in error handling, retry logic, and visual flow design that non-developers can understand and modify. However, custom REST Messages offer more flexibility for complex data transformations, bulk loading operations, and advanced Snowflake features like COPY commands or multi-statement transactions. For most organizations, start with Integration Hub ETL and supplement with custom REST Messages only when specific requirements exceed the built-in capabilities or when performance optimization requires direct API control.
How can I handle ServiceNow attachment and journal field data in Snowflake?
Attachment data should typically be stored as metadata in Snowflake (file name, size, content type, sys_id) with the actual file content remaining in ServiceNow or moved to cloud storage like AWS S3 or Azure Blob Storage for cost optimization. Journal fields and work notes can be exported as JSON arrays or separate related tables in Snowflake, maintaining the chronological order and user attribution. Consider implementing a separate ETL process for attachment content if full-text search capabilities are required, using Snowflake's semi-structured data support to index and query attachment metadata while keeping binary content in appropriate storage tiers.
What's the recommended approach for handling ServiceNow schema changes in Snowflake?
Implement a schema evolution strategy using Snowflake's ALTER TABLE capabilities combined with Integration Hub flow versioning to handle new fields, changed data types, or removed columns from ServiceNow. Create a schema monitoring process that detects ServiceNow table changes through the sys_dictionary table and automatically generates ALTER TABLE statements for Snowflake. Use Snowflake's VARIANT columns as a fallback to store complete ServiceNow record JSON when schema changes break existing column mappings, ensuring data continuity while you update ETL processes. Maintain separate development and staging Snowflake environments to test schema changes before applying them to production data pipelines.
How should I structure Snowflake databases and schemas for multiple ServiceNow instances?
Create separate Snowflake databases for each ServiceNow instance (DEV, TEST, PROD) to maintain data isolation and enable environment-specific access controls and retention policies. Within each database, organize schemas by ServiceNow application or functional area (ITSM, ITOM, HR, etc.) rather than by table type to align with business domain boundaries and simplify cross-functional reporting. Use consistent naming conventions across environments and implement role-based access control (RBAC) that mirrors your ServiceNow user access patterns. Consider creating a shared COMMON schema for reference data and lookup tables that apply across multiple ServiceNow applications, reducing data duplication and maintenance overhead.
Can I implement real-time streaming from ServiceNow to Snowflake instead of batch processing?
While Snowflake supports streaming ingestion through Kafka connectors and streaming APIs, ServiceNow doesn't natively provide change data capture (CDC) capabilities that would enable true real-time streaming. You can approximate real-time processing by implementing Business Rules or Flow Designer flows that trigger REST API calls to Snowflake immediately upon record changes, but this approach may impact ServiceNow performance and hit API rate limits. A more scalable solution involves using ServiceNow's Event Management to queue changes and process them in micro-batches every few minutes, balancing data freshness with system performance and providing better error handling than individual real-time calls.
What security considerations should I address when integrating ServiceNow with Snowflake?
Implement network security using Snowflake's Network Policies to restrict access to your known ServiceNow IP addresses or MID Server locations, and enable Multi-Factor Authentication (MFA) for all Snowflake service accounts used in the integration. Use Snowflake's Object-Level Access Control to ensure ServiceNow integration users can only access the specific databases and schemas required for data loading, following the principle of least privilege. Configure data encryption in transit using TLS 1.2+ and leverage Snowflake's automatic encryption at rest for stored data, while implementing data masking or tokenization for sensitive fields like SSN or credit card numbers during the ETL process. Regularly rotate authentication credentials and monitor access logs in both ServiceNow and Snowflake to detect unauthorized access attempts or unusual data access patterns.
How do I optimize Snowflake warehouse costs for ServiceNow data pipelines?
Configure aggressive auto-suspend settings (1-2 minutes) for warehouses dedicated to ServiceNow ETL operations since these workloads typically have predictable batch processing patterns with clear start and stop times. Use X-Small or Small warehouses for regular incremental loads and implement dynamic scaling logic that automatically provisions larger warehouses only for full refresh operations or end-of-month reporting periods. Leverage Snowflake's result caching and clustering keys on frequently queried columns like sys_created_on and assignment_group to improve query performance without requiring larger warehouses. Monitor warehouse utilization through Snowflake's Account Usage views and consider using Snowflake's Resource Monitors to set spending limits and automatic suspension thresholds that prevent runaway costs from poorly optimized queries or unexpected data volume spikes.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue