Token claim, front to back
A working replica of a claim form I built and run for a writing community. The form is the part members see. The panel beside it is what the script actually does after they press submit, because the form was never the hard part. Nothing here writes anywhere; the client, the community and every member are withheld.
What the member fills in
What happens after submit
Submit the form and the eight steps below run in order, the way the deployed script runs them.
- Validate before anything is written Required fields, word count against tokens claimed, and a link check. The cheapest place to catch a bad submission is before it enters the ledger.
- Look up the member and deduct Confirms they actually hold that many unclaimed tokens, then decrements the balance. A claim for tokens the member does not have fails here.
- Write a document backup Member details on page one, the submitted writing after a page break. The sheet cell has a length limit; a long submission would be silently truncated without this.
- File it in the archive folder So the reviewer opens a document, not a spreadsheet cell.
- Notify the team inbox A role address, never a person, with the remaining balance and a link to the document.
- Confirm to the member Sent second, on purpose. If the team notification fails, nobody has yet promised the member anything.
- Append the row to the claims log
Timestamp, name, tokens, word count, status, a blank
Reviewedcell, the text and the document link. - Return the confirmation to the browser The only step the member ever sees.
The blank Reviewed cell is the trigger surface. Setting it to Yes moves the row to the archive tab. Nobody deletes anything by hand.
A daily job chases what is still blank. Seven days unreviewed and the reminder goes out, so a claim cannot quietly rot in a spreadsheet.
A failure is logged too. The catch block writes the same row with the error in the status column before it rethrows, so a claim that broke is still a claim you can find.