A welcome letter for every new therapist, sent when your team says yes.

The rules, as proposed

These are proposals to confirm with your team, not a description of how Mentella works today. This demo covers the welcome email only; it is not a proposal to keep the spreadsheet as your hiring system, and the same rules would move to whatever replaces it.

• Ready to send: initials in Approved by approve the name, address and start date the automation sees the first time it goes through the sheet after they appear. If any of the three changes afterwards, nothing goes out until someone writes Approve new address in the Decisions tab, and the row is read again just before each letter. A change made before that first run cannot be told apart from what was approved; for a stronger rule, the approver would record the approved address itself.
• “Hired”, “hired” and “Hired ” (with a space at the end) all count as Hired. “Offer accepted” is not Hired and never leads to a letter.
• For this nonclinical welcome message, your team would confirm which address may be used, a personal one included.
• Each arrival gets a stable Arrival ID, written once in the sheet by the routine. It is the arrival, not the row and not the person: copies and sorting change nothing, and a therapist who returns years later is a new arrival with a new letter. A number is never handed out twice, even after an interrupted write. If someone clears the reference of a row already welcomed, the row is held for review instead of getting a second letter (same address and start date). We would also protect the column in Sheets so only the automation edits it.
• A withdrawal cancels what is still waiting. A letter already sent stays in the history.
• A missing or impossible start date (“2026-10-32”) holds the letter for review.
• Sent means the mail service accepted the letter. Apps Script returns no delivery receipt; bounces arrive in the sending account, which someone should read.

If a send may or may not have happened

Before calling the mail service, the routine writes “attempt” in the journal and commits it (SpreadsheetApp.flush); if that write fails, no letter is sent. After the call it writes “sent”. If the execution stops in between, the next run finds an attempt with no result. It does not guess: the arrival goes to Needs review, the check emails the technical owner, and no further send is attempted until someone reviews what happened. They look in the Sent folder and write Confirm sent, or Send again knowing the first letter may still have gone out, in the Decisions tab with their name in By. An unsigned decision, or both answers at once, is ignored. A lock keeps two runs from overlapping; it is not a transaction between the mail service and the sheet, which is why the journal carries the attempt.

The check

• A second Apps Script project, installed by another account, with view-only access to the hiring sheet and the journal. The journal is a separate workbook the team does not edit (one project cannot read another’s script properties, so the journal is the shared record).
• Every 15 minutes (a demonstration setting) it looks at when the last run finished and at the sheet’s columns, then at results: approved arrivals still waiting, Needs review, uncertain sends, and rows that still have no reference after two runs. A stop is reported at the first check after about 40 minutes without a finished run, not within 15 minutes.
• A problem counts as notified only once the mail service accepted its note; if the note fails, the next check sends it again. The morning summary never uses up an alert. It says separately whether the automation is working and what is left for your team, and counts letters from the journal, so a deleted row does not hide a letter already sent. The check runs under its own lock.
• If it cannot read the sheet or the journal, or a column is missing, it says check impossible, never “no problems”.
• It cannot see an arrival that is in none of the sheets it reads. Two Google projects reduce shared failure; they do not protect against an outage of Google Workspace itself.

Going live, and living with it

• First read in dry run: the routine records what it would send and sends nothing. Arrivals starting before a chosen date are recorded as history and never mailed.
• installTriggers can be run again at any time; it keeps exactly one trigger, and replaces it if the cadence changed. verifyDeployment runs after every code change, as the operating account, and reports missing permissions, columns, the letter, the switch and the triggers.
• A dedicated sending account, with replies going to a team inbox someone reads, rather than an alias of a personal mailbox. The code lives in its own project, not inside the sheet everyone edits.
• Periodic reading rather than an edit trigger: an edit trigger does not fire for changes made by script executions or API requests, and a simple one cannot send mail. The daily summary arrives within its chosen hour, not at an exact minute.
• The routine reads the remaining daily mail quota from Google once per run and counts down locally (a local budget, not a reservation); when it runs out, it stops before the next attempt and the next run resumes.

Handing it over

• Change the letter: edit the Welcome letter tab. Each send records a fingerprint of the letter version, not a full copy of the message sent.
• Pause sending: set Sending to Paused in the same tab. Letters wait; the check says so.
• Handle an alert: every note names who acts and what to do; answers go in the Decisions tab.
• Replace the technical owner: triggers belong to the account that installed them and are not shared. The new owner runs installTriggers and verifyDeployment under the operating account, and the old owner’s triggers are removed. The check notices if passes stop in between.

Health information

The people and details on this page are fictional; there is no health information in it. Google lists Apps Script among the services covered by its HIPAA Business Associate Agreement (list dated August 31, 2026); that covers the service under a signed agreement, not this code and not this page. Employment records a covered entity holds in its role as employer are outside the definition of protected health information (45 CFR 160.103), which depends on context. Third-party services do not inherit Google’s agreement; what matters is which service receives which data under which contract. The page asks search engines not to index it; that is not access control.