Hand off an Apps Script reminder before its operator leaves

Keep Google Workspace and the existing reminder while a successor proves they can operate it through their own account. Sharing the project alone is insufficient. Defer the handoff if the outgoing operator cannot inventory and retire their trigger, or if you cannot resolve uncertain outputs. Completing the handoff does not establish that a paid seat or contract can be removed.

This covers one existing, low-volume internal reminder within the same organization, while its outgoing operator remains available. Web apps, published add-ons, cross-domain moves and customer-facing or consequential actions are outside scope. Documentation was checked on October 21, 2026. The pilot is UNEXECUTED. No script or account was changed, and no catalog price was freshly verified.

Separate project access from execution identity

Google requires editor access to maintain a script; a bound script inherits access from its container. Installable triggers are not shared with collaborators, and user properties belong to individual users. The associated Cloud project has separate permissions, and collaborators need read access to included libraries. Google's collaboration guide.

An installable trigger runs as its creator. Another account cannot see that person's installed triggers. Time-driven execution can also be randomized within a time window. A successful manual run therefore does not establish the identity or timing of future scheduled work. Installable trigger behavior.

Record the project and container addresses, maintained code revision, function, schedule, time zone, creator, source data, recipient list and output location. Ask the outgoing operator to inspect their own triggers, including any duplicate schedules for this reminder. Do not infer that an empty successor trigger list means the project has none. If an active schedule's creator is unknown or unavailable, defer.

Arrange a maintainable ownership home for the project and container before departure. Google's collaboration guidance describes shared drives as a way to avoid individual ownership, but this is not a trigger transfer. Have the administrator approve the applicable ownership arrangement; folder sharing alone should not be your continuity plan. Ownership considerations.

Require a durable record of the work

Proceed only if the reminder already has a usable work ledger and a practical reconciliation procedure. For each intended reminder, you need a stable item identifier, due period, intended recipient, attempted action, observed result and unresolved status. Preserve an approved snapshot of the current ledger and configuration before changing anything.

The ledger must distinguish completed, still due and uncertain work. A send could succeed before its completion marker is saved. An absent marker is therefore not sufficient reason to send again. For this small internal audience, agree how the operator will check destination evidence or ask the intended recipient to confirm receipt. If the outcome remains unknowable, stop and resolve it with the process owner instead of replaying the batch.

Apps Script's execution log is short-lived. Google also provides Cloud Logging and Error Reporting, with fuller access dependent on the associated standard Cloud project. These are diagnostic resources, not proof that every intended recipient received a reminder. Logging documentation.

Have the successor and backup retrieve an older reminder's source item, ledger entry and output evidence through their own authorized access. Agree how long this history is needed and where it will remain retrievable. If the only history is a transient console log, defer this handoff until the existing automation's maintainer supplies a suitable record.

Prepare the successor without starting a second sender

Name a primary operator and a backup. Check their project/container access, necessary Cloud permissions, library access, source and destination permissions, properties and authorization setup. Reconstruct approved user-specific settings through the existing setup procedure. Treat any user-specific processing cursor as business state to reconcile, not a setting to reset blindly. Keep credentials out of the handoff document.

The successor must authorize the required function before creating a trigger. Google's trigger setup guidance. Use the automation's existing harmless test mode or an isolated test copy with dummy input and approved internal test recipients. If no safe manual test is available, have its maintainer resolve that before proceeding.

Check the successor's other workloads too. Apps Script quotas are per user, related Google-product quotas also apply, and exceeding a limit can stop execution. Low volume alone does not establish available capacity. Current quota boundaries.

Proposed pilot: observe the actual changeover

UNEXECUTED: record date, operator, input identifiers, expected result, actual result and evidence for each step. Choose a quiet change window between scheduled runs, with the outgoing operator available through their own account. Agree an acceptable delay and a deadline for investigating an absent run.

1. Rehearse manual operation. The successor uses the harmless test path. Confirm the intended sender, recipient, source access, output and ledger entry. The backup retrieves that evidence and an older completed item without the original author's help. No successor production schedule is active yet.
2. Reconcile the last outgoing scheduled run. Observe its real execution and compare every item due through the agreed cutoff with the ledger and destination evidence. Resolve partial sends individually. Save the remaining-work list; a green execution status alone is insufficient.
3. Retire the old schedule. The outgoing operator deletes their identified reminder trigger through their own account and records the result. Google documents account-level trigger review through My Triggers. Trigger management. Check for in-flight executions and reconcile any work completed during retirement; do not assume deleting a schedule cancels a run already underway. The dashboard exposes running execution status. Execution monitoring.
4. Start and observe the successor schedule. Only after retirement and reconciliation, the successor creates their own trigger with the recorded function, schedule and time zone. Wait for its first actual scheduled execution. Confirm creator identity, expected items, recipients, outputs and ledger updates. Do not substitute another manual run for this evidence.
5. Exercise monitoring and recovery. The backup locates a failed or timed-out execution and explains the response using the runbook. Use a harmless test failure if available; do not manufacture a production failure. If failure diagnosis remains unproven, keep the handoff open. Assign who checks each expected run and who covers absence.

Google sends failure notifications for these installable triggers and provides execution error details. Confirm the successor's notification settings and how the backup receives necessary failure information; do not assume project sharing copies alerts. Independently check for missing ledger entries by the agreed deadline, even when no error email arrives. Trigger failures, execution diagnostics.

Roll back without replaying completed sends

If the successor run fails, its creator retires the new schedule. Check in-flight work, reconcile outputs and preserve the amended ledger. The outgoing operator may recreate the recorded schedule only while still authorized, after unresolved work is settled and the processing position is correct. Never restore an old cursor over newly completed work.

The backup's access does not make another person's trigger visible. If its creator is unavailable and you cannot establish that the schedule is retired, defer automated resumption and escalate to the administrator and process owner. Never share accounts or retain an employee identity contrary to offboarding policy. Agree a temporary manual process only for individually reconciled outstanding reminders; there is no guaranteed exactly-once delivery or automatic catch-up here.

Review the bill separately

Keep necessary paid access or maintenance support when permissions, historical retrieval, monitoring or recovery remain unresolved. This procedure retains Google Workspace and the automation; it does not replace an automation platform.

Compare actual invoices with a dated administrator or reseller quote over the same term and required workload, showing current and proposed seat counts explicitly. Calculate current committed cost minus confirmed remaining cost minus incremental successor or support charges. Count retained Workspace cost once across the stack; record handoff effort separately. A reassignment may save nothing during the commitment.

Use the subscription audit to record remaining charges and Stack Watch for current options and availability. Consider a billing change only after the operational evidence and separately authorized offboarding review support it.