My go to On Load Client Script - Fast, efficient, and works for ALL profiles; Hides everything except initial fields

My go to On Load Client Script - Fast, efficient, and works for ALL profiles; Hides everything except initial fields

This is my on Load client script that I use for Create pages. I use a modified version for Edit and Display pages which you can create yourself using the same basic structure that I will give you below. First up, the script. Below that will be an explanation of how it works.

  1. const subformAPINames = ['Deal_Quotes', 'Assets']; // Declare all your visible subform API names
  2. const formAPINames = Object.keys(ZDK.Page.getForm().getValues()); // Get all API names visible on the page
  3. const fieldAPINames = formAPINames.filter(x => !subformAPINames.includes(x)); // Remove the Subform API names from the array above, creating an array of field API names.
  4. const visibleFields = [
  5.     "Account_Name", "Closing_Date", "Contact_Name", "Current_Task", "Customer_Reference",
  6.     "Deal_Name", "Description",
  7.     "Expected_Conversion", "Info_Required",
  8.     "Next_Project_Follow_Up", "Opened_Date",
  9.     "Product_Range", "Source", "Stage", "Type_2",'CCL','Asset'
  10. ];
  11. const readOnlyFields = ['Last_Follow_Up','Next_Project_Follow_Up','Opened_Date','Deal_Name','Current_Task','Stage']; // Declare all fields required to be read only on page load
  12. const mandatoryFields = ['Account_Name','Type_2','Product_Range','Description']; // Declare all fields required to be mandatory
  13. fieldAPINames.forEach(f => { if (!visibleFields.includes(f)) { ZDK.Page.getField(f).setVisibility(false); } }); // Hides all fields except subforms
  14. readOnlyFields.forEach(f => { if (fieldAPINames.includes(f)) { ZDK.Page.getField(f).setReadOnly(true) } }); // Sets all read only fields as such
  15. mandatoryFields.forEach(f => { if (fieldAPINames.includes(f)) { ZDK.Page.getField(f).setMandatory(true) } }); // Sets all read onlymandatory fields as such
  16. subformAPINames.forEach(s => (Object.keys(ZDK.Page.getSubform(s).getRow(0).getValues()).forEach(f => ZDK.Page.getSubform(s).getField(f).setVisibility(false)))); // Hides all subform fields
So, how does this work?

This script works with all profiles with all field permissions. You don't need to worry about creating separate scripts or separate blocks for different profiles.
  1. First we declare all the subform API names in the module
  2. Next, we grab all the API names visible to the logged in user on page Load.
    1. This doesn't distinguish the type of field, which is why we need to declare the subform API names manually
  3. Now we remove the subform field API names from step 2. This gives us 2 lists, or arrays. 1 array with just field API Names, and 1 array with just subform API Names.
  4. Next, we're going to have 3 arrays. Visible Fields, Mandatory Fields, Read Only Fields. Within these arrays, we're going to list ALL the fields that we want in each category
    1. Again, it doesn't matter if the logged in user has access to the field or not.
  5. Now, the loops begin:
    1. For each field in the fieldAPINames array, if the field name is NOT in the list of visible fields, hide it.
    2. For each field in Mandatory fields, if the field name IS found in the fieldAPINames array, make it mandatory
    3. For each field in the Read Only Array, if the field name IS found in the fieldAPINames array, make it read only
  6. Before we go on to the subforms, the above loops only work on the list of fields available to the user. If we were to make a field "Profit" read only, but it's not available to the particular user, "Profit" won't be in fieldAPINames, therefore the script won't try to make it read only... the script doesn't know "Profit" exists.
    1. If we were to use ZDK.Page.getField("Profit").setvisibility(false) and the user does not have access to the field, the script would fail. This script is completely immune to such a situation.
  7. Next, the subforms. We don't actually get the subform field names when we get all field API names. We get the subform API name, but not the individual subform field API Names. However, each subform is always populated with 1 row, even if that row is completely empty, it doesn't matter.
    1. The last line cycles through each subform. If the subform was found on the page, it executes the next nested loop.
    2. For each visible subform, we get the first row and strip out all the field API names.
    3. Now we have the subform field API names, we hide all the ones we don't want visible. In my case, I don't want any subform fields visible yet, so I just hide all of them

And that's it. One final note. I specify the visible fields rather than the hidden fields since there's usually less visible fields, so it makes sense to focus on the shorter list of fields that should be visible rather than the list of fields that should be hidden. It also means that any new fields are automatically hidden without having to alter the script.

In my next post, I will share my script structure of an On Page Change event.

    • Sticky Posts

    • Kaizen #198: Using Client Script for Custom Validation in Blueprint

      Nearing 200th Kaizen Post – 1 More to the Big Two-Oh-Oh! Do you have any questions, suggestions, or topics you would like us to cover in future posts? Your insights and suggestions help us shape future content and make this series better for everyone.

    • Kaizen #226: Using ZRC in Client Script

      Hello everyone! Welcome to another week of Kaizen. In today's post, lets see what is ZRC (Zoho Request Client) and how we can use ZRC methods in Client Script to get inputs from a Salesperson and update the Lead status with a single button click. In this

    • Kaizen #222 - Client Script Support for Notes Related List

      Hello everyone! Welcome to another week of Kaizen. The final Kaizen post of the year 2025 is here! With the new Client Script support for the Notes Related List, you can validate, enrich, and manage notes across modules. In this post, we’ll explore how

    • Kaizen #217 - Actions APIs : Tasks

      Welcome to another week of Kaizen! In last week's post we discussed Email Notifications APIs which act as the link between your Workflow automations and you. We have discussed how Zylker Cloud Services uses Email Notifications API in their custom dashboard.

    • Kaizen #216 - Actions APIs : Email Notifications

      Welcome to another week of Kaizen! For the last three weeks, we have been discussing Zylker's workflows. We successfully updated a dormant workflow, built a new one from the ground up and more. But our work is not finished—these automated processes are