Carlos Camacho Junior

        Simon Hendery  shared his thoughts  about having a matching tool when Golden Ticket's owners could donate it in case they don't have someone in mind.       Simon asked the developer community for help and when I read it I immediately thought...  YES!       When I said to Simon that I've developed the App, it was like throwing a rock into a river. I could see a ripple moving away from where the rock landed:       1) Just a few days online and the tool found the first match. Cheers Simon! The idea was yours!       2) Jace Benson posted about it spreading the idea.        3) Allen Andreas asked about the statistics and the s ection  Our Numbers  w as implemented.        4) The tool was featured in JaceNow Youtube channel. Thanks Jace!        Analysing the solution's infrastructure       1) The User Interface       Both the donor and the learner access the User Interface where they can provide name, email and a message.       For data integrity reasons, we don't

Do you know about the Related List that displays people who can approve or reject a document? Recently a scenario came up where the developer needed to prevent the employee who created a record from approving that document. It wasn't common because usually the operational level creates the document while a manager approves it. Leaving this question of personas aside and focusing on the problem, what would be a possible solution? The first workaround that came to my mind was to hide the Approval list if the user who registered was viewing his own record. A workaround is not the ultimate solution. Just a palliative fix while we find time to think about the ideal one. The action plan 1) Every record has a field called sys_created_by; 2) On the front-end (client side) we have access to an API called Glide User that has some information about the logged in user. Among them is the name in the userName property. What if we create a

        The Choice table is used internally by the platform and depending on the payload of an operation, for performance reasons the platform can decide that it is better to drop the table and insert all the values instead of perform updates on specific records.       When we insert a new record in a table, a new sys_id is generated. If we have the Choice table as a reference to provide choices for a particular field in our table, these choices will be lost every time the platform decides to recreate the Choice table.       A simple way to avoid this problem is to create a field of  type Choice  which indirectly uses the Choice table but it is the right way, or we can create our own table to maintain the Application choices.       Recently I received the mission to do exactly this: create a private choice table for an Application.     The problem       A long time ago, the platform allowed a developer to choose the Choice table as a reference.       As a consequence, old custom applic

     The Choice table - which has the internal name sys_choice - is used internally by the ServiceNow platform every time we create a field of type Choice and specify the available choices.        Points to remember when creating a choice       Always use only lowercase and underscores to form the Column name.         The Column label is what appears for the end user so you are free to use uppercase and spaces.       Use the same logic to create a choice. The value is internal and should contain only lowercase and underscores. The Label is what appears for the end user so you are free to use uppercase and spaces.        What you should never do       Never specify the Choice table as a reference in a Reference field. For example:       A reference field stores the sys_id of the corresponding record in the reference table. Since the Choice table is a core internal table, its behaviour is different from custom tables and the sys_ids can change.       The problem: when a sys_id in a refer

      Use Case: When submitting a Record Producer, a date field can’t be in the past. How to accomplish this?       We can create a Catalog Client Script.       1) What is the trigger?       The script will run when the date field value changed.       2) What do we need to confirm?       We need to check if the date provided is in the future.       3) What if the date is not in the future?       If the date is not in the future, then we show an error message to inform that the date cannot be in the past.        Step by step process       1) Create a Record Producer (RP) and define the Catalog and Category so it will be visible in a Service Portal       2) Create a variable in your RP. In this example, the variable will have this configuration:        Type:  Date        Question:  Project Deadline        Name:  project_deadline        Mandatory:  Yes (checked)       3) Create a Catalog Client Script in your RP to check if the project_deadline value changed. If the date is in the past, s

        There are scenarios when instead of updating a record, a script creates a new one. If it is the correct logic behind the Use Case it’s fine, but as good consultants we need to make sure it doesn’t happen if the client just want to perform updates.       1.1 Use Case 1: The get() method       In the script below we may think that the lines 9 to 11 are setting values to an existing record so in line 12 we’re just updating the record.       In the right panel we can see that, as the record wasn’t found, a new record was created in the sys_user table!       To guarantee that we are updating a record, it is important to wrap the get() method in an if statement like this:       If the record to be updated does not exist, the  else  statement is warning us about that fact and we’re not creating any unnecessary record.       1.2 Use Case 2: Loading data       Use the coalesce fields to locate records when loading data.       The coalesce fields will inform the platform how a record can