Triggers

The trigger sets what starts a run. Every workflow has exactly one trigger. In the field Kind you choose one of four kinds:

• Form: a signed-in member starts the run by hand.
• Public form: someone with the link fills in a form and starts a run with it, without signing in.
• Schedule: the workflow runs at fixed times.
• Integration: an event in a connected app starts the run, for example a new email.

Configure the trigger

Click the trigger card in the builder. You change the name in the header of the dialog, and below it is the row Note. The dialog has up to three tiles:

• Trigger: always there. Here you choose the Kind, and for Integration also Integration and Event. Below them are Settings and Start form, depending on the kind. Settings appears only if the kind has settings. Form and Public form have none. Start form exists only for these two.
• Responsibility: only for Integration and Public form.
• Output: always there. Shows the fields the trigger puts into the context.

You cannot delete or duplicate the trigger. You change its kind instead. This resets the settings. Start form and Responsibility are kept if the new kind has them too.

Start by hand

With Form, you fill in a form on start, or just click if there are no fields.

1. Set Kind to Form.
2. Create the questions under Start form.
3. Publish the workflow.
4. Set the workflow up for yourself.

After that you start runs in the tab Run on the workflow page or with Start now on the trigger card. As long as you have no switched-on setup of your own, the start stays locked. How you set a workflow up for yourself is described under Publishing and setup.

In the start form you set, per question, the label, placeholder, example and order, and whether it is mandatory. Without a list of your own, the form asks for all declared fields in declaration order. The trigger puts only the fields of the start form into the context.

With this trigger someone is watching. Agents may therefore ask questions and send messages. The values do not count as content from outside, which is why there is no tile Responsibility.

Start through a public link

Public form fits when clients or colleagues without access should submit something.

1. Set Kind to Public form.
2. Create the Start form.
3. Publish the workflow.
4. Set the workflow up for yourself and switch it on.
5. On the workflow page, open Form link on the trigger card.

Your setup must run on a version with this trigger. Under Who may fill in the form? you choose Anyone with the link or Only members of this workspace. Switching does not change the address. Revoke link makes the link invalid immediately.

The link belongs to your setup. Every submission starts a run through your accounts and uses credit of the workspace. If your setup is paused, you can still manage the link: change the audience or revoke it. It cannot be reached then.

The public page shows the name of the workflow, the fields and Submit. After that the person sees a confirmation, but no run status, no run number and no result. Any feedback must be sent by the workflow itself, for instance with a step that sends an email. If the link is revoked or the setup is paused, the page shows "This form does not exist or is no longer shared."

Everything that comes in through this form is marked External. This also applies when you enter the values yourself on start. The workflow then treats them like a submission through the link and asks no questions.

Limits

Start on a schedule

Schedule fits daily reports or regular checks, for example. The workflow then runs without a trigger from outside.

1. Set Kind to Schedule.
2. Under Settings, click the field Schedule.
3. Choose Daily, On certain weekdays or Monthly and a time.
4. Choose the time zone under Time zone.

Below the field you see the next runs.

With Enter cron expression you switch to the field Schedule (Cron). There you write the schedule as a cron expression, a time specification in text form. This also covers schedules with step values or lists of hours, which the selection cannot represent. If you switch back to the simple selection, such an expression is replaced. The interface warns you about this.

Time zone offers Europe/Berlin, Europe/Vienna, Europe/Zurich, Europe/London and UTC. The default is Europe/Berlin. Daylight saving time is taken into account.

Each person can set a time of their own during setup. The time zone for it comes from their browser and cannot be chosen.

Only Schedule has Run once now. It immediately starts a run through your setup. The schedule continues independently of it.

The trigger puts no field into the context, not even the scheduled time. The first step fetches all data itself. There is no tile Responsibility, because a schedule delivers no content from outside.

Missed times are not made up. If the server restarts in the minute that is due, the run drops out without replacement.

Start on an app event

Integration fits when the workflow should react to something that happens in another system.

1. Set Kind to Integration.
2. Choose the app under Integration.
3. Choose the event under Event.
4. Narrow down the source under Settings, depending on the event for example with Folder, Channel, Table or Repository.

For IMAP mailbox, the Folder is INBOX by default, the inbox. For Microsoft Teams, the selection lists show the teams, channels and chats of your connected account.

The trigger names no account. Each person chooses during setup which mailbox or calendar is queried. How you connect an account is described under Connecting services.

There are more than 25 events:

Event fields

Every event puts its fields into the context. For New email in Outlook Mail these are Sender, Subject, Content and Received on. These four fields are marked External. Their content comes from outside, and the agent is instructed not to follow instructions in it.

The Message ID is an identifier that only the trigger can write. It is not marked External. It reaches only steps that explicitly request it, for instance a tool for replying, forwarding or attachments. Under the same rule, Gmail also delivers the Conversation ID.

Polling

lowcloud regularly asks for new events for every switched-on setup. Push notifications from the providers do not exist.

Each setup keeps its own record of the events it has already seen. Two people can therefore watch the same mailbox without taking events away from each other.

A newly set up or changed trigger begins at the current time. It never catches up on older emails, calendar events or records. About two minutes can pass before the first run.

Gmail can discard its change feed after about a week. The trigger then starts again and reports that events from the gap are missing.

Pre-filters at the provider

Gmail search for Gmail and Search term for Google Calendar filter at the provider. Whatever they sort out appears in no run. To filter by content, use Responsibility instead. There every run states why something was rejected.

App-specific behavior

• A shared Outlook mailbox needs additional permissions. A connection granted earlier has to be reconnected once for that.
• New chat message in Teams, without a selected chat, sees only the latest message of each chat per check.
• Airtable without a Title column set takes the first filled column. That can be the wrong one.

Set the responsibility

In Responsibility you describe in your own words which incoming items the workflow should handle. For example: "only support requests from existing customers, no newsletters". The field exists only for Integration and Public form, the kinds with content from outside.

Every incoming event is checked against this text. Whatever does not fit ends as Skipped. If the field stays empty, every event of the source starts a complete run.

How the check runs

From the text, lowcloud builds the first step of every run, Check responsibility. You do not build a card for it. A model checks the event without tools and answers yes or no with a reason.

On no, the run ends with the status Skipped and the model's reason. None of the steps you built runs then. Skipped runs are hidden by default in the section Runs of the workflow overview and do not count towards the success rate. Show N skipped shows them.

The check is one model call per incoming event. It costs even when the event is skipped afterwards.

Model for the check

As soon as there is text in the field, Model appears below it. There you choose the model for the check from the list. The top row stands for no model of its own. It is called Automatic, even when the workspace has set a default model. An unknown model is rejected as an error on publishing.

Test with a real event

Below the trigger card in the builder is the panel Test run. With it you start a run without waiting for a new event.

1. Click Load latest events.
2. Select an event from the list.
3. Click Test with this event.

You can load real events only for Integration. For Schedule the button is called Simulate tick, for Form and Public form it is called Start test run. Via the additional menu you run Trigger only.

The test run works against the draft, not against the published version. It reads the events from your own connected account, not from the account of a setup. Without a connected account for the service, you cannot select events. Connect one under Connections in that case.

A test run does not take an event away from live operation. It does not change which events the trigger has already seen.

Trigger errors

The trigger dialog shows when the trigger last fired. It shows an error as a red box Last error with Open connections. On the workflow overview, the same error appears under Check trigger with Open in builder.

If your setup has no account for the trigger, the trigger pauses. Your row then shows Paused and the note that no account of yours is assigned to the trigger.

A workflow that nobody has set up for themselves does not run, whatever the trigger. How you set up a workflow is described under Publishing and setup.

Webhooks

There is no webhook trigger, so another system cannot start a workflow. It is not available in the field Kind.

The chat in the builder can still write a webhook trigger into the draft. The draft can then be saved but not published. The message says: "Webhook triggers are currently not available. The workflow cannot be published." The address of an old webhook always answers with "Webhook triggers are currently not available."

Permissions

Anyone who may build (the role admin, or the former role developer) can create the link to a public form. Nobody else can. The same applies to a test run with a real event.