Docs · Automating

Workflow nodes

Every node a workflow can use, grouped as the node picker groups them, with what each one asks for.

The node picker opens on Tab, or on the + at the end of a node or on a wire. It groups the nodes as this page does, and has a search box. For what a workflow is and how items move through one, read Workflows first.

Nodes marked host reach the machine Mosaic is installed on, and are off on Mosaic Cloud and, until the operator says otherwise, on a server. See Commands, scripts, code and files.

Most nodes run once for each item that reaches them. Those that would do something once for the lot, such as a mail or a command, start on Once, for all items and say so in a Run field you can change.

#Triggers

The six ways a workflow starts are described under What starts a workflow. A workflow can have more than one trigger.

#Mosaic

#Messages and requests

#HTTP request

Calls any address: an API, a service desk, a webhook.

The body and Authorization work as Postman's do, in Postman's words, so a request that works there can be copied across. Every method but HEAD can carry a body, GET included. Each body mode keeps its own content when you switch between them, and the two forms share their rows. binary sends a file from the machine Mosaic runs on, so it is a host field. A header typed by hand wins over the same header from Authorization.

For OAuth 2.0, the token is asked for once and kept until it runs out, so a workflow sending a hundred requests asks for one token.

On Mosaic Cloud, a request to an address inside a private network is refused.

#Send an email

To, Cc, Subject and Message, every field taking expressions. One message for all the items to start with, or one for each. It needs a mail server: set MOSAIC_SMTP_HOST, with its user and password, where Mosaic runs. Until then the node says it cannot send yet.

#Post to chat

Microsoft Teams, Slack, Discord or any webhook. Webhook URL is the channel's incoming webhook:

It is a password in the shape of an address: keep it in an environment variable and write {{ NAME }}.

#Search Microsoft 365

Finds the passages in your organisation's SharePoint, OneDrive or Copilot connectors that answer a question. No model answers: it is the text a person would have gone looking for.

One item comes out for each document found: title, author, url, text (the passages, most relevant first), relevance from 0 to 1, sensitivity (its label, where it has one) and the query that found it. Nothing found is no items, and a line in the node's console.

It reads as the account the Microsoft 365 Copilot integration is signed in as, and finds only what that account may read.

#Ask Copilot

Asks Microsoft 365 Copilot a question and hands on what it answered.

Each item comes out with answer, in plain words, and sources: what Copilot cited, each with a name and a url.

What you write in Ask and What it should know is sent to Microsoft. The node needs the Microsoft 365 Copilot integration signed in with the permissions the chat asks for, a Copilot licence on that account, the workspace's AI switch on, and Pro or above.

#Check a port

Whether each item's host answers on a TCP port, as nc -z says it: a connection opened and closed, with no shell, so it works on Windows too. Host is {{ $json.host }} to start with, Port 22, Wait 3 seconds. Each item comes out with status: online, offline, or nohost when it had no host. 32 hosts are tried at once, so four hundred stores take seconds.

#Data

#Conditions

Filter, If and Switch test items with conditions, all of them or any of them, with Ignore upper and lower case as a switch. A condition compares a value, usually an expression, by its type:

is in and is not in take a list of values separated by commas: Store type is in Outlet, Concession.

#Flow

#Joining on a field

Merge set to Matched on a field is a join. Wire the items to keep into input 1, and the ones to look things up in into input 2.

Every item of input 1 is a left join, and it is how a column is added to a list. To put each article's price beside the lines of a stock count:

1. Start with When run by hand.
2. From it, Read a file, read as Excel: one item for each line of the count.
3. From the trigger again, on a second wire, Run a query: a data source that returns the article code and its price. It runs once, because the trigger hands it one item.
4. Merge the two: the file into input 1, the query into input 2, matched on the article code, keeping every item of input 1, adding the price.
5. End with Show as a table.

Values are matched as a Check matches keys: as text, without the spaces around them. 40112 and 40112 are one value; ab-1 and AB-1 are two. An empty value matches nothing, not even another empty one. An item that finds two matches comes out twice, once for each.

The node's console says how the join went — 1,370 of the 1,500 items of input 1 found a match in input 2, and 130 did not. A field name that no item has stops the run and lists the names there are, since a join on a field typed wrong would otherwise match nothing and say nothing.

#Files and server

All of these are host nodes. Paths are on the machine Mosaic runs on, read and written with the account Mosaic runs as. A path field has a Browse button over that machine's folders.

#Reading an Excel sheet

Read a file with Read it as set to Excel, one item per row reads an .xlsx workbook.

Each cell arrives as what it holds. A number is a number, so it can be summed and goes back out to Excel as one. Text is text, so a code Excel kept as text keeps its leading zeros. A date is 2026-11-09, a date and time 2026-11-09T14:30:00. An empty cell is empty, and a row with nothing in it is skipped. A formula gives the value Excel last calculated for it.

The node's console says what it read: Read 1,500 rows of 12 columns from the sheet "Count". A workbook read as text or JSON by mistake is refused, with the setting to change. The older .xls format is not read: save the file as .xlsx first.

Where the file nodes are off, as on Mosaic Cloud, read a spreadsheet through a file data source and Run a query instead.

#Run on another machine

Runs a script on a store's server or a till, copies a folder there, or starts a long job there and follows it, through PowerShell remoting.

Wait for it to end takes up to 60 minutes. Starting a job with a wait makes the node wait for it and fail if the job fails or stops, with what the job printed. Looking in with a wait carries on until the job has finished, failed or stopped, through a restart of the machine.

What it needs:

• Mosaic running on Windows.
• PowerShell remoting switched on at the other end (Enable-PSRemoting). Connect over HTTPS uses port 5986.
• User: an administrator of that machine. Left empty, Mosaic connects as the account it runs as, and in a domain nothing more is needed.
• Password: only from a secret variable, {{ NAME }}. A typed password is refused, because it would be saved with the workflow. It is sent to PowerShell on standard input, never on a command line.