You can handle errors based on response status code. You get status code in series 400 if there is any error e.g. 1. 402 is error code for incorrect user details 2. 404 is either the URL you have configured doesn't exist at all, or the resource you are trying to access doesn't exist.

---

0 Helpfuls

There's also ERROR 401. It's for Basic authorization error.

---

0 Helpfuls

Blackout windows specify times during which normal change activity should not be scheduled. Maintenance windows specify times during which change requests should be scheduled.

---

0 Helpfuls

Yes, user will be granted access.

---

0 Helpfuls

Ypu can use below script: function onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === '') { return; } //if(newValue != ''){ var caller = g_form.getReference('caller_id'); g_form.setValue('u_email', caller.email); //} }

---

0 Helpfuls

getReference is not the best practice to get data from server side to client side. we should be using GlideAjax to fetch data from server side to client side. if you want to use getReference then you can use this code using on change client script : unction onChange(control, oldValue, newValue, isLoading, isTemplate) { if (isLoading || newValue === '') { return; } //Type appropriate comment here, and begin script below var user = g_form.getreference('requested_for', function(user) {// map the correct field g_form.setValue('u_email', user.email.toString());// map the correct field }); } if you want to auto-populate the email id based on logged-in user the please line in the default value of the email id field : javascript: gs.getuser().getRecord().getValue('email); Using GlideAjax : Create a new client callable script include with following function var UserDetails = Class.create(); UserDetails.prototype = Object.extendsObject(global.AbstractAjaxProcessor, { getUserInfo: function() { var details = {}; var userId = this.getParameter('sysparm_user_id'); var userObj = new GlideRecord('sys_user'); userObj.addQuery('sys_id', userId); userObj.query(); if (userObj.next()) { details.email= userObj.email_id.toString(); } return JSON.stringify(details); }, type: 'UserDetails' }); Create a new catalog client script on the record producer/request form function onChange(control, oldValue, newValue, isLoading) { if (isLoading || newValue == '') { return; } var ajax = new GlideAjax('UserDetails'); ajax.addParam('sysparm_name', 'getUserInfo'); ajax.addParam('sysparm_user_id', g_form.getValue('employee_name')); // change variable name here ajax.getXML(doSomething); function doSomething(response) { var answer = response.responseXML.documentElement.getAttribute("answer"); var answers = JSON.parse(answer); g_form.setValue('var_email_id', answers.email.toString()); // change variable name here } }

---

2 Helpfuls

Do we need an additional field of 'Email' to auto-populate the email address of user?

---

0 Helpfuls

no

---

0 Helpfuls

If you would like to show email address of user on incident form then we can dot walk to user reference field and bring email field on task form. This way, we don't need to write any script to populate email address when user is changed.

---

1 Helpfuls

We can use reference qualifier to restrict certain locations based on users location.

---

0 Helpfuls

In order to restrict for specific location, We can create usercriteria which will have location as mentioned under 'Not Available For' tab in service catalog

---

0 Helpfuls

I believe Major Incidents have their own separate work flows and notifications outside of standard incident management. With most incidents of any priority, the incident management team is usually equipped to find a solution and additional approval is usually not required. Even P1 incidents go throught the same workflow of a P2 or P3 incident. Major incidents involve notifications that get sent outside of the incident management team and have unique workflows that are more complex or require further approval in order to resolve the issue. I'm sure other poeple can describe this better, but in short, Major Incident Management is its own separate entity.

---

1 Helpfuls

IF we have complex logic which requires lot of scripting then we should go with Workflow, in all other cases we can go with Flow Designer.

---

0 Helpfuls

Feature/Aspect Flow Designer Workflow Trigger Types Multiple trigger types like Scheduled, Application, and Record triggers. Triggers on Record creation or when specific conditions are met. Integration Capabilities Provides numerous spokes for integrating ServiceNow with external systems using Integration Hub with low code. No built-in support for Integration Hub or easy external system integration. Rollback Feature No rollback action available. Includes a rollback activity to revert to an earlier activity in the workflow. Scripting Limited scripting capabilities; cannot easily handle complex scripting. Supports complex scripting with the ability to use the current object for dot-walking. SLA Timer Support Cannot be used for requirements related to SLA timers. Can be used for SLA timer-related requirements.

---

0 Helpfuls

When configuring the out-of-the-box (OOB) ServiceNow Incident Management application for end users, there are several key configurations you should consider to ensure it meets your organization's needs. Here are the essential configuration steps: User Roles and Permissions: Define and assign appropriate roles to end users, such as "Incident Caller" or "End User." These roles should have the necessary permissions to create, view, and update incidents. Service Catalog Configuration: If incidents can be reported through a service catalog, configure catalog items for incident creation. Define the variables and information you want end users to provide when reporting incidents. Incident Categories and Subcategories: Set up incident categories and subcategories to classify incidents effectively. This helps in routing incidents to the correct assignment groups and analyzing incident data. Assignment Groups: Define assignment groups responsible for handling different types of incidents. Configure automatic assignment rules based on incident category, subcategory, or other criteria to ensure incidents are routed to the appropriate teams. Service Level Agreements (SLAs): Set up SLAs to define response and resolution time targets for incidents. Associate SLAs with incident categories or priorities to ensure that incidents are prioritized correctly. Incident States and Workflow: Configure incident states and workflows to match your organization's incident management process. Define the stages an incident goes through from creation to closure and customize the workflow to meet your needs. Notifications and Email Templates: Configure notification rules to keep end users informed about the progress of their incidents. Create and customize email templates for incident notifications to ensure clear communication. Knowledge Base Integration: Integrate the incident management application with the knowledge base to provide end users with access to self-service solutions and knowledge articles that can help them resolve common issues. Incident Numbering and Prefixes: Customize incident numbering and prefixes to align with your organization's numbering conventions and to make it easier to identify and track incidents. Incident Templates: Create incident templates to simplify the incident reporting process for end users. These templates can pre-fill incident fields with common information. Client Scripts and UI Policies: Implement client scripts and UI policies to enhance the user experience by adding client-side validation and dynamic behavior to incident forms. Service Portal Configuration (Optional): If you're using ServiceNow's Service Portal, configure incident-related widgets and forms to provide an intuitive and user-friendly interface for end users. Access Control Lists (ACLs): Define ACLs to control access to incident records and ensure data security and privacy. Reporting and Dashboards: Set up incident-related reports and dashboards to provide end users with visibility into incident trends and performance metrics. Testing and Training: Thoroughly test the configuration to ensure it meets end-user needs and aligns with your incident management processes. Provide training to end users on how to use the system effectively. Documentation: Create user guides and documentation to help end users navigate the incident management application and understand their roles and responsibilities.

---

1 Helpfuls

Thanks Vamsi for such brief explaination

---

0 Helpfuls

Actual elapsed values are calculated on a 24x7 basis. Business elapsed values are calculated based on the schedule specified in the task SLA. The schedule is taken from the SLA definition by default.

---

0 Helpfuls

Actual elapsed time is the total time the SLA has taken from the time SLA start until the SLA completed. Business elapsed time is the total time which is calculated as per Schedule type (Give in SLA form for e.g., 2 business days by 4 pm) and as per time zone. To analyze the exact SLA timing condition, we always see Business elapsed time.

---

0 Helpfuls