Triggers

​

What are triggers?

A Trigger is an event that automatically starts an Agent, transforming it from an on-demand tool into a proactive agent running in the background. You can set up Triggers to run Agents based on a schedule, specific events in your other software, or incoming webhooks.

​

Organize triggers with tags

Use trigger tags to label related triggers by team, workflow, customer, or purpose. Tags are shared across your workspace and can be created, renamed, recolored, or deleted from the tag picker on any trigger. On the main Triggers page, use the Tags section in the sidebar to filter the list. Selecting more than one tag shows triggers that have any selected tag.

​

How to create triggers

A new trigger starts with one question: when should it run? Pick a trigger type from the list, and the form shows that type’s settings, then which Agent runs and the inputs it gets. You can switch the type later from the menu at the top of the form. More options holds the timeout and tags. Under What should it do?, Extra instructions adds rules for this trigger only, such as which Slack channel to post to or what to focus on. Realm sends them to the Agent at the start of every run. Use them when several triggers share one Agent but need different rules. All trigger types include a Timeout setting. Choose 15, 30, 60, or 120 minutes, or choose Uncapped for runs that should not stop automatically. If you do not change this setting, Realm stops a trigger run after 60 minutes.

​

On a schedule

This trigger runs an Agent on a recurring, time-based interval. You can set it to run daily, weekly, or monthly. Choose how often it repeats (daily, weekdays, weekly, or monthly) and the time it runs. For a weekly schedule, also select the days of the week. The summary below the controls shows the complete schedule and the next run; the time zone is shown next to the time. Verify both before saving so the Agent runs at the intended local time. Example: An Agent could run every morning at 8 AM, scan your calendar for the day’s meetings, gather recent news and background information on the attendees and their companies, and deliver a concise briefing document.

​

When knowledge changes

This trigger runs an Agent automatically when synced knowledge changes in one of your connected systems. Use it when the Agent should react to new or updated records, documents, messages, tickets, calls, CRM objects, or activities. When you create a knowledge-event trigger, you define what starts the Agent, where it happens, and under what conditions. The configuration options are:

• Source: The connected application where the event originates, such as Gong, Salesforce, HubSpot, Slack, Google Drive, Jira, or Zendesk. Only connected sources are shown.
• Trigger when: The item type and change type that starts the Agent. Realm builds these options from the selected source’s supported content types, such as Opportunity updated, Deal updated, Ticket created, Call created, Thread created, or Thread reply added.
• Filter conditions (optional): Rules that control precisely when the Agent runs.
  • If: Set conditions based on the changed item. For example, only run the Agent when an Opportunity’s Stage changes to Closed Won, when an Owner field is not empty, or when a call’s duration is longer than 10 minutes. For Slack triggers, the Mentions and Reply Mentions fields match the people @-mentioned in the message, so an Agent can for example stay out of threads already addressed to named colleagues by requiring that Mentions is empty.
  • Folder or Channel: Restrict the trigger to a specific folder, channel, or similar location within the source application. Slack triggers require a channel. Other sources can usually be left unrestricted.
  • Bot messages: For Slack triggers, you can restrict which bots may start the Agent. An empty allowed-bots selection blocks every bot while still allowing messages from people. A workflow always ignores Slack messages produced by its own runs, even when other Realm messages are allowed. If you leave this off, messages from any bot or app (for example Linear or Jira notifications) can start the Agent.

​

Options of the Trigger when field

After you select a Source, Realm shows the event options available for that source. Each option pairs a supported item type with the event that can start the Agent: Some item types only support updated events, so you may not see both created and updated for every item type. Salesforce also includes shortcuts such as Task created and Event created for activity-style automation. For CRM automation, look for the CRM object in this menu rather than a separate generic event name. For example, a Salesforce Opportunity change is configured with Source = Salesforce and Trigger when = Opportunity updated. A HubSpot deal change is configured with Source = HubSpot and Trigger when = Deal updated.

​

Conditions on updated events

Updated events require at least one Filter condition. The Agent runs only when a condition field changed and the new value matches the condition. For example, to run when a Salesforce Opportunity is moved to Closed Won:

• Source: Salesforce
• Trigger when: Opportunity updated
• Filter condition: If Stage equals Closed Won

This means the Agent runs when the Opportunity’s Stage field changes to Closed Won. It does not run for every unrelated edit to the Opportunity. Filter conditions can match a specific value, exclude a value, check whether text contains a value, match any value from a list, or check whether a field is empty or not empty. Some fields can hold several values at once, such as Tags, Reviewers, Participants, and Mentions. A condition on these fields matches if any value matches. For example, If Tags equals escalated matches a ticket that has the escalated tag among its other tags. A condition that excludes a value, such as If Tags does not equal spam, matches only when no value is spam. On updated events, the Agent runs when the condition starts matching, for example when the escalated tag is added. It does not run again when other tags change on a ticket that already matched. Created and reply/activity-added events can be left without conditions. If you leave them unrestricted, the Agent runs for every new matching item in the selected Source and folder or channel. Example: Analyze a Gong call transcript Goal: Automatically summarize every new sales call, identify mentioned competitors, and extract action items.

• Source: Gong
• Trigger when: Call created
• Agent action: The Agent receives the call transcript, summarizes it, searches for competitor names against a predefined list, and sends a summary with action items to a specific Slack channel.

Example: Automate CRM updates Goal: When a deal is marked as “Closed Won” in Salesforce, automatically fill in a “Win Reason” field based on recent call notes and emails.

• Source: Salesforce
• Trigger when: Opportunity updated
• Filter: If Stage equals Closed Won
• Agent action: The Agent gathers context from recent activities, generates a concise “Win Reason”, and updates the corresponding field in Salesforce.

Example: React to a new CRM activity Goal: When a task or event is added to a Salesforce Opportunity, summarize what changed and notify the account owner.

• Source: Salesforce
• Trigger when: Opportunity activity added, Task created, or Event created, depending on the activity you want to catch
• Filter: Optional, such as If Reply Type equals Task
• Agent action: The Agent reads the Opportunity context and the new activity, then sends a Slack message to the owner.

Example: Sync Salesforce Opportunities to Google Sheets Goal: Keep a Google Sheet up to date when relevant Salesforce Opportunities are created or updated. Set up the Agent with these pieces:

• Add Salesforce as knowledge or as a tool, depending on whether the Agent only needs synced CRM context or also needs to run live Salesforce actions.
• Add the Google Sheets tool and enable the read and write actions the Agent needs.
• Make sure the spreadsheet is selected with Google Picker before the Agent writes to it. See Updating Google Sheets for the detailed setup.
• Set write actions to Ask while testing. Change them to On only after the Agent reliably writes the right rows and values.
• Use preset parameters for stable values the Agent should not choose, such as the Spreadsheet ID and a fixed sheet or range pattern.
• Let the Agent fill dynamic values, such as the row to update and the cell values, when those depend on the triggered Opportunity or the current sheet contents.

Then create a trigger:

• Source: Salesforce
• Trigger when: Opportunity created or Opportunity updated
• Filter: Add conditions for the changes you care about, such as If Stage equals Proposal or If ARR Growth is greater than 100000.
• Agent instructions: Tell the Agent to read the triggered Opportunity, check whether that Salesforce Opportunity ID already exists in the sheet, then update that row or add a new row.

Use a stable unique key, such as the Salesforce Opportunity ID, to match CRM records to spreadsheet rows. Names can change and are not always unique.

​

Webhook

This trigger runs an Agent when it receives an HTTP request from an external system. This is a powerful way to integrate with internal tools or any third-party platform that can send webhooks, even if it doesn’t have a direct integration with Realm. To set up a webhook trigger:

1. Select trigger type: Choose “Webhook” under When should it run? when creating your trigger.
2. Copy the webhook URL: Realm will generate a unique URL for this trigger. Copy this URL.
3. Configure the external system: Paste the copied URL into the webhook configuration section of the external tool you want to trigger the Agent from.
4. Choose authentication (optional): Select an authentication method to secure your webhook and ensure only authorized systems can trigger your Agent.

For a custom webhook, Additional authentication offers these choices: Example: A “Contact Us” form on your website could send a webhook to Realm for each new submission. An Agent could then analyze the submission, create a new lead in your CRM, and notify the appropriate sales representative in Slack.

​

Project status changes

This trigger runs an Agent when a project’s status changes, for example when a project is marked Completed. Use it to post updates to other systems as your projects move through their lifecycle. To set up a project status trigger:

1. Select trigger type: Choose “Project status changes” under When should it run? when creating your trigger.
2. Choose statuses: Check the statuses that should start the Agent. With nothing selected, every status change starts it. A category’s built-in status, such as Drafting, starts the Agent whenever a project enters that category; a custom status starts it when a project moves into that exact status. See Project statuses.

The Agent receives the project name, a link to the project, and the old and new status, using your organization’s status names. When the project is linked to a CRM opportunity, it also receives the opportunity name, account, and link. Example: When a project is marked Completed, an Agent could summarize the outcome and post an update to the linked Salesforce opportunity as a note.

​

New project

This trigger runs an Agent when a project is created. Use it to do the first pass of work on every new bid, such as reading the tender documents and drafting a brief. To set up a new project trigger:

1. Select trigger type: Choose “New project” under When should it run? when creating your trigger.

There is nothing else to configure. Every project created in your organization starts the Agent once. The Agent does not start the moment the project appears. Realm waits until the project has left the setup wizard and every file in it has finished processing, so the Agent can read the files rather than find them half parsed. A project whose files are still being processed starts its Agent when the last file is done, which can be several minutes after the project was created. The Agent receives the project name, its project id, a link to the project, the description and deadline if they are set, and the names of the project’s files. When the project is linked to a CRM opportunity, it also receives the opportunity name, account, and link. The Agent can read any of the files by listing them from the project and then reading the file it needs. Each project starts the Agent at most once. Adding more files later does not start it again, and a trigger you create today does not run for projects that already exist. Example: When a new project is created, an Agent could read the tender documents, summarize the scope, deadlines, and mandatory requirements, and post that brief to the bid team’s Slack channel.

​

Run history and monitoring

You can monitor a trigger from the Agents > Triggers list and from the trigger’s detail page. In the list view, each trigger shows its Last run and Status, which makes it easy to scan whether a trigger is active and when it last ran. Use the search field to find a trigger by name. The list can be narrowed by trigger Type (Schedule, Event, or Webhook), Status (Active, Paused, or Waiting for user), and ownership (All automations or My automations).

​

Trigger details page

On the trigger detail page, the Runs card lists individual runs for that trigger, newest first. Each run shows when it started, what started it (Scheduled, Run by hand, a retry, or the document or event behind it), how long it took, and its outcome, such as Completed, the error, or why it was skipped or stopped. Select Show more to load older runs. Use the All and Problems filters to switch between every run and only the runs that failed, timed out, or are waiting for someone to respond. From a run you can:

• Open the run’s chat to see what the Agent did
• Select Respond on a run that is waiting for someone, to answer the Agent’s question
• Select Retry on a run that failed, timed out, or was canceled, to start it again

For scheduled triggers, the side panel shows the next run and the upcoming run times, along with the trigger’s state, whose access it runs with, and run stats.

​

What you can see

• Trigger status in the list view, such as Active
• Last run in the list view
• Runs on the trigger detail page
• Configured timeout on the trigger detail page, in the How it works card
• Run outcome for each run, such as Completed or the reason it stopped

​

Why it is useful

Use run history to:

• Confirm that a trigger is firing as expected
• Check when the trigger last ran and when it runs next
• Review whether recent runs completed successfully
• Find and retry runs that need a look
• Manually run a trigger with its normal input, a selected document, a webhook payload, or raw text input when testing

​

Monitoring tips

• After creating a trigger, check its Status and Last run in the list view to confirm it is active and running
• Open the trigger detail page to review its Runs
• Use the Problems filter to find runs that failed or need a response

​

Sharing and permissions

A trigger has one owner and can be shared with other people in your organization. New triggers are private to their owner until the owner shares them. Triggers that were created before sharing was introduced stay visible to everyone in your organization.

​

Roles

• Owner: The person who created the trigger. An owner can do everything an editor can do, and can also delete the trigger, manage its access list, and transfer ownership to someone else.
• Editor: Can change the trigger’s configuration, enable or disable it, run it now, and retry, cancel, or resume runs. An editor cannot delete the trigger, share it, or transfer ownership.
• Viewer: Can open the trigger and read its configuration and run history. A viewer cannot change the trigger, its tags, and cannot start a run.

Only full members and admins can be added to a trigger, because viewing, changing, and running a trigger are all full-member actions. Collaborators cannot be given access to a trigger.

​

Who can see a trigger

The owner chooses between two levels of visibility from the sharing menu:

• Private: Only the owner and the people on the access list can see the trigger. Add people individually and choose whether each of them is a viewer or an editor.
• Everyone in your organization: Anyone in your organization can open the trigger and follow its runs. Changing or running the trigger still requires the editor role.

You can switch between these two options at any time, and the named people on the access list keep the roles you gave them.

​

Organization admins

Organization admins can see every trigger and can pause or resume any of them without being added to the access list. When an admin needs to change a trigger, they can grant themselves edit access in one click. That grant then appears in the trigger’s access list, so the owner can always see who has access.

​

Runs use the owner’s permissions

Run status, timing, and errors are visible to editors and viewers. The chat transcript of a run is not shared: it stays with the person whose run created it. Because of this, an editor can only pick an agent that the owner can reach, and the Google Calendar connection of a calendar trigger can only be changed by the owner. An editor sees the owner’s calendar selection but cannot swap in their own connection.

​

Transferring ownership

An owner can transfer a trigger to another full member or admin of the organization. The previous owner stays on the access list as an editor, so they can keep working on the trigger without owning it. Because later runs use the new owner’s permissions, a transfer is refused when the new owner cannot reach the trigger’s agent, and a calendar trigger can only be transferred to someone who has access to its Google Calendar connection.

​

Triggers that need attention

A trigger stops running when it can no longer work as configured:

• Its agent was deleted or unpublished
• Its owner was removed from the organization
• Its owner no longer has access to its agent

The next time such a trigger fires, Realm skips the run and marks the trigger Needs attention in the triggers list and on its detail page, with the cause and what to do about it. The trigger’s owner and your organization admins get one notification, in the app and by email. Fix the cause (for example, publish the agent or transfer the trigger to an active member) and the trigger resumes on its next fire. If the trigger is still broken 7 days after it was first marked, its next fire turns it off and Realm notifies the same people again. Turn the trigger back on once it is fixed. Temporary problems during a run, such as a timeout or an error from a connected tool, do not mark a trigger. Those runs show as failed in the run history.

​

Troubleshooting a trigger

If a trigger does not run as expected:

• Confirm the trigger is enabled and does not show Needs attention
• Check that the trigger conditions are correct
• Verify that the source system is sending the event or webhook
• Review the most recent run history for errors or skipped runs

Run history gives you visibility into how your Agents behave over time, making it easier to monitor, debug, and trust automated workflows.