Saved scripts

Your own script library, the four kinds, libraries pulled in with a comment, and handing one to a colleague.

The Scripts tab of the panel is a library that belongs to you: synced to your account, tied to a profile, and available on every instance you open. Nothing is installed on the instance.

Add one with the + button. A script has a name, a kind, a server half and, for some kinds, a window.

The four kinds

The kind does not decide where the code runs. The tab does. The Server tab always executes on the instance, where GlideRecord and gs live. The Modal tab always executes in your browser, where the form API is proxied for you. The kind says what the script is for, and decides what can start it.

Running one executes it on the instance you are on, in the global scope, through the platform's own background script endpoint. What you print comes back to the panel.

A background script has no undo. A script that writes records writes them for real. Query first, count what you matched, and only then write.

Libraries

Save a script with the kind library, and any other script can pull it in with a comment:

// @use dateUtils, ticketHelpers

var due = addWorkingDays(new GlideDateTime(), 3);   // from dateUtils
output.due = due.getDisplayValue();

At run time the library bodies are prepended to your script, dependencies first, before it executes. A library can use another library, and cycles are detected and cut, so a mistake degrades instead of hanging.

Four rules worth knowing:

• Library names are unique per profile, because @use resolves by name. The editor refuses a duplicate.
• A missing library is a warning in the log, not a crash. The script still runs without it.
• Names match without regard to case: // @use DateUtils finds dateUtils.
• Libraries never run on their own. No run button, no triggers.

The directive can sit anywhere in the script, though the top is conventional, and several lines or one comma-separated list both work.

Sending one to a colleague

Every row has a send button. Pick somebody you and they both follow (a package goes only to a mutual follow, whatever their message setting says), and the script is bundled with every library it reaches through @use, published as a package, and dropped into your chat with them.

If a library is missing from your own profile the send is refused, rather than delivering something that cannot run.

On the other side the card says what is inside: the kind, whether it has a modal, how many libraries, and, in amber, whether it runs by itself on a trigger. Install opens a review dialog with the full server script, the modal markup, the library list, and a plain warning about what installing means. Nothing is written until you confirm.

That warning is the honest one. A package is executable code from another person. They can send you something that runs on your instance, with your roles, the moment a form loads. What the system guarantees is narrow: that the sender is a connection you accepted, and that authorship cannot be forged. Judging the code is your job, and the dialog shows you all of it. Read it the way you would read a pull request.

Nothing of yours is overwritten

Installing never replaces something you wrote. A name that collides becomes a copy, such as Closer (from Ann). A library whose contents match one you already have is reused. One that clashes is imported under a new name, and the incoming script is pointed at it, so it keeps calling the code its author meant.

Updates and withdrawing

Send the same script again after editing it and the package's version goes up for everyone who has it. On their side the row grows a green update vN badge, and clicking it opens the same review dialog. An update does overwrite that installed copy, but keeps the name they gave it.

Withdraw, on your own card, takes back their access to the package: they can no longer read it or take updates. A copy they already installed keeps working. You gave them the code, and taking it off their machine is not something this feature pretends to do.

How many you can keep

Five saved scripts and five wildcards on Free, twenty-five of each on Pro. The limit is enforced by the database, so no client can step past it. An account above the limit after a downgrade keeps everything it has and is only refused when adding one. See plans.