Automations
Automations run when records change, on a schedule, on demand, or when a webhook URL is called.
Trigger types
| Trigger | Runs when |
|---|---|
| On Create | A record is created in InfoLobby or through a web form |
| On Update | A record is updated in InfoLobby |
| On Delete | A record is deleted in InfoLobby |
| On Schedule | A configured time arrives — every day, only on chosen weekdays, or only on chosen days of the month. See On Schedule triggers. |
| On Date Field | A record's date field reaches a chosen day — runs once for each matching record. Pick the date field, how many days before/after (or on) the date to fire, and the hour. For example, "3 days before" a Due Date runs the automation for every record whose due date is three days away. |
| On Demand | You run it manually |
| On Webhook | A GET or POST request hits the trigger URL (runs in the background) |
| On Web Page | Someone visits the flow's public page URL — the flow runs immediately and returns an HTML page |
| On Comment Added | Someone adds a comment to a record. Comments posted by automations themselves are ignored, so a flow that comments can't trigger itself. Use the {{comment.body}}, {{comment.author}}, and related tokens. |
| On Email Reply | A reply to an email sent from a record arrives back on that record. Use the {{email.subject}}, {{email.from}}, {{email.body}}, and related tokens. |
| On Email Opened | A recipient opens an email sent from a record (the first time only). Requires email tracking; some email apps block the tracking image, so opens aren't guaranteed. Use the {{email.to}}, {{email.subject}}, {{email.read_at}}, and related tokens. |
| On Task Completed | A task linked to a record on this table is marked done. Runs once, on the moment it's completed. Use the {{task.title}}, {{task.status}}, {{task.completed_by_email}}, {{task.due_date}}, and related tokens, plus the record's own {{record.*}} tokens. Standalone (personal) tasks that aren't attached to a record don't trigger automations. |
Finding automations
Each table's automations page lists that table's automations. The search box filters the list as you type.
Tick All flows to search across every workspace you administer — results show each automation's workspace and table, so you can jump straight to it without remembering where it lives.
Build options
Use the visual builder for common workflows: conditions, loops, record actions, email, HTTP requests, and AI prompts.
Use PHPScript — InfoLobby's code language — when you need full control. See the PHPScript reference for the language basics and every built-in function.
Visual builder steps
| Category | Step | What it does |
|---|---|---|
| Data | Query Records | Fetch records from a table into a collection variable. Tick Return single record to get one record instead of a collection — handy when you expect exactly one match (e.g. the current financial year). The step then errors if nothing matches, and you can use the record's fields directly without a loop. |
| Data | Get Records From View | Fetch records through a saved view on a table |
| Data | Get Record | Fetch a single record by ID |
| Data | Get Related | Fetch records from a related table for a selected source record |
| Data | Get Record Tasks | Fetch the open tasks attached to a selected record into a collection variable. Loop over them with For Each and read each task's {{task.title}}, {{task.status}}, {{task.due_date}}, {{task.assignee_email}}, and related values. |
| Logic | Set Variable | Assign a value to a variable (written in a code editor with syntax highlighting, autocomplete, and token support). Tick Holds a list when the value is an array, which is what makes the variable selectable in a For Each step (see below). |
| Logic | Set HTML Variable | Assign a rich-text/HTML value (edited in a visual editor, tokens supported) to a variable |
| Logic | For Each | Loop over a collection. The Loop over dropdown lists variables that hold a list: anything from Query Records, Get Records From View, Get Related, Get Record Tasks, plus any Set Variable with Holds a list ticked. That last one is how you loop over data you built yourself or pulled from an API (see below). |
| Logic | If / Condition | Branch based on a condition (with optional else). On record-update flows you can also test whether a field changed or changed to a specific value. Single dropdown/select fields compare like ordinary values; multiple select, user, and lookup fields use contains, doesn't contain, or changed and contains to test whether a value is one of those held. An Assign Task action pointed at a multiple user field creates one task per assigned user. |
| Logic | If (Expression) | Like If / Condition, but instead of picking a value, operator, and comparison you type the whole condition as one expression with {{tokens}} — e.g. {{record.amount}} > 100 && {{record.status}} == "open". Use it when you need &&/||, arithmetic, or functions that the simple picker can't express. Has its own optional else branch. |
| Logic | Stop Flow | Halt execution with optional reason |
| Logic | Skip to Next Loop Item | Inside a For Each loop, skip the rest of the current item and move on to the next one. Only available inside a loop. |
| Logic | Comment | A note to document your flow. Does nothing when the flow runs — it just makes the flow easier to read. Shown as a highlighted note in the step list. |
| Actions | Create Record | Insert a new record |
| Actions | Update Record | Modify an existing record |
| Actions | Delete Record | Remove a record |
| Actions | Add Comment | Post a comment on a record (added as the system user) |
| Actions | Generate PDF | Render HTML content (with a file name, optional header/footer, orientation, and page size) to a PDF and append it to a record's file field. Your HTML can use the built-in fonts — including a signature script font (Alex Brush) — by setting font-family (e.g. <span style="font-family:'Alex Brush'">); the same fonts also render in rich-text fields and web pages |
| Actions | Send Email | Send via SMTP connection. Optionally pick a From sender from the connection's configured identities (defaults to the connection's first identity). Optionally link it to a record — the email is then logged on that record's comment thread and replies thread back, and you can attach the record's files matching a pattern (e.g. *.pdf). You can also add one inline attachment (a file name plus content) — text, a {{token}}, or a data: URI; pair it with make_ical() in a Set Variable step to send calendar invites (need more than one? use email_attachment() in code mode). When linked to a record you can also tick Silent to log the email without notifying the record's followers. |
| Actions | HTTP Request | GET/POST/PUT/PATCH/DELETE to a URL, with custom headers (one Name: Value per line, tokens supported) and a JSON / form-encoded / raw request body |
| Actions | API Request | Like HTTP Request, but authenticated through a saved API integration (HTTP Basic, Token/Bearer, or OAuth2). Pick the connection — auth and OAuth2 token refresh are handled for you, so no credentials live in the flow. The URL can be absolute, or relative to the connection's base URL. Saves the same response object as HTTP Request |
| Actions | AI Prompt | Send a prompt to OpenAI and save the reply. Optionally set a Timeout — AI calls wait 3 minutes by default, and a call is never allowed to outlast the automation, so raise the automation's Maximum Run Time as well for a slow model |
| Actions | Assign Task | Create a task and assign it to someone. Pick the Assign to person from your workspace members, or use the {{user.email}} token to assign it to whoever triggered the automation. Set a title, optional details, and an optional due date or date-and-time (a due time is treated as UTC, matching record date-and-time fields — use a record date-and-time field token for it). Optionally link it to a record so the task shows up on that record. The task is created on behalf of the person who triggered the flow; on scheduled/webhook runs with no signed-in user it is owned by the assignee instead, and the assignee is still notified. |
| Actions | Log Message | Write to the flow log |
| Actions | Execute Flow | Run another on-demand flow. Pick the Workspace / Table the target flow belongs to (tables you've added under Additional Workspace Access appear here too), then the Flow. Passing a Record is optional — leave it empty to run the flow with no record, or pick a single-record source (e.g. Get Record, or a Query Records with Return single record checked). Optionally bubble up errors from the called flow. |
| Actions | Web Page | (web page flows only) The HTML this page returns, edited in a visual editor with token support. Every web page flow has at least one. |
Tokens
Inside the visual builder, use {{record.fieldName}} to reference the trigger record's fields. For update triggers, {{before.fieldName}} gives the previous value. Single user fields also expose .id, .email, and .name tokens, and single lookup fields expose .id and .title. A multiple field (several users or several linked records) holds a list — when you drop its token into text (an email body, a message), the values are joined automatically (e.g. Alice, Bob); when the token is the whole value of a field assignment, the full list is passed through.
To reach records linked through a lookup, or the line items in a sub-table, see Related and sub-table records — reading across links, setting lookups, and why line rows can't be written directly.
Tip: in any token field, just type {{ and a picker pops up — keep typing to filter, use ↑/↓ to choose, Enter to insert, Esc to dismiss. (The </> button next to the field opens the same picker.)
Looping over a list
For Each loops over a variable that holds a list. Steps that fetch records (Query Records, Get Records From View, Get Related, Get Record Tasks) produce one automatically, so they show up in the Loop over dropdown straight away.
For a list you build yourself, or one that comes back inside an API response, use a Set Variable step and tell the builder it is a list:
- Add Set Variable, name it (e.g.
rows), and set the value to the list. That can be a literal like[1, 2, 3], or a token pointing into a response, e.g.{{response.json.data}}after an HTTP Request or API Request step. - Tick Holds a list on that step.
- Add For Each and pick
$rowsunder Loop over.
Without step 2 the builder treats the variable as a single value, so it never appears in the Loop over dropdown.
Items that came from an API are plain data, not records, so the field picker has nothing to offer for them. Type their tokens by hand instead: if each item looks like {"name": "...", "email": "..."}, use {{item.name}} and {{item.email}}, matching whatever the loop item is named.
Leaving the value empty with Holds a list ticked starts the variable as an empty list, which is handy when you want to collect items as the automation runs.
Saving files from a flow
Create Record and Update Record can write to file fields by setting the field to JSON describing the file(s):
[{"url": "https://example.com/report.pdf"}]— fetches the URL and stores the file (name inferred from the URL, or set"name")[{"data": "<base64>", "name": "notes.txt", "type": "text/plain"}]— stores base64-encoded content (adata:URI works too)
Note the value replaces the field's existing files — include the current items (with their path) to keep them. Tokens inside the JSON must not contain quotes or newlines; for anything beyond simple values, build the array in code mode with record_update() instead.
Webhook and web page triggers have {{webhook.get}}, {{webhook.post}}, {{webhook.headers}}, {{webhook.body}}, and {{webhook.ip}} (the caller's IP address). Webhooks additionally have {{webhook.host}} (the caller's reverse-DNS hostname, empty when none) — this is omitted on web pages to keep page loads fast. Use dotted keys like {{webhook.get.foo}} for a query parameter, or bracket access like {{webhook.get}}["foo"].
The person who triggered the automation is available as {{user.id}} and {{user.email}} — handy for assigning a task or addressing an email to them. {{user.role}} gives their role in this workspace: admin, readwrite, or readonly, so a step can branch on what the person is allowed to do.
When nobody triggered the run (a schedule, a webhook, a public web form), the automation runs as a stand-in System user instead: {{user.id}} is 0, {{user.displayName}} is System, {{user.email}} is empty, and {{user.role}} is admin. Assigning a task to {{user.id}} won't work on those runs, since there's no real person to assign it to.
The table the automation lives on is always available as {{table.id}}, {{table.name}}, and {{table.db_table}}, on every trigger (including schedules and webhooks, which carry no record). In code mode the same variable also exposes $table["fields"], keyed by field id, where a relationship (lookup) field carries lookup_table: the linked table's id, which you can pass anywhere a table name is accepted. That lets a script follow a relationship without hardcoding the other table's name, so it keeps working in a copied workspace.
Current date and time in the workspace owner's timezone: {{now.date}}, {{now.datetime}}, {{now.time}}, {{now.timezone}}. The matching UTC tokens — {{now.date_utc}}, {{now.datetime_utc}}, {{now.time_utc}} — give the same instant in UTC; use these when writing into a record date/datetime/time field, since those fields are stored in UTC. See Dates, times, and timezones for which token to use where.
Variables from prior steps are available as {{varName}} (scalars) or {{varName.fieldName}} (objects/loop items).
Record tokens stay current. An Update Record or Generate PDF step refreshes the record it wrote, so every step after it sees the new values. Put an Update Record step first and a Generate PDF step second, and the PDF is built from the updated record. {{before.*}} is the exception: it always holds the record as it was before the automation started, which is what makes the "field changed" conditions work.
Link to another flow's URL. To reference the public address of a webhook or web page flow, use {{flow_url:<id>}} — pick the flow from the token list (under Flow URLs) rather than pasting its /webhook/… or /page/… link. This resolves to the live URL when the automation runs, so the link keeps working even after the workspace is copied or installed elsewhere (a pasted link would point at the original flow). Common uses: a record automation that emails a signing-page link, or a web page that posts back to a webhook flow.
Testing without side effects
While building, you can test-run a flow from the editor to check its logic. A test run executes the real steps — so a flow that creates records, sends email, or calls an external service will actually do those things.
Runs you start yourself aren't held to the usual step time limit that keeps background automations in check: a flow you test from the editor, run from a button on a record, or run on selected records from the grid can take as long as it needs. You stay in control — press the Stop button (or Ctrl+C in the editor) to halt it, or close the progress window to cancel a button/bulk run.
To try a flow safely, tick the small skip checkbox (next to the trash icon) on any action step that makes a change — Create / Update / Delete Record, Add Comment, Send Email, Generate PDF, HTTP Request, API Request, AI Prompt, Assign Task, or Execute Flow. During a test run a skipped step doesn't perform its action; instead it logs exactly what it would have done (its resolved values), so you can verify the rest of the flow without touching live data or sending anything. Skip has no effect on live runs — leave the boxes ticked while iterating and the flow still works normally once it's active. (Read-only and logic steps don't have the checkbox, since skipping them would just break the steps that follow.)
Error alerts
When an automation fails, admins see a warning icon () in several places:
- Workspace overview — next to the workspace name and the table name
- Table grid view — next to the table name (click to go to automations)
- Automations list — next to the flow name
- Flow editor — an error panel in the settings tab shows the last error time and details
To clear the error, open the flow editor and click Clear Error, or save the flow. Fixing and re-saving the automation automatically clears the alert.
Only active flows are counted — deactivated flows with errors do not show alerts.
Web page flows
An On Web Page flow serves a public web page. When someone visits its page URL, the flow runs right away and returns whatever HTML it produces — so you can build dynamic pages backed by your tables (status pages, dashboards, confirmation pages, simple microsites).
- The settings panel shows a Public Url (
/page/…) once you save. Anyone with the link can load the page; mark the flow Active to make it live. - Build the page with the Web Page step — a visual HTML editor with token support. Run query/logic steps before it to pull in data, then reference the results with tokens. Every web page flow keeps at least one Web Page step; you can add more and their output is joined in order.
- Incoming query string, post data, headers, body, and caller IP are available as
{{webhook.get}},{{webhook.post}},{{webhook.headers}},{{webhook.body}},{{webhook.ip}}(same as webhooks).{{webhook.host}}is webhook-only (skipped here to keep page loads fast). - If your HTML is a fragment, InfoLobby wraps it in a minimal page; if you output a full
<!doctype html>document it's returned as-is. - To protect shared infrastructure, page loads are rate-limited per account based on your plan; bursts beyond the limit briefly return a "too many requests" response.
Multi-workspace access
In the flow settings panel, you can grant a flow access to tables in other workspaces where you are an admin. This lets you query or modify data across workspaces.
Moving a table to another workspace
When you move a table to a different workspace, its own automations move with it. Before the move you'll see a summary of any automations that need updating:
- Auto-updated — visual automations that reference the table are automatically granted access to the workspace involved, so they keep working. (This widens their workspace access — anyone who can edit them can then reach data there.)
- Needs review — code automations (PHPScript) can't be updated automatically, and automations in a workspace you don't administer are left untouched. Open these and fix any table references by hand.
Tables can only be moved between workspaces in the same database and the same account. If the table has file fields, the target workspace must have file storage that matches the source's — otherwise the move is blocked so your files aren't orphaned. When a file table moves, its stored files are re-tagged to the new workspace (shown with a progress bar).
PHPScript
When the visual builder isn't enough, write your automation in PHPScript — InfoLobby's code language. It covers records, querying, comments, files, email, HTTP and API calls, AI, dates, tasks, and more.
See the dedicated reference:
- PHPScript overview — what it is and a full function index
- PHPScript basics — the language: variables, control flow, arrays, record shapes
- Function pages with parameters, samples, and example output — e.g. records_query(), record_update(), curl_request(), task_assign(), openai_gpt()
On Schedule triggers
An On Schedule automation runs on a clock rather than a record event. Configure:
- Repeat — how often it runs:
- Daily — every day (the default).
- Weekly — only on the days of the week you pick. Choose one or more (e.g. Monday and Friday) and the automation runs on each of them.
- Monthly — only on the days of the month you pick. Choose one or more numbers (e.g. the 1st and the 15th), and/or Last day of month to always run on the final day — which correctly lands on the 28th, 29th, 30th, or 31st depending on the month. A numeric day that a month doesn't have (e.g. the 31st in April) is simply skipped that month; use Last day of month if you mean the end of every month.
- Trigger Hour — the hour it runs, in your account's timezone (shown as a hint under the selector). On Daily you can also choose Every Hour to run once at the top of every hour; Every Hour isn't available for Weekly or Monthly, which need a specific hour.
If the server is briefly unavailable at the scheduled hour, the run is recovered automatically within the day rather than skipped.
On Date triggers
An On Date automation checks a date field once a day, at the hour you choose, and runs for each record whose date lands on the target day. Configure three things:
- Date field — which date (or date-and-time) field to watch. Date-and-time fields match on the day, ignoring the time.
- Day offset — a number plus before / on / after. "3 days before" fires when the date is three days away; "on" fires on the date itself; "2 days after" fires two days past it.
- Hour — the hour of day it runs, in your account's timezone.
Inside the automation, the matched record is available just like a create/update trigger — use {{record.fieldName}} tokens. Each record fires once for a given day. If the server is briefly unavailable at the scheduled hour, the run is recovered automatically within the day rather than skipped.
Silent actions (no follower notifications)
The Create Record, Update Record, Delete Record, Add Comment, Generate PDF, and Send Email (when linked to a record) actions each have an optional Silent checkbox. Check it when a flow makes routine or bulk changes that shouldn't notify the people following those records — the change is still made and still recorded in activity history, but record followers get no notification for it.
Silent only mutes notifications to followers. People you @mention in a comment, users newly assigned to a record via a user field, and task assignees are still notified.
In PHPScript, pass ["silent" => true] as the final argument: record_update("orders", $id, ["status" => "done"], ["silent" => true]). The same opts argument works on record_create, record_delete, record_comment, pdf_generate, and record_email_send.
How long an automation may run
Automations are capped at 30 seconds by default. That's deliberate: an automation that runs unattended and gets stuck in a loop would otherwise burn your runtime allowance without anyone noticing.
Some work legitimately takes longer — AI prompts, image generation, or a slow third-party API. Open the automation, and in its settings set Maximum Run Time to the value you need. Only that automation is affected; everything else stays at 30 seconds.
How high you can go depends on your plan (the setting shows your limit). If an automation exceeds its run time, it stops and the error appears in its run log.
Two things behave differently:
- Manual automations (run from a button, or with Run Flow on Selected) have no time limit. You're watching them, and you can stop them at any point from the progress window.
- Web page automations must answer within 55 seconds, because a browser is waiting for the page. For anything slower, have the page start the work and show the result elsewhere.
Slow API and AI calls
The HTTP Request, API Request and AI Prompt actions each have an optional Timeout — how long to wait for that one call before giving up. Leave it on Default (10 seconds for HTTP Request, 30 for API Request, 3 minutes for AI Prompt) unless you're calling something known to be slow.
A call is never allowed to outlast the automation itself. If an automation has 30 seconds left and a step asks for 5 minutes, the call is cut short to fit — otherwise you'd wait the full 5 minutes and lose the result anyway when the automation timed out. If you need a genuinely long call, raise Maximum Run Time as well as the step's timeout.
Runtime usage
Your plan includes a monthly automation runtime limit. To see where that time goes:
- The account page shows your total runtime for the period and a 30-day runtime chart. The runtime link on that chart opens a Runtime by Flow page ranking every automation by total run time over the last 30 days (with its workspace and table) — click any row to open that table's automations.
- Each table's Automations list shows a Runtime (30d) column with each flow's total run time over the last 30 days, so you can spot heavy flows in context.
Use these to find and optimise the automations consuming the most runtime.