Workflow triggers, actions, tests, and runs

Use this reference while building or auditing a workflow. The editor validates the graph and fails closed when a Type, property, relation, mapping, or branch cannot be resolved safely.

Triggers

Every workflow has exactly one trigger.

Capture

Starts when an item lands in Captures. You can restrict it by:

• Capture source, such as Quick capture, Clipboard, Share sheet, AI agent, API, or Integration.
• Content kind: text, URL, file, audio, image, JSON, or HTML.
• URL host.
• Text contained in the title or captured text.
• Object Type, optionally including subtypes.
• Structured property filters.

Capture triggers act only on captures, never on notification-center items.

Caution

For Deep link and Share sheet sources, automatic execution requires the trigger to name the source explicitly. Otherwise Lar presents the result as a suggestion. This prevents a broad “any capture” rule from turning untrusted or externally supplied input into silent egress.

Object created or changed

Starts when an Object in the selected Type scope is created, or when a property changes. A property-change trigger can watch one selected property or any property.

Events are debounced for a short period, and Objects currently being changed by automation are guarded against immediate recursive execution. This reduces loops but does not make a poorly designed pair of workflows safe; test rules that edit properties watched by other rules.

Schedule

Runs every hour, every day at a local time, or every week on a chosen weekday and local time.

If the app was closed at the due instant, Lar catches up with at most the most recent missed occurrence. A scheduled query is capped, so do not use one run as an unbounded bulk migration.

Date property

Runs on, before, or after a selected date or date-time property at a chosen local time. The property must belong to the scoped Type and remain a date-compatible field.

An empty, malformed, or wrong-type value does not match. Changing the date creates a new effective due key and can arm the workflow again.

Manual

Runs only when you choose Run workflow from an Object’s options menu or the command palette. Manual workflows can ask a free-text question or present a choice before execution.

Match scope and filters

Use the trigger to decide which event wakes the workflow, then use scope and filters to decide whether it matches.

1. Choose one or more Types, or leave the scope broad where the editor permits it.
2. Turn on Include subtypes when descendants should match.
3. Add structured filters for properties, relations, dates, or system fields.
4. For Capture triggers, add source and content predicates.
5. Check the live match diagnostic where available.

If a condition cannot be checked—because a field or relation no longer exists, an operation is unsupported, or nesting is too deep—matching is disabled for safety.

Actions

The action picker groups the available operations. Current actions include:

Purpose	Actions
Create and classify	Create object, Convert to type, Apply template
Edit	Set properties, Append to body, Compute formula
Organize	Add tags, Remove tags, Add to collection, Remove from collection, Link relation
Inbox and lifecycle	Archive, Discard, Delete object
Communicate	Send notification, Send webhook
Compose automation	Run workflow
AI	AI: Classify, AI: Extract fields, AI: Summarize
Identify and recommend	Identify entity, Enrich entity, Recommend one
Manual input	Ask a question, Ask to choose

Map values into an action

An action field can use:

• A literal value you enter.
• A field from the trigger subject.
• The output of an earlier producer node.
• A text template that substitutes fields without executing code.

There is no general-purpose scripting or eval. Formula actions use Lar’s bounded formula language; templates perform substitution only.

Control flow

Use If for true/false filtering, Switch for several named cases, and For each to query a bounded set of Objects and run a body path for each item.

A For each node has two exits:

• Each enters the repeated body.
• Done continues after all selected items have been processed.

The engine enforces graph and iteration limits. Loop-body steps are summarized in run history rather than producing an unbounded row for every item.

Test a workflow

1. Open the workflow and select Test.
2. Choose a test subject, or use the suggested matching Object.
3. Select Preview.
4. Inspect the path, branch decisions, resolved input, and summarized output for each step.
5. Fix any unexpected mapping or branch.
6. Only when ready, select Run for real and confirm.

Preview is for understanding the planned path. Run for real performs actual writes and may create, edit, archive, discard, delete, or transmit data. The confirmation names the subject so you can verify the target.

Caution

Do not treat Preview as a rollback mechanism. A live run cannot be “previewed away,” and completed steps are not automatically reversed after a later failure.

Read run history

Open the workflow and use the run dock or View runs from its row. Runs are shown newest first and can be filtered to All or Errors.

Each run records:

• Outcome: Succeeded, Partial, Failed, or Denied.
• Origin: Capture, Object event, Schedule, Date property, or Manual.
• Subject Object, when it still exists.
• Step count and the branch or port taken.
• Bounded input and output details for each node.

Run history is stored in the local encrypted workspace database and is device-local; it is not a synced audit log across every device.

A failed automatic run also creates a notification under the bell so the failure is visible without keeping the workflow editor open.

Retry a run

1. Open View runs.
2. Expand the failed or partial run and review its step details.
3. Select Retry.
4. Read the confirmation, then choose Re-run.

Retry runs the entire workflow again from the same saved trigger snapshot. It does not resume at the failed step. Previously computed AI results are reused, but all other reached actions run again.

Caution

Before retrying, check for side effects from the earlier partial run. A retry can create another Object, send another notification or webhook, append the same text again, or repeat another non-idempotent action.

Failure behavior

By default, the graph stops on an action error and records a failed or partial outcome. An action can opt into Continue if this step fails, but later steps then run without the failed output unless their mappings remain valid.

Use continue-on-error only for optional branches. It is not a substitute for validating required inputs or external destinations.

Safety checklist before enabling automatic mode

• The Type scope and filters exclude unrelated Objects.
• Unverified capture sources are either excluded or explicitly named and reviewed.
• Every create, append, notification, and webhook action is safe to repeat.
• Delete is terminal and Trash recovery is acceptable.
• AI standing consent and spend limits match the expected frequency.
• Webhook disclosure lists only fields the destination should receive.
• Scheduled and date-property rules cannot fan out unexpectedly.
• Preview follows the intended branches for representative subjects.
• Run history and notification failures have been checked after a live test.

Related articles

• Create and manage workflows
• Process your Captures
• Capture from other apps and services