ConnectALL interacts with ServiceNow via its REST API.
Other entities - Check here for advanced configurations
Issue Linking – Issue Linking is supported for the entity types such as Incident, Problem, Change Request, Epic, Defect and Enhancement.
Sync Staging & Master Tables
Sync Standard & Custom Fields
Sync Service Catalog
Required Roles & Permissions:
The user configured in ConnectALL must have the below-mentioned roles and table permissions,
|incident_manager||Required for Incident and Problem entity.|
|change_manager||Required for Change Request entity.|
|personalize_choice||Required if ConnectALL app is NOT installed via ServiceNow Store|
|x_11154_g2g.caadmin||Required if ConnectALL app is installed via ServiceNow Store. By Assigning this role, the above three roles will be automatically assigned to the user. Hence, assigning the above three roles separately is not required.|
In addition to the above, following ACL's at table level has to be created for the role associated with the user at Global level.
PS: When ConnectALL is installed to ServiceNow instance from the ServiceNow store, then the ACL's has to be created for the x_11154_g2g.caadmin role at ConnectALL application level.
|sys_dictionary||Read||Global / ConnectALL||Required if the ConnectALL app is NOT installed via ServiceNow Store|
|sys_dictionary.*||Read||Global / ConnectALL||Required if the ConnectALL app is NOT installed via ServiceNow Store|
|sys_glide_object||Read||Global / ConnectALL||Required if the ConnectALL app is NOT installed via ServiceNow Store|
|sys_glide_object.*||Read||Global / ConnectALL||Required if the ConnectALL app is NOT installed via ServiceNow Store|
|sys_db_object||Read||Global / ConnectALL|
Required if the ConnectALL app is either installed or not installed via ServiceNow Store
|Read||Global / ConnectALL||Required if the ConnectALL app is either installed or not installed via ServiceNow Store|
- Service Desk Agent creates an incident in ServiceNow.
- ConnectALL creates a new Bug in JIRA for every incident.
- The developer works on the reported bug and updates the status with a possible resolution.
- ConnectALL synchronizes the status changes back to ServiceNow to notify about the current resolution.
Configure Application Link:
Enter ServiceNow connection parameters URL, and a valid application login credentials to create a mapping. The user must have required roles and permissions as mentioned in the previous section.
For those who integrated ServiceNow with LDAP, create a local user account in ServiceNow and use the local user in ConnectALL configuration. The URL has to be suffixed with /login.do
Select a master table and its corresponding staging table to be synchronized. ConnectALL directly reads records from the master table and updates would always go staging table. Staging table and the required transformation has to be configured in prior to this step.
Optionally staging table can be set to none when the sync has to happen on a certain master table directly.
Only when the below property is set to true in ServiceNowTables.properties, available staging table information will be displayed in the drop down.
Also, please add the below set of keys in ServiceNowTables.properties to use staging table.
PS: Restart Tomcat and Mule services after changing the property configuration.
- Users are allowed to choose only the staging table (CAIncident) which is created by installing the ConnectALL application via ServiceNow store.
- If you would like to choose your own staging table other than the CAIncident staging table, then please send an email to firstname.lastname@example.org on the relevant configurations required to use the same.
When planning to use staging table, then the corresponding staging table field configuration has to be selected for each field by clicking the icon.
In the screenshot above, u_short_description is the staging field id for the short description master field. Similarly, for all other fields (except attachments and comments) staging table field id has to be configured.
Reference field mapping
The reference field mapping enables ConnectALL to sync the value of the reference field (of a particular work item that you have mapped). If you do not configure the reference field, the sysID of the reference object will be synchronized instead of the relevant reference field.
ConnectALL provides an option to let the user choose which field on the reference object he choose to synchronize from the field configuration screen by clicking on the "Cog wheel" of the mapped field.
Considering the mapped reference field is a drop-down, the user should be able to do the value mapping based on the choices for that reference field.
Comment field mapping (supported for all entity types)
Comments syncing can be achieved mapping Work notes and/or Additional comments, with differing results.
The above mapping without any value mapping will sync the work notes from ServiceNow to the other adapter and vice-versa.
The above mapping without any value mapping will sync the public comments from ServiceNow to the other adapter and vice-versa.
For control over comment visibility between Jira and ServiceNow, click on the pencil icon to edit the value mappings and Enable the checkbox "Enable Comment Visibility Value Mapping". On enabling this checkbox you can provide value mapping for the comment synchronization.
- *Null => represents the public comment.
- *Private => represents the private comment.
Use Case 1:
- Sync Public comments from JIRA to ServiceNow and vice-versa
- Sync Private/Restricted Developers comments to ServiceNow as Private Comment (Work Notes) with work_notes_list or restricted to the users mentioned as below.
- Other private comments will be skipped for synchronization.
- The value mentioned in the above table is Developers (JIRA Role) and users (adela.cervantsz,aileen.mottern,allan.schwantd) => indicates the user name of the users in ServiceNow.
- In the case of JIRA, the restricted comment can be mapped only to a specific role, whereas the restricted comment or work_notes in ServiceNow can be assigned to multiple users. Hence we have mapped a single role ("Developers") in JIRA to multiple users (adela.cervantsz,aileen.mottern,allan.schwantd) in ServiceNow or you can map it to a single user also.
- In the case of multiple users, the usernames should be separated by a comma (,). (e.g: adela.cervantsz,aileen.mottern,allan.schwantd)
Use Case 2:
- Sync Public comments from JIRA to ServiceNow and vice-versa.
- The ServiceNow Work Notes comments with work_notes_list (adela.cervantsz,aileen.mottern,allan.schwantd) will be skipped (will not be synced to JIRA).
- Other private comments from ServiceNow other than the mapping, will be written as Developers comment in JIRA.
Use Case 3:
- Sync Public comments from JIRA to ServiceNow.
- Public comments of ServiceNow will be skipped and not synced to JIRA.
Use Case 4:
- When mapping between ServiceNow to ServiceNow, when some users are same between these two instances and if you want to retain those users, you can configure the value mapping like the below.
Use Case 5:
- Sync Public comments from JIRA as Private comments in ServiceNow.
- Sync Private comments from ServiceNow as a Public comment in JIRA.
Use Case 6:
In an app-link between ServiceNow and VSTS, when you have mapped the ServiceNow worknotes and VSTS Comments, here is what happens:
When you add a comment in VSTS, it will sync as worknotes in ServiceNow. Likewise, If you add a worknote in ServiceNow, it sync’s as Comments in VSTS.
However, If you add a comment in the Additional Comments in ServiceNow, it will not sync to Comments in VSTS as the field mapping is between Comments of VSTS and worknotes of ServiceNow.
Use Case 7:
In an app-link between ServiceNow and VSTS, when you have mapped VSTS comments with ServiceNow additional comments, here is what happens:
When you add additional comments in ServiceNow it will sync as Comments in VSTS, and likewise the Comments in VSTS will sync as Additional Comments in ServiceNow.
However, if you add a worknote in ServiceNow it will not sync as Comments in VSTS as the field mapping is between the Comments of VSTS and Additional Comments of ServiceNow.
Say you have created an app-link between ServiceNow and VSTS, mapping ServiceNow’s Additional Comments, and VSTS’ History. When you add History in VSTS, it will sync as Additional Comments in ServiceNow. If you change the field mapping on the ServiceNow side to Work notes (Instead of Additional Comments) in the app-link, and add History in VSTS – it will resync all the existing comments in VSTS as Work notes in ServiceNow.
ServiceNow User Configuration:
ConnectALL expects the Sync User configured to have the GMT timezone set in his profile. You can verify or change the timezone by clicking on the Username in the home screen.
ServiceNow adapter has an additional properties file for advanced configuration. The following options can be configured in MULE_HOME/conf/ServiceNowTables.properties
Table name used to test the connectivity to the server:
Load choice values such as status, etc.. in the value mapping screen:
Load reference fields values such as user, groups, etc.. in the value mapping screen:
Add non-task entity(table) in entity mapping screen:
Staging tables configuration:
By any chance, the access to the following master tables are restricted, we can provide a mapping for its equivalent staging/abstract tables in this properties file,
Test Management Feature
ServiceNow has the feature for test management where the archival of test cases and test step along with Planning for the test is feasible. ConnectALL works eloquently for this feature in establishing the relationships as expected with its ally application.
Following table permission is required to use the test management feature.
|sys_dictionary||Read||Used for fetching metadata and field information|
|sys_choice||Read||Used for fetching metadata and field information|
|sys_db_object||Read||Used for fetching metadata and field information|
|sys_glide_object||Read||Used for fetching field datatype information.|
|sys_journal_field||Read/Write||Used for comments sync|
|ecc_queue||Read/Write||Used for attachments sync|
|sys_attachment||Read||Used for fetching attachment content|
|task||Read||Used for fetching metadata and field information|
|tm_test_suite||Read/Write||Used to Create/Update a test suite inside the test repository|
|tm_test_case||Read/Write||Used to Create/Update a test cases inside the test repository under a given test suite|
|tm_test||Read/Write||Used to Create/Update a test step inside the test repository under a given test case|
|tm_test_plan||Read/Write||Used to Create/Update a test plan inside the test execution section|
|tm_test_environment||Read/Write||Used to Create/Update a test environment details inside the test execution section|
|tm_test_case_instance||Read/Write||Used to Create/Update a test cases instances inside the test execution under a given test plan|
|tm_test_instance||Read/Write||Used to Create/Update a test step instances inside the test execution under a given test case instance|
|m2m_tm_test_case_instance_defect||Read/Write||Used to Create/Update a test case defect under a given test case instance's reference|
Below is the available task types associated to this feature in the ServiceNow adapter.
In the above task types, 'Test/Test Plan Test' are defined as Test Steps in Service Now terms. Every TASK TYPE is considered to be a stand alone entity and user can map fields in its individual entity, accordingly.
Establishing Parent-Child Relation.
ConnectALL has a smart feature of deducing the parent ID(Provided a mapping for the parent entity is established) and mapping it with the child entry which is created in ServiceNow Test Management. Below hierarchy depicts the parent-child relationship for the available task types.
For an example case, Under Test Repository - If user has mapped application links for test suite and test case respectively, then test suite ID field isn't required to be added in the field mapping. This will be deducted dynamically and mapped accordingly. Below is the sample case where the field is ignore in field mapping.
Similar features apply for every parent-child entity with the rule of thumb that separate app links are created before expecting dynamic linkages.
Mapping Test Suite ID for creating Test Case Instances inside Test Plan
While creating test plan application link, ConnectALL provides a custom field - "Test Suite Alias" which is always mapped against a constant and advocates only unidirectional support. User can either provide the Test Suite ID(ServiceNow SysId) or the corresponding source application ID for which the mapping is must in ConnectALL. Below describes the same.
In the below example screens, user either directly provides the SYS_ID or the corresponding application's identifier(Presume that this linkage was established through ConnectALL).
With the above when User creates a test Plan the Test Cases inside the test Suite gets created as new test case instances under the TEST PLAN. (Only CREATION of TEST CASES is supported)
Dynamically Creation/Update of Test Steps from Test Cases
When user provides the mapping for the test case, ConnectALL comes up with the provision to map the Test Steps which is part of the every test case. In this case an exclusive custom field known as "Test Case Steps" is made available in the list of fields. This field can accommodate a JSON Array as input which is supposed to hold individual entity of JSON Objects which will be the Test Name, Test Description, Expected result and sequence.
Below is a sample application link between ServiceNow and ALM which is configured to establish this feature.
In this case the TEST CASE STEPS of ServiceNow is mapped with STEPS in ALM - Where the STEPS will return an ARRAY of Test Steps which is deciphered in ServiceNow and recorded accordingly. On top of this, there is a mandatory configuration in the ConnectALL.properties to be made to achieve the appropriate synchronization here.
The field names of the source and destination application's test steps are to be added here with a comma separated. This will be verified in the code logic to the respective model object conversion for further processing. In the above example property configuration -
test - ServiceNow Test Step Name | stepName - ALM Test Step Name
test_description - ServiceNow Test Step Description | stepData - ALM Test Step Description
order - ServiceNow Test Step Order | sequenceId - ALM Test Step Sequence
expected_result - ServiceNow Test Step Expected Result | stepResult - ALM Test Step Result
For configuring the timecard related synchronization, please refer here
Automatic User Value Mapping
ConnectALL supports Automatic user value mapping for ServiceNow. Below is a screenshot that illustrates this; where
name=First name and Last name
For more information on automatic user value mapping and to find out how it works, click here.
Issue Linking Limitation in ServiceNow
When you enable the issue linking option for ServiceNow in an app-link, you will notice the below explained behavior:
In a ServiceNow record when you make an individual change that involves creating or modifying dependent stories, the changes will not be updated in the other application when ConnectALL synchronizes that record. On the other hand, if you do any other modifications along with creating or modifying dependent stories, ConnectALL will be able to read all the changes (including creating and modify dependencies), and the update will reflect the dependent stories modifications as well, when the record is synchronized. This is due to a limitation in the ServiceNow application.
Time Difference Configuration
To know how to calculate the time difference, and configure it in the ConnectALL UI, read the topic Time Difference Configuration.