Making a "dot-walked" field mandatory in a form

[ctu1]

Hi,

imagine I am in a form an table A and have another table B that is referenced via a field on A. I have customized the form to have fields A1..An on it. I also have A.B1 and A.B2 on it. A.B1 beeing a checkbox. Now I need to achieve that A.B2 is made mandatory if A.B1 is checked. This can not be done via UI Policy and SN support let me know that this is not supported as those fields are "derived". I tried doing this with client script. It does not work with onChange since I can not get at the field A.B1 in the field drop-down. So this was implemented by onSubmit which has the logic, displays a message and refuses to save the record if A.B1 is checked and A.B2 is empty. BUT: This is different behaviour than the rest of the system, as the user gets no visual feedback when checking A.B1 (aka "the little red bar" in front of A.B2). Even if there is a way to set this visual hint via client script, how would I trigger that as I can not get at A.B1 from onChange()? I have tried keeping the (otherwise non-functional) UI Policy as well (which does the visuals part fine) but I don't think this is a "clean" way of doing it.

Any input appreciated. 🙂

[w_bouwer]

Hi Christian,

Derived fields only give information about records that are referenced. It is not common to build logic on those fields. Imagine you would have an excel-file, which worked with several referenced fields from other sheets on your main sheet. Updating the value on your main sheet, will not cause the value to update on the referenced fields.

Now to get back to your question. What happens when there is no referenced record? Does this mean the value still needs to be mandatory? Be sure to capture all available possibilities in your client script.

You can actually manipulate the XML behind fields to allow them to work. When you export a client script from the system, there is an element called 'field' that contains the field being referenced. ServiceNow has a default element creation script that automatically attaches an onChange to every field available on the form. The onChange references a field... which is the 'field' in the element. All active onChange client scripts will be loaded in the browser on load of the record. This means that if we can change the parameter in the client script field, we can create our own onChange fields working on alle elements of your form.

1: Export the client script in xml form
2: Edit the 'field' in the xml, to include the referenced field. On the incident table for instance, when you reference to the knowledge field on the problem, you would edit this field to be problem_id.knowledge (problem_id being the field that is the reference field, knowledge being the fieldname on the problem table). In your case this would be B.B1 (B being the reference field on form A, B1 being the field from the record on B).
3: Import your changed scripts in the client script table
4: Test if it works.

This should give you enough flexibility to build your requirement. Note that some out of the box functionality might not work (like g_form). You can completely capture these things with basic DOM javascript though.

Hope it helped.

Regards,

Wesley

[ctu1]

Hi Wesley,

yes that would probably work. The current issue is concerning catalog tasks so we are quite sure that there is always a reference to the item. But it's a valid point you're making. I never thought about exporting the client script, chaning the XML and getting it back in. That is very clever. However I am not sure what support will say... 😉

[corbettbrasing1]

It is when your client has 50 million task records and you are not allowed to add any fields to any table that extends task.  You are forced to have joined records with a ref field.  

Reason this clients will say this is because of how SNOW flattens the task table is the root of this problem