How to Get a Parent's Data to a New Record using a UI List Action

[Joshua Cassity]

We've run into an issue where we have a custom parent request form that has a related list and we'd like to add an action on that related list to create a new related record to this parent but copy over some of the parent's data over to the newly created record.

Ex. I have a Telecommunications Request Form that has basic data on it (Requested By, Telecommunication Closet Number, Type of Request, Service Code) and a related listing of Circuits that is derived based upon the Telecommunication's Closet Number.

I also have a Circuit table that has circuit specific data on it (Circuit Name, Power Type, Grid Name and also has a spot for the Telecommunication Closet Number for which it lives).

So in our case, Telecommunication Closet 45 already has three network circuits in it but I'd like to add a new circuit by letting the user press the New button on the related listing.

The problem is that when we create this new List UI Action, we can't seem to get the Closer # from the parent Request to put into the newly created child Circuit because we can't figure out how to collect and push that data to the new record. We believe this is because the action actually resides on the child Circuit form so anytime we do a 'current.' action it's not on the correct table and we end up getting this error message:

Can anyone provide us with a solution to actually be able to pull the parent's data into the child record using a List UI Action while allowing the user to input any other data into the new child record before it's saved to the database?

Any assistance would be greatly appreciated. Here is a copy of our logic so far:

// Open a new Glide Record in the circuit Table

var circuit = new GlideRecord('u_circuit');

circuit.initialize();

circuit.u_site_id = current.u_site_id; <<< Here's the Issue!

// Set the Form Fields Based Upon the NetTN Request Entered Data

circuit.insert();

action.setRedirectURL(circuit);

[Joshua Cassity]

I think we have the solution now with your guidance:

function insertNewCircuit() {

  document.location = 'u_circuit.do?sys_id=-1&sysparm_query=u_nettn_request=' + g_form.getUniqueValue('sys_id') + '^u_site_id=' + g_form.getValue('u_site_id');

}

So just to get some background on how this works because this seems really powerful to me as a new developer who could have NEVER figured this out on his own.

Am I reading how this is operating correctly? We're opening a new circuit record form with the 'u_circuit.do?sys_id=-1' url command and we're querying the Parent Request Form and populating the new record based upon those values with the following two pieces of the remaining code:

Targeting the NetTN Request Field on the Circuit form and populating it with the parent request's system id value.

sysparm_query=u_nettn_request=' + g_form.getUniqueValue('sys_id')

AND (^)

Targeting the Site ID on the Circuit form and populating with the parent's site id value.

^u_site_id=' + g_form.getValue('u_site_id');

Is that correct? Also what is the document.location command doing?

Sorry for all the questions. I just want to be sure that I'm really understanding what's going on here in case we need to leverage it again for other things. On a side note, this is very appreciated and very slick.   We'll do some testing and be sure we are getting the behavior we want but I think you nailed it.

[Joe McCarty1]

Setting the sys_id=-1 tells the system we want a new record.

The ^ is the AND operator on our encoded queries which is the format of the sysparm_query field

It's not doing anything so clever as querying the parent record.   Whenever a new record form is opened, the sysparm_query field is used to seed any data on the form.   Which is why when you click on a filtered list/related list it inherits all the values of your filter.

When building the link we just use the standard client side API for g_form to get the values we are interested in (they have to be on the form or potentially passed in g_scratchpad).

document.location is just standard browser javascript for redirecting a page.

So we build the filter as a template using the client side API and make a client redirect request to the new record using that template.   It's all done on the client side without going back to the server.

If you think this resolves your issue go ahead and mark it as answered.

[Joshua Cassity]

Are there any docs we can look at to further explore this api or behavior?

We've only been live for a few months and this has been a real learning curve for us. We're doing some testing and when it tests out I'll definitely mark this as correct.

Very cool.

Thanks Joe.

[Joe McCarty1]

For the sysparm_query, there is an exceedingly brief description here (Navigating by URL - ServiceNow Wiki ) and this is slightly more verbose (Populating Default Values with a URL or Module - ServiceNow Guru )

GlideForm is pretty thoroughly documented here (https://developer.servicenow.com/app.do#!/api_doc?v=helsinki&id=c_GlideFormAPI   )

UI Actions can be on the client or server, or in some cases both! (Client & Server Code in One UI Action - ServiceNow Guru ).   In our case it was just simple client side ui action.   UI Action details can be found here (UI actions )

[Joshua Cassity]

How would we hide the OOTB Global New button just for these related lists?

~ J ~