Shubham Kumbhar – LogiUpSkill

Scripted REST API

Shubham Kumbhar — Thu, 08 Jan 2026 07:17:42 +0000

Scripted REST API

INDEX

What is Scripted Rest API?……………………………………………………………… 1
Advantages of Scripted Rest API………………………………………………………. 2
Roles Required……………………………………………………………………………. 2
Fields of Scripted Rest API……………………………………………………………… 3
Difference between Rest API and Scripted Rest API………………………………. 3
Error Codes in Scripted REST API……………………………………………………… 4
Example……………………………………………………………………………………. 4

1. What is Scripted Rest API?

Scripted REST APIs allow developers to create custom web service APIs in ServiceNow. These APIs enable external systems to interact with ServiceNow by defining endpoints, handling requests, and customizing responses beyond standard table APIs.

Using Scripted REST APIs, developers can:

Define custom endpoints (resources)
Configure HTTP methods such as GET, POST, PUT, DELETE
Accept and process query parameters, path parameters, headers, and request bodies
Write scripts to control request handling, business logic, and response formatting

Scripted REST APIs are created and managed using the Scripted REST Service form, available under:

Scripted Web Services → Scripted REST APIs

This is commonly used for:

Integrating ServiceNow with external systems
Exposing custom data and business logic
Building reusable APIs for scoped applications

2. Advantages of Scripted Rest API

It gives full control over how requests and responses work
You can add custom business logic using scripts
It can work with multiple tables at the same time
You can return custom JSON responses
It supports secure access using roles and authentication
You can handle errors properly with clear messages
It supports API versioning for future changes
It is best for integrating ServiceNow with external systems

3. Roles Required

The role required to create and manage a Scripted REST API in ServiceNow is web_service_admin.

4. Fields of Scripted Rest API

Field Name	Description
Name	Friendly name of the Scripted REST API
API ID	Unique identifier used in the API URI
Namespace	Application scope where the API is created
Active	Enables or disables the API
Default ACLs	Security rules applied to all resources
Base Path	Base URL path for the API
Version	API version for managing changes
Short Description / Description	Explains the purpose of the API
Security	Configure authentication and access control
Content Negotiation	Define supported request and response formats (JSON, XML, etc.)
Resources	Define API endpoints (URI paths)
Request Headers	Define expected HTTP request headers
Query Parameters	Define supported query parameters

5. Difference between Rest API and Scripted Rest API

REST API	Scripted REST API
Pre-built APIs provided by ServiceNow	Custom APIs created by developers
Mainly used for standard CRUD operations	Used for custom logic and complex processing
Limited customization	Fully customizable using server-side scripts
Follows strict ServiceNow table structure	Can return custom response formats
Faster to use for simple integrations	Best for complex and non-standard integrations
Less control over request/response	Full control over headers, parameters, and payload
Example: Table API, Attachment API	Custom endpoints under Scripted REST APIs
No scripting required	Requires JavaScript scripting

6. Error Codes in Scripted REST API

Error Code	Meaning	When It Occurs
200 OK	Request successful	API executed successfully
201 Created	Resource created	Record created via POST
400 Bad Request	Invalid request	Missing/invalid parameters or payload
401 Unauthorized	Authentication failed	Invalid or missing credentials
403 Forbidden	Access denied	User lacks required role/ACL
404 Not Found	Resource not found	Invalid endpoint or record
405 Method Not Allowed	Invalid HTTP method	Method not supported for resource
409 Conflict	Duplicate/conflict	Record already exists
415 Unsupported Media Type	Invalid content type	Wrong Content-Type header
500 Internal Server Error	Server error	Script error or exception
503 Service Unavailable	Service down	API temporarily unavailable

7. Example

A catalog item named User Task Status exists in Instance A, which allows a manager to select a user to view the user’s task details. However, the actual task data (Incidents, Problems, and Change Requests) assigned to the selected user is maintained in Instance B. When the manager selects the User in catalog item in Instance A, the selected user information is sent to Instance B via integration. Instance B processes the request, fetches the count of Incidents, Problems, and Change Requests assigned to the user, and sends the response back to Instance A. The received response is then populated into the User Task Details variable of the catalog item.

Steps of Implementation:

Step 1: Create a catalog item in instance A

1.1. Create Variables

Select User – reference – sys_user
User Task Details – Multi Line Text

1.2. Final Catalog Item will Look Like this on Portal

Step 2: Create Scripted REST API in Instance B

Create a New Scripted REST API.

Navigate to ALL > System Web Services > Scripted REST API’s > New

Give a name to new Scripted REST API and fill the mandatory fields as below:

2.1. Create Resource from related list

Give name to a New Resource and fill mandatory fields as below:

Script –

This script retrieves the user from the request body, fetches the assigned user details from the User table, and returns the data in the response body to Instance A.

Step 3: Create REST Message in Instance A

Navigate to ALL > System Web Services > Outbound > REST Message > New

3.1. Provide Endpoint and Basic authentication details of Instance B.

Give name to REST message and Endpoint of instance B

3.2. Basic Authentication Details

Fill username and password details of the instance B

3.3. Create HTTP Method from related list

Select HTTP method, Endpoint, HTTP Headers and Query Parameters

Step 4: Create Script include to call REST Message in instance A

Navigate to ALL > System Definition > Script Include > New

Give a name to Script Include as below:

Script-

This script will fetch the user that is selected on the catalog item, calls the REST message we have created in instance A, and whatever response we get from instance B, script will fetch assignment details for the user.

Step 5: Create catalog client script for your catalog item which is created in step 1

Fill the required details like Type, Catalog item, Variable Name and UI Type as below:

Script –

This script will get the value of the user from the catalog item. Also, once we select the user on catalog item, it will fetch the assignment details and that details will be populated in the ‘User Task Details’ field.

Step 6: Testing

Whenever manager selects a new user, whatever incidents, problems and change requests are assigned to that user count of that will be populated in the field.

You can see the details of the user has been populated in the User Task Details field.

Similarly, if you select another user then his assigned tasks will be auto populated.

The post Scripted REST API first appeared on LogiUpSkill.

Policy in GRC

Shubham Kumbhar — Wed, 03 Dec 2025 12:58:06 +0000

Policy in GRC

Contents

What is Policy?
Policy and Compliance Architecture.
Roles Required
Process Flow Diagram for Policy
Policy – FORM View
Policy All Fields
Policy States and its Lifecycle

7.1. Approval Rule

7.2. Policy Versions

7.3. Policy Lifecycle Summary

1. What is Policy?

A policy is a formal, high-level statement that defines an organization’s rules, expectations, and guiding principles.
It sets the direction for how the organization operates and outlines what must be done to meet business goals, comply with regulations, and manage risks.
A policy defines an internal practice that an organization or business process must follow to ensure compliance and reduce risk exposure.
In simple words, A policy tells people what needs to be done and why it matters.
Example – Employees must store company data only on approved, encrypted systems and are not allowed to save sensitive information on personal devices or share it through unauthorized applications.

2. Policy and Compliance Architecture

3. Roles Required

Role Name	Description
Compliance Reader [sn_compliance.reader]	Read-only access to compliance data for reporting and monitoring.
Compliance User [sn_compliance.user]	Performs core compliance tasks: create policies, manage controls, test effectiveness, handle exceptions
Compliance Manager [sn_compliance.manager]	Manages daily compliance operations: approves policies, sets acknowledgements, monitors controls, produces reports.
Compliance Administrator [sn_compliance.admin]	Administers compliance application and data, manages dependencies and full configuration.
Compliance Developer [sn_compliance.developer]	Builds workflows, dashboards, reports, and platform components to enhance compliance processes.

4. Process Flow Diagram for Policy

5. Policy – FORM View

Navigate to All > Policies and Compliance > Policies > New

Sections

6. Policy All Fields

Field	Description
Name	Title of the policy document.
Type	Category or kind of policy (e.g., Standard, Guideline, Framework).
Owning group	The team or department responsible for owning the policy.
Owner	The person responsible for the policy’s maintenance and governance.
Compliance score (%)	The calculated compliance percentage for this policy.
Parent	A higher‑level policy under which this policy is nested.
Policy categories	Classification tags or groups used to group similar policies.
State	Current lifecycle stage of the policy (e.g., Draft, Published, Retired).
Valid from	The date from which the policy takes effect.
Valid to	The date until which the policy remains valid (expiry).
Approval method	The method by which the policy must be approved.
Approvers	The individuals or roles who must approve the policy.
Reviewers	The individuals or roles responsible for reviewing the policy content.
Contributors	Individuals or roles who contribute content or updates to the policy.
Description	A short summary of what the policy covers.
Policy text	The full detailed text of the policy.
Policy knowledge base	The repository or knowledge base where this policy is stored.
Published policy	The specific published policy record this setup relates to.
Policy template	The predefined template used to structure and format this policy.
Frequency	How often users must acknowledge this policy (e.g., annually).
First acknowledgement	The date when users must first acknowledge the policy.
Number of days to respond	How many days users have to complete their acknowledgement.
Audience	The group of users who are required to acknowledge the policy.
Reference material URL	A link to supporting documents or resources related to the policy.
Allow users to decline policy	Enables a user option to refuse or decline the policy acknowledgement.
Allow users to request exception	Allows users to request an exception to the policy requirements.
Maximum exception duration (days)	The maximum number of days an approved exception can remain valid.
Additional comments	Any notes or remarks related to the policy’s configuration or changes.

7. Policy States and its Lifecycle

Below flow represents the standard policy lifecycle within a GRC system.
Each stage is a formal status that shows where the policy is in its journey from creation to retirement.

1. Draft

This is the creation stage and Policies are created in Draft by default
A new policy is being written for the first time, or an existing policy is being heavily revised.
The Policy Owner (often a subject matter expert or manager) works with stakeholders (like Legal, IT Security, or HR) to write the content.
Goal is to create the first complete version of the policy document that addresses a specific risk, regulation, or business need.

Fill the mandatory fields along with other fields and then click on ‘Request Review’ UI button and fill the Message given below then state will change from Draft to Review.

2. Review

The draft is complete and is now being circulated to a formal review team.
This group includes reviewers and key stakeholders. These are often department heads, the GRC team, and the Legal/Compliance department.
While in Review, reviewers can send the policy back to draft, edit the policy, can add additional comments
Goal is to ensure the policy is accurate, clear, enforceable, and aligned with existing policies and regulations.

Reviewer will review the policy and then click on ‘Request Approval’ UI Action the provide message then state will change from Review to Awaiting Approval.

3. Awaiting Approval

Approvers receive the approval task in Awaiting approval and approvers can send the policy back to Review
The policy has been reviewed, all feedback has been incorporated, and the final version is now locked. It is waiting for a final “go-live” signature.
This is usually one or more designated Approvers, such as a committee, or the head of the business unit.
Goal is to get formal, auditable sign-off that the policy is officially accepted by the organization’s leadership.

Check Related List > Once Approved state will change from Awaiting Approval to Published.

4. Published

Policy is published after approval
The policy is now active and is the official standard for the organization.
The GRC team or system administrator publishes the policy to a central portal.
KB article is created in the KB identified on the policy record.
Goal is to publish the policy so it is accessible to employees and to trigger supporting activities such as communication, employee attestation, and mapping to related controls.

KB Article is created for the Policy

KB Article

5. Retired

The policy is no longer active or relevant.
The Policy Owner, with approval from GRC/Legal, initiates the retirement.
When a policy is retired, the KB article also retires.
Goal is to retire the policy by removing outdated or unnecessary content—whether it is obsolete, superseded by a newer policy, or consolidated into another policy.
Click on Retire UI action then state will change to Retired from Published.

7.1. Approval Rule

An approval rule in Policy GRC is a predefined set of conditions that determines who must approve a policy or policy-related activity.
It automatically routes the policy to the correct approvers based on attributes like department, policy type, risk level, or ownership.
Example – We are creating Multilevel Approval for policy, Level 1 approval for policy owner and level 2 approval for owning group.
Navigate to ALL > Policy and Compliance > Policies and Procedures > Policy Approval Rules > New

Select Approval Rule in Policy

Create Approval Configuration with required fields

Create Approval Level 1

Also Create Approval Rules for the Tier-1 with filter condition

Similarly, Create Approval Level 2

Also Create Approval Rules for the Tier-2 with filter condition

Now, Test the Approval Rule
1^st Level Approval

If Approved then only 2^nd level approval came

7.2. Policy Versions

Policy versions are sequential iterations of a policy created whenever updates or changes are made.
Each version records the policy’s exact content at a specific time, providing a clear and auditable history of modifications and approvals.
Once policy goes to Published state v1.0 created

If policy goes to draft again and then published then version will change to v2.0

7.3. Policy Lifecycle Summary

The post Policy in GRC first appeared on LogiUpSkill.

Policy Exception in GRC

Shubham Kumbhar — Wed, 03 Dec 2025 12:04:07 +0000

Policy Exception in GRC

1. What is Policy Exception?

A policy exception is a formally documented and approved deviation from a policy when a user or business unit cannot meet specific policy requirements.
In simple words it provides temporary relief for control owners that are unable to meet compliance requirements.
It allows temporary non-compliance under controlled conditions by capturing the justification, assessing the associated risk, and ensuring the exception is reviewed, approved, and tracked within the GRC framework.

2. Purpose of Policy Exception?

Allows users to request documented exceptions when they cannot comply with a policy.
Ensures exceptions are reviewed and approved to maintain controlled compliance.
Helps identify and manage risks associated with policy deviations.
Promotes accountability by requiring justification and transparency.

3. Roles Required

Role Name	Description
sn_grc.business_user	A GRC role for users who actively work on risk, compliance, and policy tasks. They can create/update issues, take/approve assessments, respond to evidence requests, and request/approve policy exceptions. Intended for broader participation in GRC processes.
sn_grc.business_user_lite	A limited-scope role for business stakeholders needing basic GRC interaction. They can report/read issues, respond to assigned tasks (attestations, evidence, questionnaires), and view/submit policy exceptions, but with fewer permissions than full business_user.

4. Process Flow Diagram for Policy Exception

5. Policy Exception – FORM View

Navigate to All > Policies and Compliance > Policies Exceptions > My policy Exceptions > New

Sections

6. Policy Exception All Fields

Field	Description
Number	Unique identification number.
Requester	Person requesting the policy exception, usually the control owner.
Approval group	Group that has the compliance manager role. You cannot edit the approval group if the policy exception reaches Review state. If you do not provide an approval group, then the field defaults to compliance manager. Compliance manager is the default role if the policy exception is raised from any upstream application that is integrated with GRC.
Approver	User from the approval group. If the exception policy moves to the Analyze State, then you must select an approver.
State	State of the policy exception within the approval workflow.
Substate	Approval substate of the policy exception within the approval workflow.
Priority	Approval priority of this policy exception
Watch list	Users that are notified when the request is updated.
Name	Unique name of the policy exception.
Reason	Reason for requesting the policy exception. The requester can change the reason until the policy exception is approved.
Justification	Statement of explanation for the policy exception. Justification is also displayed in the additional comments.
Source type	Type of policy exception that you want to create. The options are:
Control objective	Control objective associated with this policy exception.
Issue	Issue associated with this policy exception.
Target record	Target record table on which the policy exception is applied. This table is also referenced in the Policy eception target table field of the Policy Exception Integration Registry Form.
Risk rating	Select the risk rating as determined by the risk assessment performed on the policy exception.
Risk description	Description of the risk as performed by the risk manager during risk assessment.
Analysis of risk and impact	Details on the likelihood of this risk occurring and residual impacts of this risk on the policy exception.
Risk mitigation plan	The risk mitigation plan for this policy exception.
Valid from	Day on which the policy exception begins.
Valid to	Day on which the policy exception ends.
Duration	Number of days between the Valid From and Valid to dates.
Approved extensions	Number of times extensions have been requested so far and have been approved.
Remaining extensions	Number of times extensions can be requested in future.
Created	Date on which the policy exception was requested.
Date approved	Date on which the request was approved.
Extension date	Requested extension date, which is after the Valid to date.
Extension reason	Reason for extension.
Original valid to	Date until which the policy exception was originally requested and approved. The original Valid to date is populated only when the extension is approved.
Work Notes	Work notes can be used by exception reviewers and approvers to share Information about the exception.
Additional comments	These comments are used by the reviewer to communicate additional information to the exception requester.

7. Policy Exception States and its Lifecycle

7.1. How to request Policy Exception

Fill all the required fields

Submit the Request

7.2. States of Policy Exception

New

When creating new policy exception from Native UI then state is NEW
An exception request is created because a user, team, or system cannot meet a specific policy requirement.
Person involved in this state is the Requestor (business user, system owner, or application owner).
Goal is to document the need for the exception, including justification, scope, risk, and proposed compensating controls.

Provide all the mandatory information and save the record then , once request gets created then state changs from New to Analyze

2. Analyze

When Policy exception record is created then it is in Analyze state.
The exception is being evaluated for risk, impact, and validity to determine whether it should move forward.
Persons involved in this state are Risk team, Compliance/GRC analysts, and sometimes the Policy Owner.
Goal is to review the justification, assess risks, determine required compensating controls, and confirm whether the request is reasonable.

Provide Approver and Risk rating then click on ‘Request Compliance Review’ then state will change from Analyze to Review

3. Review

Detailed review of the refined exception request after analysis is complete.
Persons involved in this state are, reviewers such as department leads, technical SMEs, or policy owners.
Goal is to validate accuracy, check completeness, ensure risks are understood, and confirm alignment with business/legal requirements.

Click on UI action ‘Request Additional Approval’ but make sure your requester has manager assigned then state will change from Review to Awaiting Approval.

4. Awaiting Approval

The exception has passed review and is now pending formal approval.
Designated Approvers such as senior leadership, risk committees, compliance managers, or policy owners are responsible in this state
Goal is to obtain official authorization and document the approval in an auditable manner.

Impersonate to the manager of Approver, and approve the request then state will change from Awaiting Approval to approved.

5. Approved

The exception is formally granted for a defined duration, with required compensating controls in place.
Goal is to allow temporary deviation from the policy while maintaining acceptable risk levels and tracking expiration.

When we click on ‘Close Exception’ UI action

6. Closed

The exception is no longer active either it expired, was resolved, or the underlying issue was fixed.
Goal is to end the exception and ensure compliance is restored. Documentation is preserved for audit history.

7.3. Policy Exception Extension

A Request Extension is a formal request to extend the validity or expiration date of an existing approved policy exception.
It is used when the original issue or limitation preventing compliance has not yet been resolved by the time the exception is nearing its expiration.

7.3.1. Purpose

To ensure continued, documented permission to remain temporarily out of compliance with a policy.
To provide leadership and compliance teams with updated justification, risk assessment, and timelines.
To maintain auditability and avoid unauthorized or expired exceptions.
To confirm the organization still accepts the associated risk for the extended period.

7.3.2. Procedure of Policy Exception Extension

Click on Request Extension and Click on Request , then sub-state of the policy exception record changes to Under Review

When exception request closed then substate will change from Under Review to Expired.

The post Policy Exception in GRC first appeared on LogiUpSkill.

Client Script In Service-now

Shubham Kumbhar — Wed, 26 Nov 2025 07:00:29 +0000

<h2>Client Scripts in ServiceNow – Fundamentals Explained</h2> <h3>1. Alert Full Name of Logged-in User</h3><pre><code>function onLoad() { var p = g_user.getFullName(); alert(‘This is my first client Script = ‘ + p);}</code></pre> <h3>2. Alert If the Record Is New or Not</h3><pre><code>function onLoad() { if (g_form.isNewRecord()) { alert(‘This is new Record’); } else { alert(‘This is not a new record’); }}</code></pre> <h3>3. Use of Different APIs</h3><pre><code>function onLoad() { g_form.setReadOnly(‘u_email’, true); g_form.setValue(‘u_description’, ‘hiiiiiii’); g_form.clearOptions(‘u_category’); g_form.getLabelOf(‘u_number’); g_form.addInfoMessage(‘hi’); g_form.setMandatory(‘u_first_name’, true); g_form.setMandatory(‘u_last_name’, true); if (g_user.hasRole(‘admin’)) { g_form.removeOption(‘u_state’, ‘Maharashtra’); }}</code></pre> <h3>4. Show Field After Record Creation (Hide in New Record)</h3><pre><code>function onLoad() { if (g_form.isNewRecord()) { g_form.setVisible(“u_convert_to”, false); } else { g_form.setVisible(“u_convert_to”, true); }}</code></pre> <h3>5. Populate Email & Short Description When Assigned To Changes</h3><pre><code>function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === ”) { return; } var p = g_form.getReference(“u_assigned_to”).email; g_form.setValue(“u_email”, p); g_form.setMandatory(“u_first_name”, true); g_form.setValue(“u_short_description”, ‘This is :’ + g_user.getFullName());}</code></pre> <h3>6. Populate User’s First Name in Short Description</h3><pre><code>function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === ”) { return; } var name = g_form.getReference(“u_assigned_to”); g_form.setValue(“u_short_description”, ‘This is ‘ + name.first_name); alert(newValue); alert(oldValue);}</code></pre> <h3>7. Confirm Details Before Form Submit</h3><pre><code>function onSubmit() { var a = g_form.getValue(“u_first_name”); var b = g_form.getValue(“u_last_name”); var con = confirm( ‘You Entered below details -\n’ + ‘The first name is: ‘ + a + ‘\n’ + ‘The last name is: ‘ + b + ‘\n’ + ‘Do you confirm the details?’ ); if (con == true) { return; } else { return false; }}</code></pre> Client Scripts in ServiceNow – Fundamentals Explained 1. Alert Full Name of Logged-in User function onLoad() { var p = g_user.getFullName(); alert('This is my first client Script = ' + p); } 2. Alert If the Record Is New or Not function onLoad() { if (g_form.isNewRecord()) { alert('This is new Record'); } else { alert('This is not a new record'); } } 3. Use of Different APIs function onLoad() { g_form.setReadOnly('u_email', true); g_form.setValue('u_description', 'hiiiiiii'); g_form.clearOptions('u_category'); g_form.getLabelOf('u_number'); g_form.addInfoMessage('hi'); g_form.setMandatory('u_first_name', true); g_form.setMandatory('u_last_name', true); if (g_user.hasRole('admin')) { g_form.removeOption('u_state', 'Maharashtra'); } } 4. Show Field After Record Creation (Hide in New Record) function onLoad() { if (g_form.isNewRecord()) { g_form.setVisible("u_convert_to", false); } else { g_form.setVisible("u_convert_to", true); } } 5. Populate Email & Short Description When Assigned To Changes function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === '') { return; } var p = g_form.getReference("u_assigned_to").email; g_form.setValue("u_email", p); g_form.setMandatory("u_first_name", true); g_form.setValue("u_short_description", 'This is :' + g_user.getFullName()); } 6. Populate User’s First Name in Short Description function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === '') { return; } var name = g_form.getReference("u_assigned_to"); g_form.setValue("u_short_description", 'This is ' + name.first_name); alert(newValue); alert(oldValue); } 7. Confirm Details Before Form Submit function onSubmit() { var a = g_form.getValue("u_first_name"); var b = g_form.getValue("u_last_name"); var con = confirm( 'You Entered below details -n' + 'The first name is: ' + a + 'n' + 'The last name is: ' + b + 'n' + 'Do you confirm the details?' ); if (con == true) { return; } else { return false; } }

The post Client Script In Service-now first appeared on LogiUpSkill.