When we add the above and run it in a background script, we’ll see that our change request records have now been updated.
I also played around with the above by adding gr.forceUpdate(), along with gr.update() Ĭonsider adding the object.forceUpdate() along with the object.update() if it does not work for you as highlighted above. The only difference is the gr.autoSysFields(false) being added to the query.
Gr.work_notes = “Adding a worknote to closed changes” gr.autoSysFields(false) Īs you can see here, we are creating a pretty simple and normal GlideRecord Query. Var gr = new GlideRecord(“change_request”) To do that, we’ll create a background script. Let’s add a worknote to all of these records, but don’t modify the “Updated” or “Updated By” fields. Here are the 10 out of box Change request records that are closed. So in an attempt to “sneak” into the record, without the system tagging any system fields and just updating the field(s) you want – you can just add one line to your GlideRecord Query. Because you’re username is going to be updated on all of the closed Change Request records, overwriting the actual user (and time of closure) that actually occurred. If you were to just write a simple background script to add a work note, that would get the “job done”, but you would be creating a poor user experience. The Change Manager wants to add a worknote to all closed Change Request records.Īs a ServiceNow Admin, when we consider a bulk update, we should consider the impact that this will have on our end users.
#Lightwright 6 how to add worknotesh update#
Don’t Update System Fieldsįor better understand this GlideRecord Method, let’s consider the following use case. Keep in mind that this is a server side operation and can only be used in a business rule or background script – it’s not possible to implement this feature on the client. When you want to leave system fields alone and you’re running a bulk update via background script – consider using toSysFields(false).
0 kommentar(er)
