Create Your First Script

AUTOMATIONBEST PRACTICESOPENFRAMETUTORIAL

Phase 5 — Scripts & Automation · Step 3

Section

June 19, 2026

Published

Vladislav Marchenko

Vladislav Marchenko

Head Of Marketing

Create Your First Script

Phase 5 — Scripts & Automation · OpenFrame Onboarding

The library is a great start, but sooner or later you'll want your own script — your install routine, your cleanup, your health check. The editor makes it straightforward, and you can test it against a real device before it goes anywhere near production. Let's build one.


Before you start

  • Decide what the script does and which OS it targets — that drives the shell type.
  • Have the script body ready (or be ready to write it in the editor).
  • Know whether it needs inputs — command-line arguments, environment variables, or neither.

Open the editor

Go to Scripts → Scripts List → Add Script. You'll get the New Script form.


Fill in the basics

  1. Supported Platform — toggle Windows, MacOS, or both. There's also a Run as User option (Windows only) for scripts that need to run in the logged-in user's context rather than as system.
  2. Name — something scannable, e.g. Clear Temp Files.
  3. Shell Type — pick the language: PowerShell, Batch, Bash, Python, Nu, Deno, or Shell. Match it to your target OS (PowerShell/Batch for Windows; Bash/Shell for Linux/macOS; Python is cross-platform).
  4. Category — file it so it's findable later.
  5. Timeout — how long (in seconds) to let it run before OpenFrame kills it. Default is 90; raise it for long-running installs.
  6. Description — say what it does in plain language. Future-you will be grateful.

Define inputs (optional)

If your script takes parameters, declare them here:

  • Add Script Argument — an Argument plus a Value. Leave the value empty to make it a flag.
  • Add Environment Var — a name plus a value, passed into the script's environment.

Pick the convention your code reads. If your script reads $env:NAME / os.environ / $NAME, use Environment Vars. If it reads positional/--flags, use Script Arguments. Mixing them up is the #1 reason a script "ignores" its input — see Run a Script on a Device for the full explanation.


Write the body

Scroll to Syntax and write (or paste) your code in the line-numbered editor. Keep it idempotent where you can — a script that's safe to run twice is a script you'll trust at scale.


Test before you save

Click Test Script. OpenFrame opens a Select Device picker (search, Device Tags filter, online/OS status) — choose a known device and run it for real. This is the step that catches a wrong table name, a bad path, or a variable you wired up wrong, before you roll it out. Confirm the result, fix, repeat.


Save

Click Save Script. It appears in your Scripts List with the shell type, OS, and category you set, and its "…" menu and detail page let you edit or run it later.


Quick checklist

  • Set Supported Platform (and Run as User if needed)
  • Named it, picked the Shell Type, set a sensible Timeout
  • Wrote a clear Description
  • Declared inputs in the right place — Argument vs Environment Var
  • Used Test Script against a real device before saving
  • Saved and confirmed it's in the library

What's next

You can now run your script on demand (Run a Script on a Device) or set it to run automatically — Schedule a Script covers recurring runs and device assignment. To read what came back, see Script Results & Output Logs.


Based on OpenFrame v0.9.19. Screens and defaults may shift between releases — when in doubt, what's in your console wins.

Vladislav Marchenko

Head Of Marketing

Hi all! My name is Vlad and I’ve been brought on to head the marketing team at Flamingo. Thankfully, this isn’t the first time I will be building a marketing department from scratch, so the experience should come in handy. Now it’s time to dive into the world of MSPs and find myself in this new world.

Related Content

Product Releases

Webinars

Case Studies

Blog Posts

Frequently Asked Questions

MSP AI Agents

Yes. In production MSP shops today, 10% to 25% of tickets close before a human opens them. Thread alone has processed 173 million tickets across 750-plus MSP partners at 96% triage accuracy, handing back 490,000-plus technician hours. Agents own the low-risk, high-volume work (password resets, MFA enrollment, known installs, onboarding and offboarding) and flag anything that touches production data or needs judgment for a human to take.
On a five-person desk, reported deployments show $78,000 to $130,000 in annual direct labor savings, roughly 30% fewer escalations, and 15% to 20% better SLA compliance. Broader MSP adoption data adds ticket handling time cut by 45% and five to 12 points of margin, all from reclaimed capacity rather than headcount cuts.
An AI agent for an MSP is software that reads a ticket, decides the action, performs it across your tools, and records the result without a technician driving each step. It differs from a chatbot or copilot by taking action, not just suggesting one.

AI MSP

MSPs use AI to triage and route tickets, cut alert noise, schedule patches, assist L1 security work, and draft client reports. Kaseya's 2025 benchmark found 30% already use it to eliminate tedious tasks, with ticket triage the most common starting point.
Start with a readiness assessment, not a tool purchase. Confirm your ticket history is clean and your RMM, PSA, and monitoring systems connect. Then pick one high-volume, low-risk workflow, usually ticket triage, and pilot it on internal tickets before any client sees it.
Automate high-volume, low-risk tasks first. Ticket triage and alert noise reduction top the list because they run constantly and a human still resolves the underlying issue. Save security approvals, billing changes, and client-facing actions for later, always with a human in the loop.

AI Safety

It can be, with governance. Keep a human in the loop on high-risk actions, log every automated step for audit, and choose platforms that keep your data yours with no vendor lock-in. Pilot on internal data first so you catch issues before client systems are involved.

AI for MSPs

Set a baseline before rollout, then track tickets closed per technician, mean time to resolution, percentage of tickets resolved with no human touch, technician hours reclaimed, and cost per ticket. AI-driven automation commonly cuts operational cost per ticket by 25 to 40%.
No. AI automates routine tickets, patching, and monitoring, but trust, accountability, and complex business judgment still need people. The future of managed services moves technicians from closing tickets to advising clients, which makes the human role more valuable, not obsolete.

About OpenFrame

OpenFrame isn't built to plug into your stack. It replaces it. Instead of duct-taping a dozen tools together (RMM, MDM, SIEM, patching, remote access, each its own login and bill), we bundle it into one unified platform: RMM, MDM, monitoring, automation, remote access, patch management, security monitoring, and ticketing, plus built-in AI copilots. So "does it integrate with X?" usually means: you won't need X anymore.