Run your application review round on Jotform submissions

I want an app my review committee opens during an application round, instead of mailing scoring spreadsheets around and recompiling them by hand. The people using it are committee members and a chair, not operators, so it has to read like a review board rather than a database. Let me pick which Jotform form holds the round using Get User Forms, and remember that choice in settings. Everything else hangs off that one form.

Load applications with Get Form Submissions for the selected form, paging through with offset and limit until every submission is in, and cache them so a few hundred applications do not mean a few hundred slow calls. Two Jotform details matter here and shape the whole app. First, submission answers are keyed by question ID rather than by any human wording, so pull Get Form Questions once per form and join on question ID to get the real question labels and the order the form asks them in. Never show a reviewer a raw field ID. Second, uploaded documents come from Get Form Files, which lists the files for a form, so match those files back to their submission and show each application's attachments on the application itself. Use Get Single Submission when opening one application if you need the freshest copy of its answers.

Scores and everything else the committee produces live in the app's own storage, not in Jotform. Keep an applications table keyed by submission ID holding applicant name, applicant email, review status, the outcome, the rationale, who recorded it, when, whether the applicant email has gone out, and the briefing output with its status and timestamp. Keep a scores table with one row per submission ID plus reviewer email, holding a score per rubric criterion, the weighted total, per criterion notes, an overall comment, and when it was submitted. Keep a criteria table holding the rubric itself as criterion name, description, weight, maximum score and sort order, so the rubric is configurable in the app rather than hard coded. Keep an eligibility rules table holding the rules the briefing assistant checks against. Keep the wording generic throughout, because this same app should suit grant, scholarship, award, vendor RFP and accelerator rounds equally.

The main screen is the review queue. Identify the reviewer by the signed in viewer's email address and default the queue to My queue, meaning applications this reviewer has not scored yet, with tabs for all applications, ones I have scored, and ones already decided. Each row shows applicant name, submitted date, how many reviewers have scored it so far against how many the round requires, the current average score, the completeness flag from the briefing assistant, and the outcome status. Because a round can run to several hundred applications, filtering is load bearing rather than decorative: let me filter by score range, by review status, by outcome, and by reviewer, including a filter for applications a specific reviewer still owes a score on. Let me sort by average score, by spread between reviewers, and by how long an application has been waiting. Do the filtering and paging in the handlers over the cached set rather than pulling everything into the browser.

Opening an application gives a two column detail page, the applicant's materials on the left and the scorecard on the right, so a reviewer can read and score without switching screens. On the left render every question and answer in form order using the labels from Get Form Questions, with the applicant's uploaded documents listed as openable links from Get Form Files, and the briefing summary inline once it exists. On the right render the rubric from the criteria table, one row per criterion with a score control and a notes box, plus an overall comment field, with the weighted total updating live as they score.

Saving a scorecard writes a row to the scores table the first time this reviewer scores this application, and updates their existing row if they are revising, so a reviewer can always change their own score and can never touch anyone else's. Blind scoring is the rule that matters most: until the signed in reviewer has submitted their own scorecard for an application, hide every other reviewer's score, note and comment for it, and hide the running average from the detail page, so nobody anchors on what a colleague already gave. The moment they submit, reveal the full comparison for that application immediately. Make the blind state visible in the interface, so a reviewer understands scores are hidden by design rather than missing.

Give each application a Brief this application button that kicks off a background agent. The agent reads the application's answers and the documents the applicant uploaded, checks them against the eligibility rules held in settings, and writes back a structured summary covering what is being requested, who is asking, how it reads against each eligibility rule, and anything that looks missing or contradictory. It also returns a completeness flag, complete or incomplete with the specific gaps named, which the queue shows as a column so the chair can spot half finished applications early. Save the brief, the flag and the timestamp onto that application's row and show it inline on the detail page, with a running state while the agent works. Make it explicit in the interface that the brief is reading assistance and never a score, and that a reviewer is still expected to read the application.

A consensus view ranks applications by average score across every reviewer who has submitted. For each application show the average, the number of reviewers in so far, the spread between the highest and lowest reviewer, and the per criterion averages so the committee can see whether they disagree on the whole application or on one criterion. Flag any application where the spread crosses a configurable threshold as one to discuss. Show reviewer progress alongside it, listing who is still outstanding and how many applications each reviewer has left, since chasing the reviewer who did not know it was their turn is most of what a chair actually does during a round.

When the committee decides, the chair records the outcome on the application as accept, reject or more information needed, with a rationale, saved to the applications table with who decided and when. Write that outcome back to Jotform with Update Submission so the record in the form matches the decision, updating the decision field on the submission and its status. Note in setup that the form needs a field to hold the outcome for this to land cleanly, and if there is no such field, keep the outcome in the app and say so rather than failing silently.

Once an outcome is recorded, let the chair send the applicant the matching email through Gmail Send a Message, using an accept, reject or more information template that fills in the applicant name and, where useful, a committee summary drawn from the reviewers' notes. Always show the filled in email for review and require approval before it sends, record the sent timestamp on the application, and never send twice for the same application. Alongside that, let the chair post a round status summary to the committee's Slack channel with Send a Message, covering how many applications are in the round, how many are fully scored, how many are still waiting, the current top applications by average score, the ones flagged for disagreement, and which reviewers are outstanding. Let me pick the destination channel in settings using List Channels.

Keep a configurable list of chair email addresses. Everyone on the committee can see the outcome panel, the applicant emails and the Slack summary button, but only a chair can act on them, and for everyone else those controls are disabled rather than hidden, so the process is visible to the whole committee. Add a settings screen for choosing the form, editing rubric criteria and weights, editing the eligibility rules, setting the disagreement threshold and the required number of reviewers per application, editing the three email templates, picking the Slack channel, and managing who chairs. Bear in mind Jotform enforces a daily limit on how often the connection can be used and returns how much is left on every response, so page efficiently, reuse the cached submissions and question labels across screens, and refresh on demand rather than refetching the whole round on every navigation.