Unit 3 · Module 2

What Apps Script Is

The runtime, where the code lives, and what a host global looks like up close

The one-paragraph definition

Google Apps Script is JavaScript that runs on Google’s servers. Every Google product (Sheets, Docs, Gmail, Drive, Calendar) is reachable from the script through a pre-loaded host global named after it. It’s the same V8 engine that powers Chrome and Node, hosted by Google, with the Google product API built into the environment.

The pieces, named

Piece What it is
The language JavaScript (V8 engine, modern syntax)
The host Google’s servers
The host globals SpreadsheetApp, DocumentApp, GmailApp, etc. — one per Google product
The editor script.google.com, or Extensions → Apps Script inside a Google doc
Where it runs Always on Google’s servers. Never on the developer’s machine.

Where the code lives

Apps Script can be created in two flavors, and the difference matters because it changes what getActive___() means.

Bound

The script is attached to a specific Sheet, Doc, Form, or Slide. Created from Extensions → Apps Script inside that document. The script belongs to that document and travels with it. SpreadsheetApp.getActiveSpreadsheet() means “the Sheet this script is bound to.”

Standalone

The script lives on its own at script.google.com, not attached to any document. To reach a specific Sheet, the script has to open it explicitly by URL or file ID — for example SpreadsheetApp.openById(“abc123”). There is no active document, so getActiveSpreadsheet() returns null.

Whose Google account the script uses

Every time an Apps Script touches Gmail, Sheets, or any other Google product, Google has to decide whose data the script is allowed to reach. The short answer: it depends on how the script was triggered, and the developer doesn’t always get the final say.

Two words to keep separate before reading the table below:

Which identity the script uses, by trigger

How the script runs Whose Google account it uses
Developer clicks Run in the editor The developer
Simple trigger (onOpen, onEdit) fires for a user in a shared doc The user who triggered it
Installable trigger (time-based, form-submit, etc.) The account that installed the trigger — usually the developer, but each user who installs the script for themselves gets their own copy running as them
Web app deployment (doGet / doPost) Set at deploy time: either “execute as me” (the developer) or “execute as the user accessing the web app”
Add-on installed by a third party The user who installed and is using the add-on

Where OAuth fits in

Apps Script still goes through OAuth. The first time a script tries to touch a sensitive service like Gmail or Drive, Google shows the running account a consent screen — “this script wants to access your Gmail. Allow?” The script can’t skip that. What it can skip is the setup work: the developer never has to write OAuth-handling code, register a client ID, store tokens, or refresh them. Google’s runtime handles the consent flow on the script’s behalf, then quietly hands it the access it needs.

The consent prompt is tied to the account currently running the script. If the developer clicks Run, the developer sees it. If a coworker triggers an onEdit in a shared Sheet, the coworker sees it the first time — for their Gmail, not the developer’s.

What a host global is up close

The previous module described host globals as “pre-loaded toys the host hands the script.” That’s the frame. Here’s the substance.

A host global is an object. The capitalized name — SpreadsheetApp, GmailApp, DriveApp — points to an object that already exists in the script’s memory before the script starts running. The developer never creates it, never imports it, never has to set it up. The runtime loads it on the script’s behalf, and the first line of the script can reach for it without ceremony.

What lives on a host global

Each host global comes packaged with methods — functions that hang off the object. A method is called by writing the object’s name, a dot, the method name, and parentheses. For example:

Apps Script

SpreadsheetApp.getActiveSpreadsheet();
SpreadsheetApp.openById("abc123");
SpreadsheetApp.create("New sheet");

All three lines start with the same host global, SpreadsheetApp, and each one calls a different method on it. The methods are the things Google decided the script should be able to do with Sheets — open the active one, open one by ID, create a brand new one, and so on. They’re the “buttons on the remote” from the previous module, only now we have a name for them: methods.

Why no import lines are needed

In most JavaScript outside of Apps Script, using someone else’s code means writing an import line at the top of the file — import { sendEmail } from “@sendgrid/mail”, for example. That line tells the runtime “go find this package and load it into my file.” Without the import line, the runtime would have no idea where sendEmail came from.

Apps Script skips that step for Google products. Because Google is the host, Google has already loaded its own products into the script’s environment before the first line runs. No import, no setup, no package install. The host globals are simply present.

What this means for reading code