PROJECT Golden Ticket matching tool

 

      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 section Our Numbers was 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 allow a user to register the same e-mail twice.
      Fully responsive, the form can be accessed by any device. We also use SSL (Secure Sockets Layer) to encrypt the information between the User Interface and our website.


      2) The Database layer
      
      When the data is submitted, it is stored in a table. We have a flag to identify if the user was already matched or not.


      3) Scheduled Job

      We've created a scheduled job that runs in a daily basis.
      The job query the database and verify the amount of donors and learners who contains the flag "not matched".
      If we identify that there are one or more donors and learners not matched, the service match them preparing a record in a new table.
      The match rule is a simple FIFO (First In, First Out) algorithm. When the form is submitted by the user, we store the date and time. Our algorithm order the records by date and time and relates the first (oldest) available donor with the first (oldest) available learner. These two records are then flagged as "matched" and the algorithm keep looking for the next pair of records (donor x learner) available.


      4) Sending the E-mail

      We've created a second scheduled job that now can query a list of prepared matches. If any, this service sends an email to each match informing the donor and learner contact information so they can connect and proceed with the donation process.


      Thank you.


Screenshots:




 

 

 

  






Comments

Post a Comment

Popular posts from this blog

Hacktoberfest

Image
I just completed the #ServiceNowHacktoberfest by having 4 contributions accepted! - Service Portal is a single place for everyone to access information, services and different applications. For my first contribution   (1068)  I shared a use case to get a parameter from the URL and use it into an Ajax call, recovering information from the database to show within the User Interface. - For my second pull request   (1069) I talked about best practices, explaining how to safely update a record. If we're not cautious with this kind of programming we can accidentally insert records instead of updating them. - For my third contribution   (1085)  I explained how to validate a field provided within a Catalog Item/Record Producer so that the date can't be in the past.  - The last one   (1093) was about fixing a direct reference to the Choice table. This is an internal table and it is not best practice to reference that table directly when you are crea...
Read more

VIDEO How to fix a reference to the Choice [sys_choice] table

Image
        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.    ...
Read more

How to hide a Related List

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 ...
Read more