var gr = new GlideRecord('incident'); gr.orderByDesc('sys_created_on'); //gr.setLimit(10); gr.chooseWindow(4,5);// 4-first row and 5- last row gr.query(); while(gr.next()){ gs.print(gr.number); // create problem record here }

---

0 Helpfuls

create a Workflow that will be associated with your catalog item. This workflow should define the logic for generating 10 catalog tasks simultaneously.

---

0 Helpfuls

You can achieve this by modifying the OOB change workflow

---

0 Helpfuls

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