ServiceNow Integration

ServiceNow can be added as an integrated tool and used as part of your Cloud Governance through CoreStack. ServiceNow ITSM process flow can be enforced while using CoreStack Self Service module for cloud resource provisioning / modification / decommissioning. This provides seamless experience for your end-users who can continue to use ServiceNow or CoreStack UI for their self-service needs and the ITSM process adherence is built-in. The two different scenarios are explained below.

Scenario 1 (CoreStack as the Self Service Portal):

SSR(Self Service Request) Creation: All end-users will be logging into CoreStack and use the Self service module to raise a self service request. All requests will be automatically be synced with ServiceNow.

Approval: Approval can be through CoreStack portal or the approval can be triggered through ServiceNow.

Catalogs: In this case user will create a SSR(Self Service Request) in CoreStack, each catalog from CoreStack can be mapped to a single catalog in ServiceNow, as ServiceNow will be a placeholder (source of truth) to keep the catalog records for further reference.


Scenario 2(ServiceNow as the Self Service Portal):

SSR(Self Service Request) Creation: All users will be logging into the ServiceNow portal and raise a self service requests. All requests will be automatically be synced with CoreStack.

Approval: Approval workflow will be through ServiceNow portal. If required, the workflow can be configured to initiate provisioning without approval.

Catalogs: As the user will create a request in ServiceNow and the corresponding SSR to be created in CoreStack, each request item in ServiceNow to be mapped to individual items of CoreStack to initiate provisioning. Catalog admin should maintain the sync between ServiceNow and CoreStack catalog for any new addition or any changes to the existing catalog.


Pre-Requisites in ServiceNow

CoreStack supports the following 2 types of integration with ServiceNow Request module. The configuration requirement while adding a ServiceNow account may vary based on the integration type.

  • Request Catalog Availability for Resource Provisioning, Decommissioning and Modification
  • ServiceNow Workflow scripts to be configured for connectivity to CoreStack webhook after request catalog approval stage
  • Create user in ServiceNow for CoreStack App with admin privileges and meeting below requirements:
    • The given credentials should be for a local account even if SSO/LDAP is configured for the ServiceNow instance
    • The given user should have access to REST API specifically to the Table API (Request, Incident and CMDB)
    • The given user should also have access to the list catalog API
  • Have the Authentication URL and access credentials for CoreStack App ready

Onboarding ServiceNow in CoreStack

Steps to add:

Go to Settings (ICON) – Select Integrated Tools – Select ServiceNow and ‘Add Account’.

You will see 4 tabs > Authentication, Activation, Tools Configuration and Authorisation. Each of these tabs are explained below.

1. Authentication Tab

This tab captures some basic metadata about the ServiceNow account such as Name, Description, Environment, Scope and the access credentials. The fields are very similar to that you see in Cloud Accounts onboarding.

Environment: Please select the appropriate environment type for the ServiceNow account, this would help in identifying the Dev and Production ServiceNow accounts and can be referred for future reporting.

Scope: Please select the scope for this account to be added. You can select from the following options:

  1. Private: If the account to be used only by the logged in user and not to be shared with any other user
  2. Tenant: If the account to be shared with other users in the same tenant
  3. Account: If the account to be used by different tenants in the same CoreStack account (organisation)

Enter all required inputs and click on NEXT.

2. Activation Tab

In the Activation section select the Request Management, Configuration Management, Change Management and Incident Management types to be managed by CoreStack. You can choose to ignore some of these modules as per your requirement.

Triggers & Actions:

Under Triggers & Actions, we can provide the requisite settings to manage Request Management , Change Management and Incident Management Sections.

Request Configuration:

There is a need to map a relevant Self Service Request from ServiceNow so that CoreStack can understand the list of attributes expected from the integrated requests. Hence you need to provide a sample request.

You will see the list of last 5 requests created in the system, you can either select one of them or enter the request id which is more relevant for the mapping. Request attribute should be mapped with Set Default Options after Request id population.

Request Attribute Mapping:
ServiceNow CoreStack
Requested For Created By
U Third Party Referenceid Id
Due Date Activation Time
Approval Status
Sys Id Third Party Id
Short Description Name
Work Notes Resources
Action Mapping:

In this section, you would be mapping the actions between CoreStack and ServiceNow.

Scenario 1:

Source: CoreStack

Target: ServiceNow
CoreStack Action ServiceNow Action ServiceNow Action Attribute
create_request create_request Short Description, Approval, U Third Party Referenceid
modify_request modify_request U Third Party Referenceid, Approval
approve_request modify_request U Third Party Referenceid, Approval, Work Notes
reject_request modify_request U Third Party Referenceid, Approval

Note: Above mentioned ServiceNow Action Attributes are mandatory for the respective actions. Any other attributes can also be provided for each action but that should have mapping with CoreStack Attribute in Attribute Mapping section.

  • Action Mapping is done with Set Default Options after Request id is populated
  • User can also click Add New to add Service now CoreStack actions mappings as per user preference
Status Mapping:

In this section, you would be mapping the status values between CoreStack and ServiceNow.

ServiceNow (Approval Status) CoreStack (Order Status)
Requested Pending
Approved Approved
Rejected Rejected
  • Status Mapping is done with Set Default Options after Request id is populated
  • User can also click Add New to add Service now CoreStack Status mappings as per user preference

Catalog Mapping:

As specified above, there can be 2 different scenarios for integration based on which portal is used by end users to create self service requests. The catalog mapping and sync will differ based on the scenario.

Scenario 1:
ServiceNow CoreStack
Service Catalog – > CoreStack Services -> Public Cloud Automation Compute – > Virtual Machine -> Ubuntu Catalog, Cent OS Catalog..etc
Scenario 2:
ServiceNow CoreStack
Service Catalog ->Network & Infrastructure -> Virtual Machine – > Ubuntu Catalog Compute – > Virtual Machine -> Ubuntu Catalog
Service Catalog ->Network & Infrastructure -> Virtual Machine – > CentOS Catalog Compute – > Virtual Machine -> Ubuntu Catalog
Service Catalog ->Network & Infrastructure -> Virtual Machine Scale Set- > Ubuntu Catalog Compute – > Virtual Machine Scale Set -> Ubuntu Catalog
  • Click Add New to add Service now & CoreStack Catalog mappings
  • Map With respective Category catalogs for Request Management Flow

Incident Management:

CoreStack can be used to create Incidents in ServiceNow for automation failures happening as part of the self service fulfilment workflow.

Configuration Description, Caller of the incident with Incident state to be updated in incident Management configuration for effective management of incidents. Assignment Group is optional.

Change Management :

CoreStack can be used to create pre-approved change requests as part of the Self Service workflow. It can also update the ServiceNow CMDB for any resource creation / changes in the cloud accounts done as part of the Self Service workflow.

Change Description, Affected CI/Service of the request with state, Reason for Change to be updated.

Click on Next to proceed to Authorization section.

3. Authorization Tab

Select from the CoreStack Roles listed in the Authorization tab based on which roles should have access to this account once added into CoreStack.

Click on Finish to complete the account addition.

Integrated Automation Workflow

ServiceNow service request management flow till closure of service request process steps is as below:

  • User creates a Request in ServiceNow, approval flow is initiated based on the catalog requested.
  • Once the request is approved the details will be published to the CoreStack webhook for provisioning resource automation.
  • CoreStack will create a change and initiate the provisioning.
  • Request status will be updated for each sequence of execution. (Enables requester to view the updates right from the request details)
  • CMDB entry will be created once all the tasks are performed.
  • Change closure and SSR closure will be initiated once the tasks are complete.

CoreStack Provisioning & Post Provisioning Workflow with ServiceNow Integration:

In typical Enterprise environments, resource provisioning is not just a single step stand alone process. There are multiple standards and best practices that need to be incorporated. Some of these are actions within the target cloud such as setting the right back-up and security policies, following tagging standards etc. There would also be requirement to integrate with multiple enterprise toolsets for antivirus, patching, monitoring etc.

CoreStack can automate the entire set of actions involved in provisioning multiple resources in the cloud and performing multiple post provisioning steps in the cloud or in connected tools using blueprints.

Provisioning & Post provisioning workflow with ServiceNow Integration process steps example as below.

Connecting blueprints and setting up fully automated complex workflows may require some custom configurations. Please talk to the support team for assistance.