> ## Documentation Index
> Fetch the complete documentation index at: https://www.activepieces.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

This tutorial explains three techniques for creating triggers:

* `Polling`: Periodically call endpoints to check for changes.
* `Webhooks`: Listen to user events through a single URL.
* `App Webhooks (Subscriptions)`: Use a developer app (using OAuth2) to receive all authorized user events at a single URL (Not Supported).

to create new trigger run following command,

```bash theme={null}
npm run cli triggers create
```

1. `Piece Folder Name`: This is the name associated with the folder where the trigger resides. It helps organize and categorize triggers within the piece.
2. `Trigger Display Name`: The name users see in the interface, conveying the trigger's purpose clearly.
3. `Trigger Description`: A brief, informative text in the UI, guiding users about the trigger's function and purpose.
4. `Trigger Technique`: Specifies the trigger type - either polling or webhook.

# Trigger Structure

```typescript theme={null}
export const createNewIssue = createTrigger({
    auth: PieceAuth | undefined
    name: string, // Unique name across the piece.
    displayName: string, // Display name on the interface.
	description: string, // Description for the action
    sampleData: null,
    type: TriggerStrategy.WEBHOOK | TriggerStrategy.POLLING | TriggerStrategy.APP_WEBHOOK,

    props: {}; // Required properties from the user.
    // Set up the trigger. See "When the hooks run" below.
	onEnable: (ctx) => {},
    // Tear the trigger down. See "When the hooks run" below.
	onDisable: (ctx) => {},

    // Trigger implementation, It takes context as parameter.
    // should returns an array of payload, each payload considered
    run: async run(ctx): unknown[] => {}
})
```

> [!TIP]
>
> It's important to note that the `run` method returns an array. The reason for
> this is that a single polling can contain multiple triggers, so each item in
> the array will trigger the flow to run.

## When the hooks run

| What the user does | Polling trigger | Webhook / app webhook trigger |
| - | - | - |
| Turns the flow on | new `onEnable` | new `onEnable` |
| Turns the flow off, or deletes it | `onDisable` | `onDisable` |
| Publishes a flow that is off, turning it on | new `onEnable` | new `onEnable` |
| Republishes a running flow with the same piece, piece version, trigger and inputs | nothing, keeps polling on the same schedule | old `onDisable`, then new `onEnable`, both with `isRepublish: true` |
| Republishes a running flow with the same trigger and inputs on a newer piece version | new `onEnable` with `isRepublish: true` (the old `onDisable` is skipped) | old `onDisable`, then new `onEnable`, both with `isRepublish: true` |
| Republishes a running flow with a different trigger or changed inputs | old `onDisable`, then new `onEnable` | old `onDisable`, then new `onEnable` |

* A failing `onDisable` is logged and ignored, so the flow still turns off. A failing `onEnable` fails the publish or the turn-on.
* A patch upgrade in the builder (e.g. 0.5.1 → 0.5.3) keeps the trigger's inputs. A minor or major upgrade resets them to the new version's defaults. Which row applies depends on the inputs that get published: if they match the running flow, `context.isRepublish` is still `true`; if they differ, the trigger starts fresh. Don't rely on an upgrade to clear stored state.
* `context.isRepublish` is `true` only in the rows that say so. Use it to keep stored state that is still valid, rather than starting fresh. See [Polling Trigger → Republishing a running flow](https://www.activepieces.com/docs/build-pieces/piece-reference/triggers/polling-trigger.md#republishing-a-running-flow).
* A polling trigger's `onDisable` still runs when the flow is turned off or deleted, but not on an upgrade, because the trigger keeps running. If `onEnable` creates something outside the store, save its id in the store and, when `context.isRepublish` is `true` and the id exists, reuse it instead of creating another. If the trigger needs to register and unregister with every version, make it a webhook trigger: those run both hooks on every republish.
* `test` runs when the user loads sample data in the builder, and `run` runs on every poll or incoming event. Neither is part of turning the flow on or off.

## Context Object

The Context object contains multiple helpful pieces of information and tools that can be useful while developing.

```typescript theme={null}
// Store: A simple, lightweight key-value store that is helpful when you are developing triggers that persist between runs, used to store information like the last polling date.
await context.store.put('_lastFetchedDate', new Date());
const lastFetchedData = await context.store.get('_lastFetchedDate', new Date());

// Webhook URL: A unique, auto-generated URL that will trigger the flow. Useful when you need to develop a trigger based on webhooks.
context.webhookUrl;

// Payload: Contains information about the HTTP request sent by the third party. It has three properties: status, headers, and body.
context.payload;

// PropsValue: Contains the information filled by the user in defined properties.
context.propsValue;
```

**App Webhooks (Not Supported)**

Certain services, such as `Slack` and `Square`, only support webhooks at the developer app level.
This means that all authorized users for the app will be sent to the same endpoint. While this technique will be supported soon, for now, a workaround is to perform polling on the endpoint.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.