Build your first workflow

You'll build a workflow that watches for new orders and creates a review task for any order of £100 or more. Along the way you'll use an event trigger, a trigger filter, a Create data step and a template, then test the result and read its job.

Before you start

You need a project and two entities:

If you haven't created entities before, see Data modelling.

1. Create the workflow

1. Go to Workflows and select New Workflow.
2. Name it Flag large orders and select Create Workflow.

The editor opens with a Start node on the canvas.

2. Add the trigger and its filter

1. Select Workflow Settings.
2. Add a trigger with type Event, event EntityCreated and entity orders.
3. Add a filter condition: field total, operator gte, value 100.
4. Save the settings.

The filter is checked before a job is created, so orders under £100 won't start the workflow at all.

3. Add the step

1. Select Add Step and choose Create data.
2. Set the key to create_review and the entity to order_reviews.
3. Set the payload:

{
  "order_id": "{{ $anythink.trigger.id }}",
  "note": "Order from {{ $anythink.trigger.data.customer_email }} for £{{ $anythink.trigger.data.total }} needs review"
}

4. Connect the Start node to the step to make it the start step.
5. Select Save Workflow, then enable the workflow.

{{ $anythink.trigger.id }} is the whole value of order_id, so it's written as a number. The note mixes text and templates, so it's written as text.

4. Check it works

Create an order that should be flagged, and one that shouldn't:

curl -X POST "https://api.my.anythink.cloud/org/$ORG_ID/entities/orders/items" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"customer_email":"sam@example.com","total":149.50,"status":"new"}'

curl -X POST "https://api.my.anythink.cloud/org/$ORG_ID/entities/orders/items" \
  -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -d '{"customer_email":"ali@example.com","total":24.00,"status":"new"}'

Then check:

1. In the workflow, select View Job History. There's one job, for the £149.50 order, with status Success.
2. Open the job. The create_review step's data shows the review it created.
3. Open the order_reviews entity. There's one review: "Order from sam@example.com for £149.5 needs review".

The £24 order didn't match the filter, so it left no job.

What you built

Take it further

• Notify someone. Add a Send an email step after create_review to email your support inbox, or an Integration step to post to Slack. See Step types.
• Only flag paid orders. Change the event to EntityUpdated and add a filter condition status changed_to paid. See Triggers and scheduling.
• Summarise with AI. Add an Integration step using Claude to summarise the customer's order history into the review note. See Workflow recipes.

Next steps

A trigger decides when a workflow runs and what data the job starts with. A workflow can have several triggers of different types — for example, run when an order is created and every night at 02:00 to catch anything missed.

Add and edit triggers in the workflow editor under Workflow Settings.

Event triggers

Event triggers run a workflow when something happens in your project.

For the three entity events, choose the entity in Entity. For PushActionTaken, the entity box is the notification category; leave it empty to react to every category.

Note: On EntityCreated, trigger.data holds the fields in the create request, so it doesn't include the new id or values the server filled in. Use {{ $anythink.trigger.id }} for the id, or add a Read data step to load the saved record.

Limit: EntityDeleted appears in the event list but doesn't fire yet. Don't build on it.

Trigger filters

A filter makes an event trigger skip events you don't care about. Filters are checked before a job is created, so a filtered-out event costs nothing and leaves no job in Job History.

Filters are a tree of and, or and not groups around conditions:

{
  "and": [
    { "field": "status", "op": "changed_to", "value": "paid" },
    { "field": "total", "op": "gte", "value": 100 }
  ]
}

How filters behave:

• field is a top-level field on the record. Dotted paths and related records aren't supported.
• changed and changed_to only work on EntityUpdated, the only event that knows the previous values.
• Types matter: the boolean true doesn't equal the text "true".
• Text that looks like a date (for example 2026-09-01) is compared as a date.
• An empty and matches everything; an empty or matches nothing.
• An unrecognised op counts as a match, so check spelling — a typo makes the filter let every event through.

The dashboard filter builder covers and conditions. Use the workflow API to save or and not groups.

Timed triggers

Timed triggers run on a cron schedule.

Timed jobs start with an empty payload: there's no trigger.id or trigger.data. Begin with a Read data step to fetch what the job should work on.

Limit: Missed runs aren't caught up. If a timed workflow is disabled, it doesn't run while disabled; when you enable it again it runs once at the next minute, then follows its schedule.

Note: An invalid cron expression is saved but never runs. After saving, check the schedule's next run time.

Manual triggers

Manual triggers add the workflow to the Workflows menu on records of the entities you choose. Running it from a record starts a job with that record's id in {{ $anythink.trigger.id }} and the entity name in the payload; trigger.data is empty, so load the record with Read data if you need its fields.

You can also start a workflow from your own code:

POST /org/{orgId}/workflows/{workflowId}/trigger
Authorization: Bearer <token>
Content-Type: application/json

{
  "entity_name": "orders",
  "entity_id": 1042,
  "data": "{\"reason\":\"manual resend\"}"
}

• data is a JSON string, not an object. It becomes trigger.data.
• For a workflow with a manual trigger, entity_name is required and must be one of the trigger's entities.
• The caller needs the anythink_workflows:trigger permission.
• A successful call returns 204 No Content. The job runs in the background.

Limit: anythink workflows create <name> --trigger Manual --entity <entity> saves the trigger with no entities attached, so calls to it are then rejected with "not permitted for this workflow". Until this is fixed, create the workflow first, then set its entities in the Anythink dashboard.

API endpoint triggers

An API endpoint trigger gives the workflow its own route:

POST /org/{orgId}/workflows/api/sync-orders?id=1042&entity_name=orders
Authorization: Bearer <token>
Content-Type: application/json

{ "source": "shopify", "since": "2026-09-01T00:00:00Z" }

The response doesn't wait for the workflow, so an API endpoint trigger suits fire-and-forget work: imports, syncs and notifications. If your app needs the result, have the workflow write it to a record and read that record.

Workflows with several triggers

• Events: if more than one trigger on a workflow matches the same event, the workflow runs once.
• Schedules: each timed trigger runs independently. Two schedules due in the same minute create two jobs.
• Manual and API calls: when a workflow has both manual and API endpoint triggers, calls may be validated against either one, so an API call can be asked for an entity_name. Keep manual and API triggers on separate workflows.
• Steps can't tell which trigger started the job. If that matters, use separate workflows or check the payload shape in a Condition or Run a script step.

Note: anythink workflows seed doesn't apply a seed file's triggers array — the workflow is created with a single default Manual trigger regardless of what the file specifies, even though workflows export produces a triggers array in the same shape. Add extra triggers in the Anythink dashboard until this is fixed.

Enabling and disabling

• A disabled workflow doesn't run for events or schedules, and its buttons disappear from records.
• Each trigger also has its own Enabled switch.
• Edits apply to jobs that haven't started yet. A job that's already running finishes with the version it started with.

Note: Calls to the trigger endpoint and to API routes check the trigger's Enabled switch, not the workflow's. To stop a workflow's API route, disable that trigger.

Next steps

Each step does one job. Configure steps on the workflow canvas, or send the same parameters object to the workflow API. Parameter names are snake_case.

How steps return data

A step's output is saved under its key, so a step with key find_orders is read with {{ $anythink.steps.find_orders… }}. Where the output lives depends on the step:

When a step fails, its error details are saved at the top level of its output, and the workflow follows the step's on failure link if it has one.

Filters in data steps

Read data, Update data and Delete data select records with filter_conditions, a list of conditions that must all match:

[
  { "field": "status", "operator": "eq", "value": "pending" },
  { "field": "created_at", "operator": "lt", "value": "{{ $anythink.now }}" }
]

value can contain templates.

Warning: Operators other than these are ignored rather than rejected. For a Delete data step, a filter whose operators are all misspelled matches every record. Test delete steps against a copy of your data first.

Note: Values are added to the query as they are. Avoid values containing & in filters until this is handled.

Row-level security options

Steps run as the workflow worker, so records they create have no owner and aren't readable by users on entities with row-level security. Create data, Update data and Upsert data can grant access as part of the write:

A payload can also carry grants directly:

{
  "title": "Weekly check-in",
  "user_id": 21,
  "_rls": { "mode": "add", "users": [{ "user_id": 21, "readonly": false }] }
}

If a field named for grants is missing or can't be read, the step logs a warning and writes the record without that grant.

Limit: Update data ignores the row-level security options when it updates by ids. Use filters, or an _rls payload, to change grants.

Read data

Reads records from an entity.

Limit: Omitting limit currently fails validation with "Limit must be greater than or equal to 0" instead of falling back to 5000. Set limit explicitly until this is fixed.

Limit: anythink workflows step-add and step-update both silently rewrite a Read data step's entity parameter to entity_name, which then fails with "Entity is required". Neither CLI command can set a working Read data step yet — set parameters with a direct PUT /org/{orgId}/workflows/{workflowId}/steps/{stepId} call instead, until this is fixed.

Returns data: the list of records.

{
  "entity": "orders",
  "filter_conditions": [{ "field": "status", "operator": "eq", "value": "pending" }],
  "sort_by": "created_at",
  "sort_direction": "asc",
  "limit": 100
}

Reads ignore row-level security. Filter to the records the workflow should act on.

Create data

Creates one record, or one record per item in a list.

Returns data: the created records, or an empty list if every item was a duplicate. Fails when loop_over doesn't resolve to a list or a create fails.

{
  "entity_name": "order_reviews",
  "loop_over": "{{ $anythink.steps.large_orders.data }}",
  "payload": "{ \"order_id\": \"{{ id }}\", \"note\": \"Review orders over £100\" }",
  "prevent_duplicates": true
}

Update data

Updates records by id or by filter.

Returns data: the payloads that were sent (not the saved records). Fails when ids resolves to no numbers, or when neither ids nor filters are set.

{
  "entity_name": "orders",
  "ids": "{{ $anythink.trigger.id }}",
  "payload": "{ \"status\": \"reviewed\", \"reviewed_at\": \"{{ $anythink.now }}\" }"
}

Upsert data

For each item, finds a matching record by key fields, then updates it, leaves it, or creates a new one. Use it for imports and enrichment, where the same data may arrive more than once.

Returns data: one record per item, in the order of the input. Fails when an item is missing a match_on field.

When more than one record matches, the oldest (lowest id) is used and a warning is logged. Items are processed one at a time; if one fails, earlier items stay written.

{
  "entity_name": "customers",
  "loop_over": "{{ $anythink.steps.fetch_customers.data }}",
  "payload": "{ \"external_id\": \"{{ id }}\", \"email\": \"{{ email }}\", \"name\": \"{{ name }}\" }",
  "match_on": ["external_id"],
  "on_match": "Update",
  "update_fields": ["email", "name"]
}

Delete data

Deletes every record matching the filter.

Returns nothing, so later steps can't reference it. All matching ids are collected first and then deleted.

{
  "entity_name": "sessions",
  "filter_conditions": [{ "field": "expires_at", "operator": "lt", "value": "{{ $anythink.now }}" }]
}

Condition

Branches the workflow. When the conditions hold, the workflow follows on success; otherwise it follows on failure.

Text compares without regard to case. gt, gte, lt and lte compare as numbers when both sides are numbers.

Returns condition_result, logical_operator and evaluation_details, which lists each comparison with its actual value — useful when a branch goes the wrong way.

{
  "logical_operator": "AND",
  "filter_conditions": [
    { "field": "$anythink.trigger.data.total", "operator": "gte", "value": "100" }
  ]
}

Note: A false result with no on failure link ends the job as Failed. When "nothing to do" is normal, link the false branch to a harmless step.

Limit: is_null and is_not_null don't work reliably in conditions yet, because missing values are compared as text. Compare with eq and an empty value, or test for emptiness in Run a script.

Run a script

Runs JavaScript for logic that the other steps can't express: reshaping data, calculations, building prompts, parsing responses.

The script can read a $anythink object:

console.log, info, warn, error and debug write to the step's log. isArray, isObject and deepClone are available as helpers.

var orders = $anythink.steps.find_orders.data;
var total = orders.reduce(function (sum, o) { return sum + o.total; }, 0);
return { count: orders.length, total: total, over_budget: total > 5000 };

Scripts run on the Jint JavaScript interpreter with a 30-second timeout, 64 MB of memory and 100,000 statements. They have no network or file access, templates aren't applied inside scripts, and secrets aren't available — use Call an API or Integration for anything external.

Call an API

Sends an HTTP request.

Returns data: the parsed JSON response, or the part at results_path. Fails on a non-2xx status, with status_code and response in the output.

{
  "url": "https://api.example.com/v1/customers?updated_since={{ $anythink.steps.last_sync.data[0].synced_at }}",
  "method": "GET",
  "headers": { "Authorization": "Bearer {{ $anythink.secrets.example_api_key }}" },
  "results_path": "customers"
}

Note: An empty response stores no output. A response that isn't JSON, or a results_path that isn't found, succeeds with data set to {} — check the result in a Condition when it matters.

Note: Put credentials in headers, not in the URL. Request URLs are written to the step log.

Send an email

Sends one of your project's email templates. See Email templates.

Returns to, template_type, variables and attachment_count. Success means the email was queued for sending, not that it was delivered.

{
  "to": "{{ $anythink.trigger.data.email }}",
  "template_type": "welcome",
  "payload": "{ \"first_name\": \"{{ $anythink.trigger.data.first_name }}\" }"
}

Send a push notification

Sends a push notification through your configured providers and waits up to 30 seconds for the delivery result.

Send once per row. When the title, body or another content field refers to $anythink.steps.<key>.data[*], the step sends one notification per item in that step's data, with the item's fields available by name. Up to 10 send at once.

{
  "title": "{{ $anythink.steps.due_checkins.data[*].first_name }}, time for your check-in",
  "body": "It takes two minutes.",
  "audience": { "kind": "user", "user_id": "{{ $anythink.steps.due_checkins.data[*].user_id }}" }
}

Returns send_log_id, delivery_status, delivered, failed and unregistered; per-row sends return iterations and totals. The step fails if delivery fails — for per-row sends, only if every send fails.

File handler

Moves files in and out of records.

Downloads are limited to 50 MB and 30 seconds, and private or local network addresses are refused.

Returns file_id, url, mime_type, size_bytes and skipped, which is true when an existing file was kept.

{
  "operation": "FetchAndLink",
  "entity_name": "products",
  "record_id": "{{ $anythink.trigger.id }}",
  "field_name": "image",
  "source_url": "{{ $anythink.trigger.data.image_url }}",
  "skip_if_empty_source_url": true
}

Integration

Calls a connected service with your project's or a user's credentials. Connect services in Settings › Integrations.

Returns the service's result at the top level. AI text operations return text, model, input_tokens and output_tokens, read with {{ $anythink.steps.<key>.text }}.

{
  "provider": "claude",
  "operation": "generate-text",
  "credential_source": "system",
  "inputs": {
    "model": "claude-opus-4-8",
    "max_tokens": "2000",
    "system_prompt": "Summarise customer feedback in two sentences.",
    "prompt": "{{ $anythink.trigger.data.feedback }}"
  }
}

Limit: Claude models that start their reply with a thinking block, including Claude Opus 5, currently return empty text. Use claude-opus-4-8 until support lands. With no credentials connected, the step fails and tells you which service to connect.

Next steps

Every run of a workflow is a job, and Anythink keeps each job's payload, status and step-by-step results. That history is how you test a workflow and how you find out why one failed.

Test a workflow

In the Anythink dashboard

1. Open the workflow and select Test Workflow.
2. Choose an entity and a record to use as the trigger data, or edit the JSON payload directly.
3. Run it. The canvas highlights each step as it runs: running, succeeded or failed.
4. Select View Job History to see the job in full.

With the CLI

anythink workflows trigger 174
anythink workflows trigger 174 --payload '{"total":129.5,"status":"paid"}'

Limit: The CLI prints API error (204): Empty response even when the job was queued successfully — a 204 No Content is the documented success response, not an error. Check Job History, or anythink workflows jobs <id>, to confirm the run.

What a test run does

A test run works the same way for any trigger type, including timed workflows, which run once immediately without affecting their schedule.

Note: Test runs are real runs. Steps write data, call APIs and send email and push notifications. Test against sample records, or disable steps with side effects by routing around them while you build.

Job statuses

Reading a job

Job History lists the workflow's jobs, 25 per page, newest first. Open a job to see:

• Payload: the id, entity_name and data the job started with.
• Error: the message from the step that failed the job.
• Each step's log: what the step did, including resolved queries, request URLs and condition values.
• Each step's data: the output saved for later steps, or the failure details — for example the HTTP status and response from Call an API, or every comparison a Condition evaluated.

The job view refreshes every two seconds while a job is running.

Jobs from the API

GET /org/{orgId}/workflows/{workflowId}/jobs?page=1&pageSize=25
GET /org/{orgId}/workflows/{workflowId}/jobs/{jobId}

Both need anythink_workflows:read. Each job includes its status, payload, error_message, current_executing_step_key and a steps list with every step's success, log, data_json and error_message.

anythink workflows jobs <id> calls the same endpoint, but its list view doesn't surface that detail yet:

── Jobs (1) ────────────────────────────────────────────────────────────────────

  Job #133086 Success — ?

The ? stands in for fields the CLI doesn't render (payload, error message). Use anythink workflows step-get <workflow_id> <step_id> for a step's parameters, or call the API endpoints above directly for the full job, including each step's data_json.

Limit: anythink workflows list currently crashes with Value cannot be null. (Parameter 'text') once the project has a workflow with certain malformed trigger configuration. Use anythink workflows get <id> for a single workflow, or call GET /org/{orgId}/workflows directly, until this is fixed.

Re-running a job

Failed jobs aren't retried automatically. To run one again with the same input, copy the job's payload and start the workflow with it:

POST /org/{orgId}/workflows/{workflowId}/trigger
Content-Type: application/json

{ "entity_name": "orders", "entity_id": 1042, "data": "{\"total\":129.5,\"status\":\"paid\"}" }

data must be the payload's data as a JSON string. See Triggers and scheduling.

Why didn't my workflow run?

Keep logs useful and safe

• Step logs record resolved values, including request URLs. Send credentials in headers or integration connections, never in URLs or query strings.
• Use console.log in Run a script steps to record intermediate values while you build, and remove noisy logging once the workflow is stable.
• Give steps descriptive keys (find_due_orders, not step_2): keys appear in templates, logs and the job's current-step field.

Permissions

Project administrators have all of these. API keys need the exact permissions for the calls they make.

Next steps

What secrets are for

Any time a workflow needs to call an external API, it needs credentials — an API key, a bearer token, a webhook secret. Rather than pasting these values directly into your workflow configuration (where they would appear in logs and step outputs), you store them as secrets and reference them by name.

Secrets are encrypted at rest. Only the workflow engine can decrypt them at runtime, and only for the project they belong to.

Managing secrets

In the dashboard

Go to Settings → Secrets in your Anythink dashboard. From here you can:

• See all your stored secret keys (names only — values are never shown)
• Add a new secret
• Rotate (overwrite) an existing secret
• Delete a secret

Via the CLI

# List all secret keys
anythink secrets list

# Create a new secret (you will be prompted to enter the value securely)
anythink secrets create STRIPE_SECRET_KEY
anythink secrets create ANTHROPIC_API_KEY

# Rotate a secret (overwrites the existing value)
anythink secrets update STRIPE_SECRET_KEY

# Delete a secret
anythink secrets delete STRIPE_SECRET_KEY --yes

Values are entered via a hidden prompt — they are never visible in your terminal history or shell output.

Using secrets in workflows

Reference a secret in any workflow step that supports template syntax using:

{{$anythink.secrets.YOUR_KEY_NAME}}

The most common use is in the Call an API step headers or body. For example, to call an external API that requires an API key:

Headers:

{
  "Authorization": "Bearer {{$anythink.secrets.MY_SERVICE_TOKEN}}",
  "x-api-key": "{{$anythink.secrets.MY_API_KEY}}"
}

Body:

{
  "api_key": "{{$anythink.secrets.STRIPE_SECRET_KEY}}",
  "amount": "{{ $anythink.trigger.data.amount }}"
}

At runtime, the workflow engine decrypts the secret value and substitutes it into the payload before the request is made. The decrypted value never appears in job history or step logs.

Best practices

• One secret per credential — give each key a clear, descriptive name (STRIPE_SECRET_KEY not KEY1)
• Rotate regularly — use secrets update to rotate keys when you cycle credentials in external services
• Delete unused secrets — if a workflow no longer uses a secret, remove it to keep things tidy
• Never hardcode sensitive values — if you find a token or password pasted directly into a workflow step body, move it to secrets

System templates

Anythink maintains a set of system email templates, one for each triggered event. You can edit the subject line and body content of any template to match your product's tone and branding.

Editing a template

1. Go to Settings → Email Templates in your Anythink dashboard
2. Click the template you want to edit
3. Update the Subject and Body fields
4. Use the Preview button to see how the rendered email will look with real sample data
5. Click Save

Changes take effect immediately — the next time that event is triggered, the updated template is used.

Template variables

Each template has access to a set of variables that are automatically substituted at send time. Use double curly braces to insert them:

{{ OrgName }}
{{ Email }}
{{ ConfirmationUrl }}
{{ PasswordResetUrl }}
{{ InviteUrl }}
{{ DashboardUrl }}

Commonly used variables:

The available variables differ slightly between templates — use the Preview panel to see exactly which variables are in scope for each template.

Branding your emails

To make emails feel like they come from your product rather than Anythink:

• Set your organisation name in Settings → General — this populates {{ OrgName }} in all templates
• If you have white-labelling enabled, your logo and brand colours are applied automatically to the email wrapper
• Edit the body copy of each template to match your product's voice

Sender address

Emails are sent from Anythink's shared sending infrastructure. If you need emails to come from your own domain (e.g. noreply@yourapp.com), this is available on higher-tier plans — contact support to configure custom sending.

Each recipe is a full workflow you can rebuild and change. They show the patterns that come up most: importing data without duplicates, messaging many users individually, adding AI to a record, and keeping team data private.

Import customers from another system every night

Goal: keep a customers entity in step with an external CRM, updating existing customers and adding new ones, without creating duplicates when the job runs twice.

Trigger: Timed, 0 2 * * * (02:00 UTC).

fetch_customers:

{
  "url": "https://api.examplecrm.com/v2/customers?updated_within=24h",
  "method": "GET",
  "headers": { "Authorization": "Bearer {{ $anythink.secrets.crm_api_key }}" },
  "results_path": "customers"
}

upsert_customers:

{
  "entity_name": "customers",
  "loop_over": "{{ $anythink.steps.fetch_customers.data }}",
  "payload": "{ \"crm_id\": \"{{ id }}\", \"email\": \"{{ email }}\", \"name\": \"{{ full_name }}\", \"plan\": \"{{ plan }}\" }",
  "match_on": ["crm_id"],
  "on_match": "Update",
  "update_fields": ["email", "name", "plan"]
}

How it works:

• The API key lives in a project secret and goes in a header, keeping it out of the request URL, which is written to the step log.
• loop_over runs the payload once per customer, with each customer's fields available by name.
• match_on: ["crm_id"] makes the import safe to re-run: a customer that already exists is updated, never duplicated.
• update_fields stops the import overwriting fields your team edits in Anythink.

Adapt it: give crm_id a unique constraint so a manual edit can't create a second match, and add a File handler step if the CRM provides avatars — FetchAndLink with skip_if_empty_source_url: true.

Send each user a personalised reminder

Goal: every morning, remind users who haven't checked in this week, using their own name.

Trigger: Timed, 0 8 * * *.

due_checkins reads a checkin_status entity filtered on last_checkin_at lt your cut-off date, returning user_id and first_name.

remind:

{
  "title": "{{ $anythink.steps.due_checkins.data[*].first_name }}, how was your week?",
  "body": "Your check-in takes two minutes.",
  "click_action": "/check-in",
  "audience": { "kind": "user", "user_id": "{{ $anythink.steps.due_checkins.data[*].user_id }}" }
}

How it works:

• data[*] in the title and audience makes the push step send once per row, with each row's fields filled in. Up to ten send at a time.
• When nobody is due, the push step has nothing to send and succeeds with iterations: 0, so a quiet morning isn't a failed job.
• The step's output totals delivered, failed and unregistered devices, which you can see in Job History. It fails only if every send fails.

Summarise support tickets with Claude

Goal: when a ticket is created, add a two-sentence summary and a suggested priority.

Trigger: Event, EntityCreated on tickets.

summarise:

{
  "provider": "claude",
  "operation": "generate-text",
  "credential_source": "system",
  "inputs": {
    "model": "claude-opus-4-8",
    "max_tokens": "1000",
    "system_prompt": "You triage support tickets. Reply with only JSON: {\"summary\": \"two sentences\", \"priority\": \"low\" | \"normal\" | \"urgent\"}",
    "prompt": "Subject: {{ $anythink.trigger.data.subject }}\n\n{{ $anythink.trigger.data.body }}"
  }
}

parse:

var text = $anythink.steps.summarise.text || "";
var start = text.indexOf("{"), end = text.lastIndexOf("}");
if (start < 0) throw new Error("No JSON in reply: " + text.slice(0, 200));
var reply = JSON.parse(text.slice(start, end + 1));
return { ai_summary: reply.summary, ai_priority: reply.priority };

save:

{
  "entity_name": "tickets",
  "ids": "{{ $anythink.trigger.id }}",
  "payload": "{{ $anythink.steps.parse.data[0] }}"
}

How it works:

• The Integration step returns Claude's reply at the top level, so the script reads $anythink.steps.summarise.text.
• Parsing in a script means a malformed reply fails the job visibly instead of writing bad data.
• The whole payload of save is one template, so the script's object is written as-is.
• save updates by $anythink.trigger.id because trigger.data on a create doesn't include the new id.

Note: Use claude-opus-4-8 for now. Models that begin their reply with a thinking block, including Claude Opus 5, currently return empty text through the Integration step.

Share records with a user's team

Goal: when a coach logs a session note for an athlete, the athlete and everyone in their team can read it, but other teams can't.

Trigger: Event, EntityCreated on session_logs.

One Create data step writes the shared note with row-level security set from the athlete:

{
  "entity_name": "session_notes",
  "payload": "{ \"user_id\": \"{{ $anythink.trigger.data.athlete_id }}\", \"note\": \"{{ $anythink.trigger.data.summary }}\" }",
  "auto_set_rls": true,
  "rls_user_field": "user_id",
  "auto_set_rls_user_groups": true,
  "rls_user_group_mode": "all",
  "rls_user_groups_readonly": true,
  "rls_user_group_grant": true,
  "rls_user_group_field": "team_group_id"
}

How it works:

• Workflow writes have no owner, so without grants nobody but project administrators could read the note.
• auto_set_rls with rls_user_field gives the athlete read and write access.
• auto_set_rls_user_groups looks up the athlete's groups; rls_user_group_grant shares the note with every member, read-only.
• rls_user_group_field stamps the team's group id on the note, so you can filter and report by team.

Adapt it: leave rls_user_group_grant off when only staff should see team records; staff can still read them through group-scoped reads without every team member seeing each other's notes. See Roles and permissions.

Next steps