Functions in BAS: Turning Blocks into Reusable Logic

If modules are the boxes BAS ships with, functions are the units you build yourself. They’re the layer where a loose sequence of clicks and extractions becomes something you can name, reuse and reason about — the difference between a script and a program.

What a function actually is

A function is a container made of action blocks. That’s the clean way to place it in the BAS hierarchy: modules are made of functions, and functions are made of action blocks. You take the blocks that accomplish one coherent task and wrap them into a single named unit.

During development you’ll reach for functions constantly, because they exist to group the actions you need into something you can call by name instead of rebuilding by hand.

Why you break a scenario into functions

A well-written automation script is split into component parts. Take a typical registration bot — it naturally decomposes into discrete jobs:

• authorising on the site
• fetching the balance
• registering the email
• and so on

Each of those becomes its own dedicated function. That’s the whole point: you break a sprawling scenario into concrete, single-purpose tasks, each isolated behind a name. When the login flow changes, you fix one function — not twenty copies of the same blocks scattered through the project.

Parameters and return values

Functions in BAS behave like functions in any programming language. They can:

• Take parameters — values you pass in when calling the function. Inside the function you read them with the Get function parameter action, so the same logic can run against different inputs.
• Return a result — handing a value back to the caller and signalling whether the function completed successfully or not.

This is what makes a function reusable rather than a one-off. Log in shouldn’t be hardcoded to one account; it should take the login and password as parameters and return success or failure. Write it once, call it for every account.

Running functions across threads

The payoff that matters at scale: a function can be called across multiple threads at the same time. That’s the primary lever for raising the throughput of an automation scenario — instead of processing one account, one listing or one message at a time, you run the same function in parallel across many threads.

Combined with the right interaction mode (a real browser caps out around 100–200 threads per machine; the HTTP-client scales far higher), parallel function calls are how a BAS project goes from “works on my list of ten” to “chews through tens of thousands.”

The takeaway

Functions are the hinge of the whole BAS model. Below them, action blocks do the literal work. Above them, modules package functions for reuse across projects. In the middle, functions are where you impose structure: name the tasks, parameterise them, return clear success or failure, and run them in parallel. Master that habit — decompose, parameterise, reuse — and your bots stop being fragile one-offs and start being systems you can maintain.