Automations and apps

A workflow is either callable (your code or a webhook calls it and it returns a Result) or an automation: an app event starts it, it decides with AI Nodes and logic, and it acts in your apps. Both run on the same engine, with the same versions, tests, limits, and billing.

What starts a workflow

The first step of every workflow is its trigger. Choose it under Triggers in the Studio node library, or in the first step's settings:

• API request: POST /v1/workflows/{id}/execute with the input fields you define (see Workflows API), or a webhook trigger.
• Schedule: On a schedule: Runs every few minutes or hours, or daily or weekly at a time you choose. The event's fields (scheduled_at, fired_at) are the workflow's input, as input.<field>.
• Gmail: New email: Triggers when a new message is received in Gmail. The event's fields (from, body_text, received_at, labels, message_id, thread_id, to, subject) are the workflow's input, as input.<field>.
• Slack: New message: Triggered when a message is posted in a Slack channel (public, private, or multi-party IM). The event's fields (attachments, blocks, bot_id, channel, channel_type, files, subtype, team_id, text, thread_ts, ts, user) are the workflow's input, as input.<field>.
• Slack: Reaction added: Triggered when a reaction is added to a message in Slack. The event's fields (event_ts, message_channel, message_ts, message_user, reaction, team_id, user) are the workflow's input, as input.<field>.
• GitHub: Issue opened or changed: Triggered when a new issue is added to the repository. The event's fields (action, created_at, created_by, description, issue_id, number, title, url) are the workflow's input, as input.<field>.
• GitHub: Pull request opened or changed: Triggered when a pull request is opened, closed, or synchronized. The event's fields (action, created_at, created_by, description, number, title, url) are the workflow's input, as input.<field>.
• GitHub: New commit: Triggered when a new commit is pushed to a repository. The event's fields (author, id, message, timestamp, url) are the workflow's input, as input.<field>.
• Google Sheets: New rows: Simple polling trigger that monitors Google Sheets for new rows. The event's fields (detected_at, row_data, row_number, sheet_name, spreadsheet_id) are the workflow's input, as input.<field>.
• Notion: Page created: Triggers when a new Notion page is created. The event's fields (page_id, event_id, timestamp, workspace_name, authors) are the workflow's input, as input.<field>.
• Linear: Issue created: Triggered when a new issue is created. The event's fields (issue_id, identifier, title, description, priority, action, data, type, url) are the workflow's input, as input.<field>.
• Linear: Issue updated: Triggered when an issue is updated. The event's fields (issue_id, identifier, title, description, priority, action, data, type, url) are the workflow's input, as input.<field>.
• Linear: Comment added or changed: Triggered when a comment is received. The event's fields (comment_id, body, issue_id, action, data, type, url) are the workflow's input, as input.<field>.
• Outlook: New email: Triggered when a new message is received in the Outlook mailbox. The event's fields (message_id, subject, preview, from, received_at, conversation_id, web_link, has_attachments, event_type) are the workflow's input, as input.<field>.
• Jira: Issue created: Triggers when an issue is created in Jira, including a sub-task. The event's fields (issue_id, issue_key, issue, user) are the workflow's input, as input.<field>.
• Jira: Issue updated: Triggers when a field on an existing issue changes — its status, assignee, or anything else on the issue. The event's fields (issue_id, issue_key, issue, changelog, user) are the workflow's input, as input.<field>.
• Jira: Comment added: Triggers when a comment is posted on a Jira issue. The event's fields (comment_id, comment, issue_key, issue) are the workflow's input, as input.<field>.
• Salesforce: New lead: Triggers when a new Lead is created in Salesforce. The event's fields (lead_id, name, lead) are the workflow's input, as input.<field>.
• Salesforce: New or updated opportunity: Triggers when a Salesforce Opportunity is created or updated. The event's fields (event_type, opportunity) are the workflow's input, as input.<field>.
• Shopify: Product created: Triggers when a product is created, from the admin, the API, an import or an app. The event's fields (id, title, handle, product_type, vendor, status, tags, variants, created_at) are the workflow's input, as input.<field>.
• Shopify: Product updated: Triggers when any field of a product changes, as one delivery per edit rather than one per field. The event's fields (id, title, handle, product_type, vendor, status, tags, variants, updated_at) are the workflow's input, as input.<field>.
• Shopify: Variant out of stock: Triggers when a variant's stock crosses to zero across every location, not on every sale. The event's fields (id, product_id, title, sku, price, inventory_item_id, inventory_quantity, old_inventory_quantity, inventory_policy) are the workflow's input, as input.<field>.
• Shopify: Variant back in stock: Triggers when a variant's stock crosses back above zero across every location, not on every restock. The event's fields (id, product_id, title, sku, price, inventory_item_id, inventory_quantity, old_inventory_quantity, inventory_policy) are the workflow's input, as input.<field>.
• Shopify: Inventory level updated: Triggers when the quantity of an inventory item changes at a location, in either direction, once per location affected. The event's fields (inventory_item_id, location_id, available, updated_at) are the workflow's input, as input.<field>.

An automation can still be run from the API or the Test panel with an input shaped like its event, for example to test it or to process an older message. Its Result step is optional: an automation that only acts doesn't need one.

Acting in your apps

Under Actions, each app lists what a workflow can do in it, such as add label (Gmail), remove label (Gmail), mark as read (Gmail), archive (Gmail), reply (Gmail). Map their inputs like any step, for example input.message_id from the trigger. Steps that are safe to repeat are retried when the app is briefly unavailable; steps that aren't (sending a reply) are attempted once. Studio tests and Instant Workflow trials simulate them with a sample result; turn on Send real requests in the Test panel to act for real. The generic HTTP request step is still there for any other API.

Connecting an app

Connect an account once (from a step's settings or Workspace → Connections) and every workflow in the workspace can use it. You sign in on the app's own page. Kovca's integration provider, Composio, holds the access, uses it only for that app, and Kovca keeps only an ID for the account. Nobody can see the access again. If the app stops accepting it (you revoked it, or it expired), the connection shows Needs reconnecting and automations using it wait: reconnect and they continue. Disconnecting revokes Kovca's access.

Activating an automation

Building and activating are separate. The Studio's Activate button lists what's left (connect the app, choose the account in each step, fix problems, test with a sample event) and then activates the automation. Publish & activate publishes your latest changes as a new version and starts it in one step. A live automation runs a pinned published version: later edits don't reach it until you choose Publish & update (or Update to vN for a version you already published), which continues from the same position, so no event is missed or repeated. Statuses:

• Active: new events run within about a minute (as soon as the app sends them, for apps that send events).
• Waiting: runs were refused (monthly usage limit, spending cap, or rate limit). Schedule events wait in order and run once they can; none are dropped. Apps that send their events resend refused ones for a while; an event they stop resending is skipped.
• Needs attention: reconnect the account, update a version that can't run, or check recent failed runs (new events keep running).
• Paused: schedule events that arrive meanwhile run when you resume; app events are skipped while paused.

Reliability

• Each event runs once. Kovca records every event it sees (its ID only, for 14 days), so a restart or a resent event never runs it twice. Schedule triggers move past an event only once its run has started, so they never skip one either.
• Schedule events run oldest first. A large backlog is processed in batches until it's done.
• A failed run isn't retried automatically, because its actions may already have happened. Kovca doesn't keep app events, so run it again with the event's values.
• Event runs appear in Executions as Automation, are billed like any run, and send outbound webhooks.
• Kovca never stores email or event content: only event IDs, positions, counts, and timings. Actions and events in apps connected through Composio pass through Composio.
• An item an automation creates (a message it posts, an email it sends) never starts that automation again, where the app identifies it.

Gmail

The Gmail trigger runs for new messages in a label (Inbox by default), optionally matching a Gmail search such as subject:(conference OR summit) -from:me. New mail is checked about every two minutes. Gmail is connected through Composio, so the Google sign-in page names Composio. Add label and Remove label take label IDs (system labels like STARRED, or a custom label's ID); Mark as read, Archive, Reply, and Send email need no label.

Instant Workflows

A shared automation shows which app event starts it. Visitors run it on the sample event (which they can edit), app actions return sample results, and nothing is sent. Saving your own copy leaves out the sharer's accounts; the new owner connects their own app and activates it.