Introduction
The ONEiO ServiceNow Update Set provides a quick and convenient way to enable direct integration from ServiceNow to ONEiO. It includes pre-built scripts and Business Rules that simplify message exchange, making it easier and faster to set up integrations.
The Update Set is optional, but highly recommended for ServiceNow customers who want to streamline their integration setup with ONEiO.
If you need assistance configuring the Update Set, please contact support@oneio.cloud.
Overview
- What is the ONEiO ServiceNow Update Set?
- Architecture and Flow
- Deployment
- Features
- Optional Script Configurations
-
Troubleshooting
What is the ONEiO ServiceNow Update Set?
The Update Set is a ServiceNow package containing Script Includes and Business Rules that automate communication from ServiceNow to ONEiO. It enables the transfer of record data and attachments to ONEiO whenever they are created or updated, requiring only minimal configuration.
Availability
- Publicly available on the ServiceNow Developer Site (version 1.2).
- Delivered as a ServiceNow Update Set (newer versions backward-compatible).
- Works with all ServiceNow Rhino versions (ECMAScript 5+).
Contents
- Script Include: ONEiO Library
-
Business Rules:
- ONEiO REST Post Payload
- ONEiO Send Attachment after Correlation ID
- ONEiO Send Attachment
Architecture and Flow
The Update Set follows a clear flow inside ServiceNow:
- REST payloads are sent according to Business Rule conditions defined in ServiceNow, covering both records and attachments.
- Attachments get be retrieved from ONEiO based on the correlation information received.
- Record data and attachments flow from ServiceNow to ONEiO, where they can be seamlessly forwarded to other ITSM systems.
Deployment
- Import and Commit the Update Set in ServiceNow.
-
Configure the REST Message in ServiceNow:
- Credentials for target system (ONEiO)
- Target system URL (QA / Production)
- ServiceNow table(s) that trigger communication
- (Optional) Add extra conditions or configure Business Rules to adjust payload behavior. See the section below for more details.
Permissions Required
For the ONEiO Update Set to work correctly, the following accounts must have sufficient permissions:
- ServiceNow Data Access a Runtime: The Business Rules that build the payload run in the context of the user who triggers the record change (e.g., a service agent). The data included in the payload reflects that user's access. If your instance enforces ACLs for server-side scripts, ensure these users can read the referenced fields and tables. This typically works by default and doesn't require extra configuration.
- Outbound Authentication (ServiceNow → ONEiO): Configure the authentication used by ServiceNow to prove its identity to ONEiO. Options include Basic Auth or OAuth. You can do this under System Web Services → Outbound → REST Message → ONEiO.
- Inbound Authentication (ONEiO → ServiceNow): Provide ONEiO with a dedicated ServiceNow integration user account that has read access to sys_attachment and the parent records to fetch attachments. If ONEiO needs to create attachments or records, which is a common requirement, grant this account write access to sys_attachment and the target tables (e.g., incident).
- Admin (setup only): An admin is required to import the Update Set and configure the integration settings. These are setup-only tasks that require elevated permissions.
For additional guidance on integration tasks, refer to: "How to configure ServiceNow for integration with ONEiO".
Features
Public version 1.5:
- Sends payload with:
- Record fields
- Related field labels and emails
- Last journal entry of comments and work notes
- Previous record's field values and changed field values
- Sends attachment information on insert (after reception of correlation ID) and subsequent updates
- Payload fields sorted alphabetically
- Previous field values and changed field values, with possibility of dot walking
- Configurable lookup of related fields
- Configurable resolving values
Example Resulting Payload
{
"ServiceNow-table": "incident",
"account": "227cdfb03710200044e0bfc8bcbe5d6b",
"account_name": "ACME South America",
"active": "1",
"active_name": "true",
"activity_due_name": "UNKNOWN",
"approval": "not requested",
"approval_name": "Not Yet Requested",
"caller_id": "62826bf03710200044e0bfc8bcbe5df1",
"caller_id_email": "abel.tuter@example.com",
"caller_id_name": "Abel Tuter",
"category": "inquiry",
"category_name": "Inquiry / Help",
"child_incidents": "0",
…
"urgency": "3",
"urgency_name": "3 - Low",
"previous_record": {
"active": "1",
"active_name": "true",
…
"short_description": "t5.20",
"sla_due_name": "UNKNOWN",
"state": "1",
"state_name": "New",
…
"urgency": "3",
"urgency_name": "3 - Low"
…
}
"changed_fields": {
"short_description": "t5.21",
"sys_mod_count": "21",
"sys_updated_on": "2025-09-04 17:20:51",
"sys_updated_on_name": "2025-09-04 10:20:51"
},
"changed_field_list": "*short_description*sys_mod_count*sys_updated_on*sys_updated_on_name*"
}
Optional Script Configurations
Excluding Previous Record and Changes
The standard ONEiO REST Post Payload script's call to the ONEiOLibrary is:
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', [], {}, {});
Set grPrevious to null to exclude previous_record, changed_fields, and changed_field_list from the payload:
new ONEiOLibrary().post(grCurrent, null, 'ONEiO', 'post', [], {}, {});
Excluding Fields from Payload
In the ONEiO REST Post Payload script's call, define an excludedFields array in the script parameter, e.g.:
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', ['assignment_group', 'assigned_to'], {}, {});
Lookup of Reference Fields
Whilst ONEiO can handle reference lookups, performing them inside ServiceNow is also possible.
Use the 'relatedFieldsConfig' parameter in the ONEiO REST Post Payload scrip to include details from reference fields (like user email or department, e.g.:
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', [],
{
sourceFieldConfigs: [
{
sourceField: 'assigned_to',
relatedFields: ['email']
}
]
}, {});
In this example the trigger event is set to default inside the field’s lookup configuration. Valid options for the events are: 'insert' | 'update' | ‘delete’ | 'always'.
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', [],
{
sourceFieldConfigs: [
{
sourceField: 'caller_id',
relatedFields: ['email','phone','department'],
onEvent: 'always' //overrides event default
},{
sourceField: 'assigned_to',
relatedFields: ['email'] // inherits default 'update'
}
],
onEventDefault: 'update’ // setting trigger event default
}, {});
The payload will look like this:
{
caller_id: "sys_id_123",
caller_id_details: {
email: "caller@test.com",
phone: "+123456789",
department: "xyz"
},
assigned_to: "sys_id_456",
assigned_to_details: {
email: "assignee@test.com"
}
}
Resolving Values
A resolving value in ONEiO is referring to the attribute in the payload, which is evaluated to pick the correct tenant on a multi-tenant vendor endpoint.
Set the 'resolvingConfig' parameter to determine tenant or routing values.
- Options include static values or lookup from reference tables.
- Works accross Business Rules “ONEiO REST Post Payload”, “ONEiO Send Attachment after Correlation ID” and “ONEiO Send Attachment”.
Example for assigning a static value below. Here, the targetField and tablesOnly configuration are omitted → defaults apply:
- Field to hold resolving value: resolving_value
- Scope: all ServiceNow tables configured for the Business Rule
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', [], {}, {
valueDefinition: { staticValue: 'some value' }
});
Example for resolving via Reference Table:
- Resolving field: account
- Value looked up from a reference table field
- Scope: trigger only when record is in sc_task table
new ONEiOLibrary().post(grCurrent, grPrevious, 'ONEiO', 'post', [], {}, {
valueDefinition: {
sourceField: 'company',
referenceTable: 'core_company'
},
targetField: 'account',
tablesOnly: ['sc_task']
});
Troubleshooting
If a field is not included in the payload, check:
- The field is not mentioned in the list of fields to exclude?
- Was the currently active business rule edited?
- assignment_group exists on the specific ServiceNow table the Business Rule triggers on (some custom tables may not include it)?
- Does the integration user have read access to assignment_group?
- The Business Rule edited is triggered on the correct table(s)?
- Are there extra conditions in the Business Rule that prevent the field from being included?
- Is a custom label or alias used (verify the payload uses the actual field name assignment_group)?
- Was an assignment group set in the ticket?
Comments
Please sign in to leave a comment.