Vivek Chavan – LogiUpSkill

Scripted REST API

Vivek Chavan — Fri, 06 Feb 2026 11:55:16 +0000

Scripted REST API

Scripted REST API is a server-side interface in ServiceNow that lets external systems send and receive data using HTTP methods (GET, POST, PUT, DELETE) with custom logic written in JavaScript.

Table API provides access to all fields of a table (based on ACLs), which means consumers can retrieve or modify every accessible field in that table.

In contrast, Scripted REST API allows us to control and limit field access by explicitly defining which fields are exposed in the response as per business requirements.

Basically, Table API exposes all accessible fields, whereas Scripted REST API allows us to restrict and expose only required fields, improving security and performance.

Scenario 1 – Create scripted REST API to get count of records in any table in ServiceNow

Scenario 2 – Create scripted REST API to get 5 fields of incident record by passing sys id.

Solution – Navigate –> All –Scripted rest API –> New

Create record as below:

Now create one resource to get data form system as below by clicking in new

Now scroll down and test our scripted REST API by clicking on Explore REST API

Now Fill the table name as input to Api parameter e.g.– incident, problem, change_request

Now click on send button on below and scroll down to see result

Use case 2– New incidents are created daily in the target instance by synchronizing incidents from source ServiceNow instance that are in the new state and were created between yesterday and today.

To achieve above use case in source instance create Resource in same scripted REST API

Give name getIncByState , select GET HTTP method and in relative path give the state as dynamic value

Write a script which sends a response to another instance by requesting a state value.
Create an array of object and fetch incidents whose state is new and any input and add records in array of object, assign array of object to response with count like shown below.

Now, in target instance opens scheduled jobs to create a new scheduled script for fetching incidents from source instance.

Click on “new” to create new and select Run – Daily, Time zone –user system time zone and Give time value to run script on the time

Write a script in a scheduled job to fetch data in the target instance.

Now check the incident table, some records will be created in the target instance same as the source instance between yesterday and today.

Open incident table in source instance and create 2-3 incidents

Now click on “Execute Now” scheduled job and see the target instance incident table. Incidents will be created in the target instance form yesterday.

This use case implements a Scripted REST API to synchronize incidents between two ServiceNow instances by automatically creating new incidents in the target instance daily. The integration filters source incidents to include only those in the new state and created within a defined time window (from yesterday to today), ensuring that only relevant and recent records are transferred. This approach maintains data consistency across instances, avoids duplicating or outdated records, and supports efficient, scheduled incident synchronization.

The post Scripted REST API first appeared on LogiUpSkill.

Service level Agreements (SLA)

Vivek Chavan — Tue, 03 Feb 2026 13:06:18 +0000

Service level Agreements (SLA)

Service Level Agreement

It is a contract between the service provider and the customer that ensures response and resolution of tasks within a specified timeframe.

SLA timer

The SLA timer component is to track the amount of time required to complete the task as defined by the matching SLA definition.

Response –

It is the time taken to acknowledge the ticket.

Eg – Time required to give response for an incident such as assignment of incident to the user.

Resolution –

Actual time taken to resolve a ticket.

Eg- Time required for resolve the incident.

OLA –

An Operational Level Agreement (OLA) is an agreement that defines service commitments between internal teams or supporting organizations to ensure SLAs are met. (e.g., Network Team & Service Desk)

SLA Conditions-

Start Condition –

The SLA starts when this condition evaluates true.

Example: Incident state is New or In Progress

Pause Condition –

Defines when the SLA timer is temporarily stopped.
Time is not counted while the pause condition is true.

Example: Incident state is On Hold, Waiting for customer response

Stop Condition –

Defines when the SLA timer ends.

Example: Incident state is Resolved or Closed

Reset Condition –

Defines when SLA timing is recalculated as if it started again.

Eg – when incident is reopened

Scenario:

The organization tracks user-reported incidents with SLAs defined for Priority 1 cases. A Response SLA of 15 minutes starts when the incident is created and assigned to a group and ends when it is assigned to an individual. A Resolution SLA of 3 hours begins at incident creation and ends when the incident is resolved, pausing while the incident is in the On Hold state and resuming once work continues. Both SLAs operate 24/7 based on the caller’s time zone.

Navigate to → All → SLA → SLA Definitions → New

Solution –

1.Create an SLA record for Priority 1 with a 15-minute response time, as per the configuration below.

2.Response SLA will be completed when it is assigned to any user.

3.Create an incident record with Priority 1 and assign it to any assignment group. The Response SLA is attached to the incident in the related list.

4. The Response SLA timer is breached after 15 minutes.

5.The Response SLA is marked as completed once the incident is assigned to a user.

6.Create Priority 1 Resolution SLA as below

7.The SLA is paused when the incident is On Hold, and business time is not calculated.

8.The SLA timer stops when the incident is resolved or closed, and the SLA state is marked as completed.

9.Create an incident record with Priority 1 and assign it to the user as shown below. The Resolution SLA will be attached to the incident.

10.After the incident is resolved, the SLA state is marked as completed once the stop condition is met.

The post Service level Agreements (SLA) first appeared on LogiUpSkill.

Access control List

Vivek Chavan — Tue, 03 Feb 2026 12:39:31 +0000

Access control List

Access Control List

Access control list or ACL is a part of Security in ServiceNow.
ACL can be applied on Tables, UI Pages, Script Include also.
It is Nothing But to give permission to Tables & Fields.
Where we can restrict user’s access for below:
i. Create
ii. Read
iii. Write
iv. Delete
To access ACL admin needs to elevate the role to “security admin”.
Admin override allows admin users to bypass ACLs. Even if an ACL would normally deny access, an admin can still perform the action.

Evolution order of ACL-

Role – ServiceNow checks whether the user has at least one role listed in the ACL. if condition is false then access denied
Condition – ServiceNow evaluates the Condition field on the ACL, if condition is false then access denied
Script – Script must return true to allow access, returning false (or nothing) denies access.

ServiceNow checks ACLs in this order:

table. Field
table. *
table. None
* *
* . field
* . none

The first matching ACL found is enforced.

Use case-

Configure the ACL so that the Payroll Manager group has full access to payroll data with create, read, update, and delete permissions, while the Payroll User group has read-only access and is restricted from creating, updating, or deleting payroll records.

Solution-

Create two roles ‘payroll_manager’ and ‘payroll_user’ and two groups Payroll Manager, payroll User.

Assign payroll_user role to Payroll User group and assign payroll_manager role to payroll manager group and assign some users to both groups.

Click on profile and Elevate role to “Security admin” to access the ACL.

Create ACL with read access to payroll user table. None and give roles “payroll_user” and “payroll_manager”.

Or Navigate to Payroll table and scroll down to access control related list.

Impersonate to user with “payroll_user” role.

Open payroll record can read record but cannot update create and delete record.

Because we have given only read access for user group so user can only see records.

Create the ACL record with create, write, delete access with payroll manager role.

Manager can access record create, read and write on record.

Now Create * access to payroll table for read access.

Impersonate with user having payroll_user role Payroll. open payroll record and you will see payroll table fields but not data.

Summary –

Implemented role-based access control for the payroll system. The Payroll Manager role was granted full CRUD (create, read, update, delete) access to payroll records, while the Payroll User role was restricted to read-only access. This configuration secures the access for valid user.

The post Access control List first appeared on LogiUpSkill.

Flow Designer Properties

Vivek Chavan — Tue, 03 Feb 2026 12:07:20 +0000

Flow Designer Properties

Flow Designer in ServiceNow is a low-code automation tool used to design and automate business processes without heavy scripting. It allows users to create flows by defining triggers, conditions, and actions to automate tasks such as approvals, notifications, record updates, and integrations.

To create new flow, navigate to All – Process engine — Flow designer — New

After you click on New button on page, it will open to create new flow.

Flow Name
Enter a clear and meaningful name that describes the purpose of the flow.
This helps users easily identify the flow later.

Application
Select the application scope in which the flow will run.
It controls which data and actions the flow can access.

Description
Briefly explains what the flow does and when it is triggered.
This helps others understand the flow logic quickly.

Now click on Show additional properties

4.Protection
It defines whether the flow is editable or read-only after creation.
Setting it to read-only helps prevent unauthorized changes to the flow.

5.Run as
It specifies the user context under which the flow executes.

User who initiates session
The flow runs using the roles and permissions of the user who triggered it.
the system limits flow actions by user ACL restrictions. Ensure that security restrictions don’t prevent users who trigger the flow from performing flow actions.

System user
The flow runs with system-level privileges, regardless of who triggered it.

Updates appear as done by System, Does not evaluate Users roles/access when running the Flow.

6.Flow Priority
Flow priority determines the execution order when multiple flows are triggered at the same time. By default, flows can be set to Low, Medium, or High, with High priority flows running first.

The post Flow Designer Properties first appeared on LogiUpSkill.

Decision table

Vivek Chavan — Tue, 03 Feb 2026 11:31:25 +0000

Decision table

A Decision table in ServiceNow is a configuration option that can be used to evaluate multiple conditions and return a result based on predefined logic. It simplifies complex decision-making by organizing rules in a tabular format, where each row represents a unique set of conditions and their corresponding output.

Decision Tables are used when:

Business logic depends on multiple conditions
Rules change frequently
Non-developers (admins / process owners) should manage logic
You want consistency, reusability, and auditability

Inputs (Conditions)

Fields used for evaluation

Example: Category

Rules (Rows)

Each row represents one decision rule
Use case:
If Category = hardware then assignment group is Hardware, Category =Software then assignment group = Software, Category = Network then assignment group = Network and Select assignment group based on category.

Navigate to Decision Tables
All → Decision Builder → Decision Tables
Create new decision table like below

Now create a flow in flow designer and attach this decision table to flow like below

Now use update record action to update the assignment group based on category using data pill of corresponding decision table.

Output – Open incident form and update the category to “Hardware” on incident and check assignment group in incident will be updated to Hardware.

The post Decision table first appeared on LogiUpSkill.

SLA

Vivek Chavan — Fri, 09 Jan 2026 06:20:57 +0000

Service Level Aggrement (SLA)

SLA Priority Increase and Decrease

Service Level Agreement (SLA):

Service Level Management (SLM) enables you to monitor and manage the services offered by your organization.

It is a contract between the service provider and the customer that ensures response and resolution of tasks within a specified timeframe. It will include details about resolution time, breach levels and their corresponding penalties.

If the organization not able to fulfil the goal of the services in the time specified in the agreement. Then, it is considered as a breach of the Agreement.

The breach can cost the penalty or impact the image of the organization. Thus, SLA helps organization to measure the quality and efficiency of the task assigned to the employees by determining the progress of the task.

Response – It is the time taken to acknowledge the ticket.
Eg – Time required to give response for an incident such as assignment of incident to the user.
Resolution – Actual time taken to resolve a ticket.
Eg- Time required for resolve the incident.

1.Retroactive start: It starts the SLA from the time start time of the previous SLA.

2.Retroactive pause: This would consider the pause time of previous SLA.

Requirement: Create an SLA’s for priorities P1, P2, P3, P4 such that when you increase the priority the retroactive start should be on updated field and when you decrease the priority the retroactive start should be created field.

Solution:

Let’s create a temp field of type date/time for incident form layout.

This temp field will store the created or updated date/time based on the requirement of increase and decrease of priority.

Let’s create SLA definition for the priorities 1-4 of the incident table i.e. P1, P2, P3, P4 of duration 3 min,

Keep Schedule as No schedule for all SLA’s for now. And other fields as default.

Here start condition should be based on priority.

And cancel condition should be when start condition not met.

Retroactive start and Retroactive pause should be true for all. And select your ‘temp’ field for ‘set start to’ field.

Pause condition should be when state is put on hold.

At the end, stop condition should be when State is resolved.

Similarly create other SLA’s for other priorities P2,P3,P4.

Now it’s time to write the Business rule which would set the temp field according to the priority change.

The post SLA first appeared on LogiUpSkill.

Email Notification in Service-now

Vivek Chavan — Fri, 09 Jan 2026 05:50:20 +0000

Email Notification in Service-now

Email Notification :

Email notifications are a type of triggered email—email that’s sent in response to specific user action or an event.

Creating an email notification involves specifying when to send it, who receives it, what
it contains, and if it can be delivered in an email digest.

Types of Email Notifications:

Outbound Email Notifications:

Sending mail to users from ServiceNow instance.
ServiceNow used SMTP to send the mail from the server.

Inbound Email Notifications:

Receiving mails from user in ServiceNow instance
POP is used.

For email notifications, we have to set some settings.

Navigate to System Properties => Email Properties, the following list of properties will be displayed,

In Outbound Email Configuration,

Select Email sending enabled and enter any random email address as shown in above snapshot.

In Inbound Email Configuration,

Select Email receiving enabled and at the bottom write the trusted domain from which ServiceNow should receive mails. If we enter star (*) then from all domains the email will be received.

Check “Automatically create users……..” to create users automatically when any email is received from the user.

See below snapshot.

Outbound Notifications :

Create Outbound notifications for the incident table when the record is inserted..

Navigate to Configure => All => Notifications and click on New button as below,

The following form will be displayed. Enter condition in “When to send” section,

1.Send when : Record inserted or updated

Now select the user or group to whom the email to be sent as follows, User/Groups in field is form selected table.

Configure the email as follows,

Save the above form.

Now, Create a new record in incident table

Save the above record.

Since, short description contains “ashwini”, so as per the outbound notification we set, the email will be automatically sent to the mentioned user. The email engine process this mail.

First, this email will go in “Outbox” under System Mailboxes. In Outbox the mail is in Ready state. Email will be sent to the user, and it will be saved in Sent under System mailbox as follows

Since this email details are in Sent mailbox and its state is “Processed” that means the mail has been sent to the user which is mentioned as a recipient while creating Notification.
For recipient check notification as follows,

The mail will be like below,

To check the sender navigate to Email Properties =>Email Accounts as follows,

If the user reply to this mail, it will be displayed in All=>Inbound =>Received

To check the received mails, navigate to System Mailboxes =>Inbound =>Received as below,

The email engine of ServiceNow will identify the “Reply” by the Ref no of the email which is send by the ServiceNow to the user as below,

2.Send when: user defined event is fired:

For that there should be a user defined event.

To create Event, navigate to Event Registry as follows,

(Fired by :to trigger this event we should write some code ,we can write it in business rule.write here the name of the business rule

Queue : whenever u r triggering any event it shd be the part of the system queue)

Click on Submit.

To trigger this event we need to write a script.(business rule or script include)

So create business rule to run after updating the incident record if short description contains “ashwini”

To trigger the event we have eventQueue().

Use the function eventQueue(“Your event name”,”the current object”, “parameter1”, “parameter2”)

Refer follow screenshots for business rule ,

Now change “Send when” option to “Event is fired” and keep all as it is in outbound notification as below,

Now update any incident and check the mail ,

Now the mail should be sent to user as below,

To send the notification containing param values(passed in business rule while triggering the event) ,access param values in outbound notification as below,

Now again update any incident record and check the mail.

Mail Script :

Email scripts allow for business rule-like scripting within an outbound email message.
With mail scripts, you can dynamically change the email output of your system based on
different criteria. Mail scripts allow you to perform simple tasks, such as displaying incident
data, and complex ones, such as making advanced database queries.
You can add a ${mail_script:script_name}embedded script tag to the body of the email notification
or template, replacing script name with the name of the script you created. This makes it easy
to use the same scripts in multiple email notifications or templates.
Now to add email scripts in the body of our mail, first we will have to create
mail scripts. To create a mail script open the Notification Email Script module and click on new.
We can write our code using template.print();

(Check below code in “message HTML” of Notification )

To see the code for mail script, navigate to System Notification => Notification Email Scripts

You will get the list of all mail scripts, search for the required one as below,

Now update incident record and check the mail,

Inbound Actions:

When the system receives the mail, it can be seen in inbox / received mail.

Inbound actions in ServiceNow are used to process incoming emails by creating or updating records within the platform. These actions are similar to business rules and use conditions and scripts to take action on a target table.

When an email is received, the system checks for a watermark that associates it with a task and other conditions. If the conditions are met, the system takes the inbound email action configured.

The system can take two types of actions: Record action, which sets a value for a field in the target table, and Email reply, which sends an email back to the source that triggered the action.

Navigate to System Policy => Inbound Actions and click on New button

The following form will be displayed.

Set the type as “New” and Action type is “Record Action”.

Available Types are:

New: An email that is not recognized as a reply or forward.
Reply: An email with a watermark, with an In-Reply-To email header, or whose subject line begins with a recognized reply prefix.
Forward: An email whose subject line begins with a recognized forward prefix, even if the email also contains a watermark or In-Reply-To header.

Set the condition as if Subject contains “ashwini” (if this condition met, inbound action will trigger)

Now set the Actions as below,

Now if any user sends an email whose subject contains “ashwini”, then as per the Inbound action condition, inbound action will trigger,

Check in Inbox,

After some time, it will go in Received mails,

Click on that record, Email details will be displayed as below,

You can see the value of Target, in the above screenshot Incident having Number INC0010227 is created,

Open that record.

As per the condition in Inbound Action, Sender of Email becomes Caller and Subject of email becomes short description.

You can preview this email by clicking on link under Related links at the bottom,

In Email log, you can see 2 incidents are created having number INC0010226 and INC0010227

To stop this, just check “Stop Processing” checkbox.

Now check the inbox/received mails again and check how many incidents are created for one mail.

Gmail:

Inbound: Inbox / Received

Click on this mail and check the Email Log, you will see only one incident has been created,

Scroll down, at the bottom check Email Log,

————————————— Overview ——————————————————-

The post Email Notification in Service-now first appeared on LogiUpSkill.

Service-now Inegration GuideLines

Vivek Chavan — Thu, 08 Jan 2026 05:51:00 +0000

Service-now Integration Guidelines

Service-now Webservice
1. By default, in Service-now for every table there will be SOPA WSDL and Rest endpoints for following operations
2. For Soap if your table name is “u_customer_table”, the WSDL will be
  1. https://instancename.service-now.com/u_customer_table.do?wsdl
3. For Rest if your table name is “u_customer_table”, the WSDL will be
  1. https://instancename.service-now.com/api/now/table/u_customer_table
4. Soap WSDL functions
  1. Insert
  2. update
  3. deleteMultuple
  4. getKeys
  5. deleteRecords
  6. get
  7. getRecords
5. Rest Endpoints Methods
  1. Post
  2. Get
  3. Put
  4. Delete
Soap Web Service Integration with Third Party Tool (Here we are considering as another service instance is a third party tool)
1. Whenever we need to integrate with third party tool, we need to request the SOAP WSDL from them.
2. Once we will get the WSDL from third party tool, we will create SOAP Message in ServiceNow.
3. How to Create Soap Message
  1. System Navigator–>Search Soap Message as below
  3. Click on “SOAP Message” Module, you will get all the list of Soap Messages.
  4. Click on “New” UI Action.
  6. Here I am using WSDL of incident table as fallows
  8. And Save it.
  9. After Save you will get the related link at bottom of the form
  10. Click on that
  12. After Clicking on the UI Action : Generate Sample SOAP messages, it will create a WSDL xml and functions and will get one add info message at top as fallows.
  15. Click on the “insert” function in another tab.
  17. Select Authentication type as Basic one and select the same profile from reference field in Basic auth Profile and save the record.
  18. Click on the Auto Generated Variables
  20. After clicking on that, you will get all the variable in “Variable Substitution” related list
  22. Select insert.shortdescription variable and put some test value as fallows
  24. After that click on Test from related link
  26. After clicking on Test, you will get the request and response xml on the screen.
  28. If you get 200, it means, you have created an incident and in response you will get incident number as well as sys_id.
  29. Now go back to your insert function again.
  30. Click on Preview Script Usages as fallows
  32. You will get a code, which you can use in your server-side scripting.
Rest Web Service Integration with Third Party Tool (Here we are considering as another service instance is a third-party tool)
1. Go through Navigation Search and search Rest
3. Click on New
5. Add the authentication type as a Basic
7. And put values for HTPP Request
9. And save it.
10. Now create HTTP Method for this Message as below – to create it click on New which is on “HTTP Method” related list
12. You will get new form, then please fill the values like below
14. Fill the HTTP Request tab
16. Then create HTTP query parameter and content with variable for description ${des}
18. And save it.
19. Then click on “Auto generate Variables”
21. Then it will create a entry in related list of variable substitution.
23. Put some test value for des variable and then click on TEST
25. After clicking on Test, you will get request and response details.
Http Status Codes
1. 2xx – Success: IT represents Request was accept successfully.
  1. 200 – Success
  2. 201- Success and record created
  3. 202 – Accepted
2. 4xx – Error -IT represents the Request was incorrect at client only means requester.
  1. 400 – Bad Request
  2. 401– Authentication Failed
  3. 403 – Forbidden
  4. 404 -Not Found
  5. 405 -Method not Allowed
3. 5xx -Error -It represents the request was correct but error at Server side.
  1. 500 – Internal Server Error
  2. 502 – Not Implemented
  3. 502 – Bad Gateway
  4. 503 – Service Unavailable
  5. 504- Gateway timeout

The post Service-now Inegration GuideLines first appeared on LogiUpSkill.

Incident Management

Vivek Chavan — Wed, 07 Jan 2026 13:17:07 +0000

Incident Process in Service-now

What is Incident?

Incident is an event of interruption or disruption or degradation in service operation. An open incident implies that the customer is impacted.

Goal of incident management

The first goal of the incident management process is to restore a normal service operation as quickly as possible and to minimize the impact on
business operations, thus ensuring that the best possible levels of service quality and availability are maintained. ‘Normal service operation’
is defined here as service peration within Service Level Agreement (SLA).

Different ways to raise Incident:

User can open Incident Ticket via User Interface (Self Service) or Email.
IT ServiceDesk will open an Incident for all incidents reported via phone, walk-in or Email.
Incident Tickets can be opened automatically by monitoring tool.
The monitoring team will also create incident for qualified alert.

1.Creating Incident via User Interface (Self Service):

In Service Now personal development instance in left navigator search for Incident.

Go to Self Service> Incident> New

Click New it will open Incident Form here in short description end user should write issue faced and define Urgency and Submit form.

2.Creating Incident via Email:

If user don’t have access to the service now or user unable to login to the system in that case incident can be raised by sending mail to ServiceNow,
only if the user is specific or having specific mail id. As per the mail, record get inserted in incident table, for this customization is needed that will
be done in Service Now, System Policy> Email> Inbound Actions.

3.Creating Incident using Service Catalog:

In ServiceNow personal development instance in left navigation search for catalog

Self Service> Service Catalog> Can We Help You?> Create Incident

Enter the issue in Please describe your issue and define Urgency.

Click on submit and see incident created as below

4.Creating Incident using Service Portal:

In Service Portal Home click on Get Help> Create Incident> Submit

Fill urgency and issue click Submit

Incident created as below

All incidents are shown in service portals homepage in My Open Incidents

5.User can create incident by contacting to IT Service Desk via Phone or walk-in and as per information given by user/customer/caller/requester
IT Service Desk will create incident in ServiceNow, Incident> Create New.

Once the incident is logged in into the system now IT service desk agent will work on it. For that in left navigation search for incidents go to Incidents>
open-unassigned

It will check the incidents are not assigned, now open the incident from list as per the short description categorization of incident is takes place then
as per urgency defined by caller incidents priority is set. Then as per the category and priority of incident, incidents are assigned to Assignment group
or to a particular member in that group I.e. Assigned to

Now the assignee will work on that incident to fix the issue/interruption.

Example:

Incident is raised by end user via self- service contact type now see incident life cycle to fix issue as follows

Saanvi is end user she faced an issue that she unable to open email so she has created incident via self-service as follows (for this I impersonate
user as Saanvi )

What is impersonation?

Administrators can impersonate other authenticated users for testing purposes and view impersonation logs. The impersonation option is not visible
in the mobile view of the platform.

When impersonating another user, the administrator has access to exactly what that user can access in the system, including the same menus
and modules. The instance records anything the administrator does while impersonating another user as having been done by that user.

Procedure to Impersonate user:

In the banner frame, click your user name to open the user menu.
Select Impersonate User.

The Impersonate User dialog box appears.

Select a user from the Recent Impersonationslist or enter a different user’s name in the user selection field.
To return to your original login, follow these same steps then select End Impersonation.

Here I impersonate user as Saanvi

Saanvi has created incident via self-service as follows

Now I Priyanka system administrator checked un assigned incidents for that go to Incidents> open-unassigned

To check the incident raised by Saanvi, I will add filter condition in list view as follows

Click on filter icon add condition caller is Saanvi then click Run

Or in search field find caller Saanvi

Then press Enter it will shows incidents where caller is Saanvi/ incidents raised by Saanvi

Open the incident now I will work on that incident to resolve it.

As per short description I set category and subcategory of incident.

According to urgency and impact incidents Priority is set.

In contact type I entered self servicecause incident is raised via Self service.

I entered Assignment group and Assigned to values as below.

Once incident is assigned State of incident changes to In Progress.

Now assignee will work on that incident and if needs more information from caller or any other reason he can keep this On Hold.

For this click On Hold now on hold reason is mandatory save the form it shows Resume UI Action, once information is taken from caller assignee
will resume work by clicking on Resume.

Click on Resume state of incident changes from On Hold to In Progress

Now after solving issue assignee will click on Resolve and state changes to resolved.

After this assignee click on Close Incident to close the incident and state changes to closed

In this way incident get resolved and then closed. The process flow will be like

In this example On Hold, Resume, Resolve and Close Incident UI Actions/buttons are custom UI Actions.

UI Actions:

Here following are the custom UI Actions that I have created and as per UI Action incident state changes as follows

Incident Process in Service-Now

We have incident where we have following process.

We have following state for incident.
1.New
2.In Progress
3.Pending Customer
4.Pending Information
5.Customer Update
5.Resolved
6.Closed

Incident Process till Close1.New created incident in New State
2.Fulfiller should ACK the ticket by clicking on ACK ui action and incident should go in “In Progress” state.
3.Fullfiller can change the state to Pending customer to get information from user i.e. caller.
4.When user i.e. caller send the information then incident state should changed to “Customer update”
5.Fullfiller then change the state to In Progress.
6.After resolving ticket fullfiller can change the state to Resolved.
7.Fullfiller can cancelled the ticket when it is in In Progess.
8.Fullfiller can Reject the incident before Acknowledgment.
9.Fullfiller will not close the incident, to close the incident we have schedule job which will run daily.
10.Incident Auto Close schedule job will close the incient which are in state=resolved the update date is less than 5 days of current date.

Note:

User can Cancelled the ticket by changing the state=Closed and closed code=Cancelled
User can Reject the ticket by changing the state=Closed and closed code=Reject

Close Code and Close Notes:
When Incident changed the state to Resolved or Closed , Close Code and Closed Notes are mandatory fields.

Close Code is choice field
Close notes is String field.

Close Code and Close Notes fields having more specific details about “Why we are closing the Incident.”

SLA:

Responce SLA start when incident is created and stops when Incident Acknowledged (If ACK_Time and ACK_By field has value then incident is acknowledged)
Resolution SLA start when the incident is in “In Progress” and stops when incident is Closed and pause when incident is in one of the state i.e.
Pending Customer, pending information, customer update and resolved.

Incident Priority:

Priority field is always readonly and it is depends on urgency and sevirity fields using datalooup

We have one client script i.e. if the caller is VIP, then the priority should be P1 using client script.

Incident Assignment Rules
We have assignment rules for setting assignment group as per Incident Category and Incident Subcategory

The post Incident Management first appeared on LogiUpSkill.