• Script include — The ServiceNow script include configures the main integration logic and API wrapper. It defines the frequency of synchronization, authenticates the API, and maps Arctic Wolf priority values to ServiceNow.
• Scheduled job — The ServiceNow job runs every five minutes and includes tasks such as running the sync ticket action, logging results, and notifying the integration administrator.
• Business rules — After any ticket is updated, the integration runs two business rules, one for closing cases and one for posting comments. For a rule to apply to a case, the case status must be closed and the contact must be Arctic Wolf.
• Dictionary entry — The custom dictionary entry stores mappings between organization IDs and their applicable PODs.

Inbound data sync

1. Every five minutes, the system runs the scheduled job.
2. The automation gets the previous sync results from the system property.
3. The automation retries all previous failures and then attempts to sync again.
4. The automation queries all accounts with an Arctic Wolf ID, and then parses the organization ID and POD.
5. For each organization, the automation calls the Ticket API, fetches tickets updated in the last five minutes, and then filters the results by status and priority.
6. For each update, the automation checks to see if a ServiceNow case exists. If the case:
   • Exists — The automation updates the title, description, priority, status, hold reason, assignees, and comments as needed.
   • Does not exist — The automation creates a case and then maps the ticket fields to case fields, sets an assignment group, finds contracts and entitlements, maps an assignee, converts Markdown comments to HTML work notes, and escalates as needed.
7. The automation records all results in the system property, identifying which updates were successful and which failed.

Outbound data sync

1. The system runs the two ServiceNow business rules to close cases and post comments.
2. The business rules extract details such as close notes and comments.
3. The business rules parse the organization ID, POD, and ticket ID.
4. The business rules call the Ticket API to close the ticket or post the comments as needed.

Failure retry mechanism

1. The system reads the latest sync results and extracts previous failures.
2. The system attempts to re-sync failed tickets before processing new updates.
   • If the retry succeeds, the item is moved to a successes array.
   • If the retry fails again, the item remains in the failures array.
3. The mechanism saves the results back to the system property for the next run.

Fields for case creation

This customer also had customizations configured for ServiceNow-specific fields such as assignment_group, contract, entitlement, and case categories and types.

Ticket priority

Statuses

Sync results object

{
"sync_time": "2024-01-01T12:00:00Z", // Current sync timestamp
"updated_after": "2024-01-01T11:55:00Z", // Looked for tickets updated after this time
"total_ticket_count": 15, // Total tickets processed
"successes": [
{
"pod": "<pod>",
"ticketId": "<ticket_id>",
"organizationId": "<org_id>",
"sync_action": "create", // or "update"
"success": true,
"case_sys_id": "<case_id>"
}
],
"failures": [
{
"pod": "<pod>",
"ticketId": "<ticket_id>",
"organizationId": "<org_id>",
"sync_action": "update",
"success": false,
"case_sys_id": null // or existing case ID
}
]
}

Polling logic

// Get tickets updated in last 5 minutes
pollingIntervalMinutes = 5
currentTime = now()
updatedAfter = currentTime - pollingIntervalMinutes
// For updates: Only add comments newer than last poll
if (isUpdate) {
// Filter comments by createdAt > (lastSyncTime OR currentTime - 5 minutes)
}

Error handling

try {
var response = r.execute();
var httpStatus = response.getStatusCode();
return JSON.parse(responseBody);
} catch(ex) {
gs.info("ArcticWolf - {method} - Error: " + ex.message);
return null;
}

Sync errors follow this resolution process:

• Each ticket sync is wrapped in an individual try-catch block.
• Failures are recorded in the results object.
• The sync continues even if individual tickets fail.
• Failed tickets are retried on the next run.

All significant operations are tracked in system logs, including API HTTP status codes, pagination progress, error messages, and the sync results summary.