ITSM Integration
Authentication Type
Determines the authentication method for API communication. Supported options are:
- No Auth: No credentials are required; no headers are sent.
- Basic Auth: Requires a username and password to authenticate API requests
- Username: The account username used to authenticate the request.
- Password: Password for basic authentication.
- Token: An API token is used instead of a username/password.
- Cookie: Uses a session cookie after logging in.
- Oauth2 – A more secure authentication method that grants access. The following details are required:
- Client ID: A unique identifier assigned to the client application by the OAuth2 provider, used to request authorization.
- Client Secret: Enter the client secret provided by your OAuth2 provider. This is essential to authenticate API requests securely and must be kept confidential.
- Token URL: This is the endpoint provided by the OAuth2 provider where the client application sends authentication requests to obtain an access token. It plays a crucial role in the OAuth2 authentication flow, enabling the exchange of client credentials for a token.
- Example:
https://dev12345.service-now.com/oauth_token.do
- Example:
- Grant Type: Specifies how the application obtains access tokens.
- Scope: The scope defines the level of access granted to the client application. It specifies the resources or permissions the application can access after authentication. The scope must align with the required permissions of the ITSM system.
- Example:
Useraccount
incident.write
(Allows creating and updating incidents)Incident.read
(Allows fetching incident details)
- Example:
Fields are dynamically populated based on the selected authentication type.
Advanced Configuration
This section allows users to customize ITSM settings using YAML, including payload transformations, field mappings, severity conversions, and additional attributes. It provides step-by-step instructions for defining static fields, dynamic mappings, and severity conversions for seamless integration with ITSM systems like Jira, ServiceNow, and BMC Remedy. For details, please refer to the Advanced Configuration (YAML-based) Section.
Default Payload Configuration
This section provides the default payloads for Jira and ServiceNow, which serve as the base structure for creating tickets. Users can modify, extend, or override these defaults using YAML-based configurations to adjust field mappings, transformations, and additional attributes as needed. For more details on creating the payload configuration script, refer to Creating Payload Configuration Script) Section.
Jira Default Payload Configuration
{
"fields": {
"project": {
"id": 1001
},
"issuetype": {
"id": 3
},
"summary": "Default Issue Summary",
"priority": {
"name": "Low"
},
"description": {
"version": 1,
"type": "doc",
"content": [
{
"type": "paragraph",
"content": [
{
"type": "text",
"text": "Default issue description. Modify this with actual details."
}
]
}
]
}
}
}
ServiceNow Default Payload Configuration
{
"severity": 2,
"urgency": 2,
"impact": 2,
"priority": 3,
"description": "Testing Memory usage",
"active": True,
"node": "server-2",
"short_description": "test purposes for host:server-2",
"opened_at": "2025-03-05 17:44:01",
"sys_created_on": "2025-03-05 17:44:01",
"correlation_id": "2025Mar03-46e6ff",
"source": "VuNet Systems",
"company": "VuNet Systems",
"type": "test purposes",
"cmdb_id": "",
"incident_state": "1",
"state": "1",
"metric_name": "300"
}