Review

connector/doc/Kordia_ServiceNow_Ticket_Manager.md

@@ -41,7 +41,7 @@ HTTP CONNECTION:
 
 ### Initialization
 
-When you have created the element, go to the the **Config** page and fill in the **Client ID**, **Client Secret**, and **Refresh Token**. These will be used to establish authentication with the ServiceNow application and allow ticket updates afterwards.
+When you have created the element, go to the the **Config** page and fill in the **Client ID**, **Client Secret**, and **Refresh Token**. These will be used to authenticate with the ServiceNow application, which will allow ticket updates afterwards.
 
 In addition, you will need to fill in the **Correlation rule folder**. All Correlation rules that can trigger ticket updates must be in the same folder.
 
@@ -53,7 +53,7 @@ This Automation script contains an input parameter that will be used for the imp
 
 ### Correlation rules
 
-Correlation Rules should be created in order to create/update/delete tickets based on DataMiner alarming. Taking into account Kordia's setup of Customers and Services being represented as DataMiner services, and the fact that each Customer may contain one or more Services, the Correlation rule should be created to monitor a DataMiner service representative of a Kordia Customer.
+Correlation rules should be created in order to create/update/delete tickets based on DataMiner alarming. Taking into account Kordia's setup of customers and services represented as DataMiner services, and keeping in mind the fact that each customer may have one or more services, the Correlation rule should be created to monitor a DataMiner service representative of a Kordia customer.
 
 ## How to use
 
@@ -67,9 +67,9 @@ This page also contains a logger table that has the POST request data sent and t
 
 On this page, the Tickets table displays information about the tickets that have been created by DataMiner based on the Correlation rules used with the connector.
 
-Flapping Window is used for cases where DataMiner alarms are flapping but incidents must not be closed if such flapping window has not passed. A flapping incident is for example an alarmed interface that keeps switching between Up/Down in a short amount of time. This reduces the number of false positives/negatives in the operation and also helps us to calculate the correct Duration of an incident as it can be seen in the Tickets table.
+The "Flapping Window" is used for incidents where alarms are quickly switching between states. Such a flapping incident can for example be an interface that has an alarm and that keeps switching between up and down in a short amount of time. These incidents will not be closed until the flapping window has passed. This reduces the number of false positives or negatives in the operation and also helps to calculate the correct duration of an incident as shown in the Tickets table.
 
-The page also contains toggle buttons for auto-clear functionality of the Tickets table and also for the flapping functionality.
+The page also contains toggle buttons for the auto-clear functionality of the Tickets table and for the flapping functionality.
 
 ### Config Page