How to set current.assigned_to in script without using sys_id

Eric K3 · ‎09-15-2016

I know how to set the assignment_group and assigned_to using sys_id:

current.assigned_to = "f2f86bb36f18c2004523da0cbb3ee467";

How can I set the assigned_to by using users' names, "Jacob McGillicutty", since the sys_id is bad for readability?

randrews · ‎09-15-2016

i am a little confused here... why are we worried about readability in the script..

using the sys_id ensures that the CORRECT John Smith is assigned to the record instead of just A john smith... the history of the ticket should show the friendly name and be useful for review.. where are you getting the sid that you want it to show the username instead?

if i am doing this in a script.. where i am assigning a bunch of records to one person <not a good idea in a scheduled script if they are going to leave btw> what I would do is define the user as a variable with a value of the sid... so for example...

var John_Smith = 'f2f86bb36f18c2004523da0cbb3ee467' ;

then set the assigned to as john_smith .. or add a comment to the line you have...

current.assigned_to = 'f2f86bb36f18c2004523da0cbb3ee467'; //John Smith

if this is going to be code called moving on and not in a one time script... i would create a system property and put the sid in the system property.. that way if he leaves the company you just change that property and don't have to go find scripts and modify them.

View solution in original post

BALAJI40 · ‎09-15-2016

Hi Andrew,

By assigning reference filed to a sys_id is hard coding the script. SO that's why generally we can set the display values.

But this one good explanation.

if this is going to be code called moving on and not in a one time script... i would create a system property and put the sid in the system property.. that way if he leaves the company you just change that property and don't have to go find scripts and modify them.

randrews · ‎09-15-2016

the problem is that display values are not unique by their very nature... if you hire a second person with the same display name you will end up with the system assigning the tickets to the first one it finds.. this is why sid is the best tool for this job... it IS unique...

display name should ONLY be used in a case where you can verify you will never have the same display name twice.

if you are asking how to create a property.. this wiki has a pretty good explanation of creating a property and a page for it to live on..

http://wiki.servicenow.com/index.php?title=Adding_a_Property#gsc.tab=0

and this talks about why and how a little more and how to get the property using gs.getProperty()

http://wiki.servicenow.com/index.php?title=System_Properties_Best_Practices#gsc.tab=0

jagarnathn · ‎09-15-2016

If email id's are unique, then i need to opt very simple thing.

var email_id="jhon@example.com";

var gr= new GlideRecord('sys_user');

gr.get(email_id);

current.assigned_to=gr.sys_id;

No need to create a property here.

Regards,

Jagarnath

randrews · ‎09-15-2016

if that works for your system go for it... I am paranoid about this type thing because we were TOLD email addresses are unique.. then they decided to change the policy and start reusing email address's after an employee has been inactive for 90 days

which had some.. undesirable affects...

as far as no need for a property you should never in a script lock something down to a person, or any other field that changes frequently.. people will get hired, fired, and leave on their own... if you set this as a property <say named auto assign for X type of records> and store it on a property page when the person leaves the company you can just open that property update it and it is fixed on the fly... if you hard code the user in the code and they leave than it is going to be assigning tickets to an inactive user till your next release <bad> or you are going to have to change the script in prod <bad> or do an emergency change <bad>

the system property just gives you the ability to change that person without having to touch the script.