> For the complete documentation index, see [llms.txt](https://sandgarden.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sandgarden.gitbook.io/docs/publications/configure-triggers.md).

# Configure Triggers

This guide explains how to configure automatic trigger behavior for an existing Publication. See [Concepts](/docs/overview/concepts.md) for Publication and Source definitions. Use it when a Publication should react to new activity in one of its connected Sources.

### Where trigger settings live

Each Source in a Publication has its own trigger settings on the Publication form. Open the Publication, go to **Inputs**, and use **React to** to add triggers for a selected Source. The **Add Triggering Event** control only shows Sources that appear in **Inputs** and can emit at least one trigger event.

![A Publication's React to section with triggering events enabled for a GitHub Source](/files/1FPalwrpPM5v8NlOiuEJ)

### Trigger events by Source type

| Event concept        | On-screen label                                                                                 | Supported Sources                                                                                               |
| -------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| Merged pull requests | GitHub and Bitbucket Sources show **Pull Requests**, and GitLab Sources show **Merge Requests** | GitHub repository, GitHub access-token, GitLab, GitLab project, Bitbucket repository, Bitbucket project         |
| New issues           | **New Issues**                                                                                  | GitHub repository, GitHub access-token, GitLab, GitLab project, Linear                                          |
| Issue comments       | **Issue Comments**                                                                              | GitHub repository, GitHub access-token, GitLab, GitLab project, Bitbucket repository, Bitbucket project, Linear |
| Releases             | **Releases**                                                                                    | GitHub repository, GitHub access-token, GitLab, GitLab project                                                  |
| Send to Doc          | **Send to Doc**                                                                                 | Jira project, Atlassian Forge Jira project                                                                      |
| Issue status changes | **Issue status changes to:** and **Select statuses...**                                         | Jira project, Atlassian Forge Jira project                                                                      |

> Note: After an administrator selects **Releases**, the form displays **React to pre-releases** only for GitHub repository and GitHub access-token Sources. Selecting the option makes the Publication react to both full releases and prereleases for that Source. Clearing it makes the Publication react only to full releases. GitLab Sources support **Releases**, but do not display **React to pre-releases**. See [Trigger and Event Types](/docs/reference/trigger-and-event-types.md) for the compatibility lookup table.

### Add and remove triggers

1. Open the Publication you want to update.
2. Go to **Inputs**.
3. Select **Add Triggering Event**.
4. Choose a Source from the list.
5. Select the triggers that Source supports. For Jira Sources, choose one or more statuses with **Select statuses...**.
6. For each GitHub repository or GitHub access-token Source, select **Releases**. The form then displays **React to pre-releases**. Keep the option selected for the Publication to react to both full releases and prereleases for that Source. Clear it for the Publication to ignore prereleases and react only to full releases. Configure this choice independently for each Source. With the option cleared, Doc Holiday omits prereleases from release comparisons and uses the newest stable, non-draft release.
7. Save the Publication.

> Note: Existing Publications require no migration and preserve the prior behavior. Each Publication continues to react to prereleases for a Source until an administrator clears **React to pre-releases** for that Source.

To remove a trigger setup, use the trash button on the Source card. Removing the Source from **Inputs** also clears that Source's trigger settings.

> Note: Manual requests from git or from the app still work even when no triggers are configured. See [Request work in git](/docs/working-with-doc-holiday/request-work-in-git.md) and [Request work in the app](/docs/working-with-doc-holiday/request-work-in-the-app.md).

> Note: Doc Holiday does not offer a scheduled or cron trigger. Use [GitHub Action](/docs/automation-and-integrations/github-action.md) for scheduled or release-driven runs.

### Verify

For a configured GitHub Source, clear **React to pre-releases**, publish a GitHub prerelease, and open [Work History](/docs/working-with-doc-holiday/work-history.md). Confirm that the prerelease creates no new entry for the Publication. Publish a full release and confirm that a new entry appears. If an administrator leaves **React to pre-releases** selected, confirm that both a prerelease and a full release create a Work History entry for the Publication.

***

<p align="center"></p>

<p align="center">Docs authored by <a href="https://doc.holiday">Doc Holiday</a></p>
