Limits and permissions

Time, memory and size limits for functions, and whose permissions a function runs with in each situation.

Functions run in a sealed sandbox with fixed limits. Their access to your data is always borrowed from a person, never taken. This page lists both.

Limits

Limit Value
Time per run Set per function: 100 to 30000 ms. Default 5000 ms. When it runs out you see Timed out.
Memory per run 128 MB. Going over stops the run with "memory limit exceeded (128 MB)".
Code size 256 KB.
Name Up to 120 characters.
Description Up to 500 characters.
Log output Up to 1000 lines or 256 KB per run. After that logs are cut off with "[log truncated]".
Calls to workspace data Up to 10,000 per run.
Runs at the same time Up to 4 per workspace. Extra runs wait their turn.
Result Must be plain data (JSON).

What the sandbox leaves out

Every run starts fresh in its own sealed space. There is no network, no files, no timers and nothing from outside. Your function reaches your workspace only through the axis toolkit, which is covered in Developers. To call another website, use a flow's HTTP request block (Blocks reference).

Whose permissions a function uses

A function can never do more than the person or role it runs as. A refused call comes back to your code as an error you can catch, and shows as a red step badge when you run by hand.

How it is started Runs with
You press Run function Your own permissions. You need Can run on Custom code.
Called over its public web address The public role only. See Expose a function over HTTP.
A flow's Run function block The flow's author and the function's author, whichever has less. See below.
A work queue stage button, or a stage's arrival action The person who pressed the button or moved the item, and the function's author, whichever has less.
A form's function target See Forms. A form filled in by a signed-in person runs as them; a public form runs as the public role.

The rule for automatic runs

Flows and queue stage buttons still need the caller to hold Can run on Custom code. On top of that, automatic runs (flows, queue stages, forms) use the weaker of two people:

  • the caller: who the flow runs as, who moved the queue item, or who submitted the form; and
  • the function's author: whoever last changed the function's code.

In plain words:

  • If the author can do everything the caller can, it runs as the caller.
  • If the caller can do everything the author can, it runs as the author.
  • If neither covers the other, or the author no longer belongs to the workspace, the run is refused and the flow step, queue action or form submission records the error.
  • A public form skips this comparison and runs with the public role's access.

The point is that nobody can edit a function to borrow a more powerful person's access. Changing a function's code makes you its author, so a small edit by a lower-access person can reduce what a flow's function is allowed to do.

Tip: if an automatic run starts failing with a permission error after someone edited the function, check who last changed it and what their roles allow.

Permission levels

On the Roles page the app is called Custom code:

Level Lets someone
No access Not open Functions.
Can view Read the code.
Can run Also run a function. It acts with the caller's permissions.
Full control Write, change and delete functions. Code is unbounded, so this is a trusted job.

The workspace owner holds every permission.