> For the complete documentation index, see [llms.txt](https://docs.currents.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.currents.dev/guides/currents-actions/lifecycle-notifications.md). # Lifecycle Notifications Configure and receive action lifecycle notifications Action lifecycle notifications inform teams when actions are created, disabled, re-enabled, archived, expired or approaching expiration. Currents delivers these notifications to Slack, email, or both. This provides visibility into changes and upcoming expirations without requiring visiting the dashboard. Teams receive timely updates, allowing them to respond before a forgotten quarantine leads to unexpected test failures. Notification settings are configured entirely in the dashboard. The REST API can create and manage actions, but notification routing is configured per project in the **Action > Notification Settings** page.

### Configuration and Delivery #### Slack Enabling Slack notifications requires two steps: 1. **Connect Slack to the organization** following the [Slack App](/resources/integrations/slack/slack-app.md#installation). {% hint style="info" %} A **Currents organization administrator** must connect, re-authenticate, or disconnect the integration. A **Slack administrator** must authorize the app; the exact required Slack role depends on whether the account uses a single workspace or Enterprise Grid. {% endhint %}

2. **Enable Slack notifications** in the Action Settings page: * select a channel * choose the events Connecting Slack under Integrations alone does not enable notifications, they must be configured on this page.

Once Slack is connected, anyone with **Actions Admin** access can configure the channel and events. If the Slack option is unavailable, a Currents organization administrator must complete the Integrations setup first. #### Email Email is configured on the same page. Slack and email are independent - either or both can be enabled.

Recipients include: * **Action creator** - always listed, but mail is sent only when the creator value is a valid email address. * **Organization administrators** and **action administrators** - optional. * **Additional emails** - up to ten extra addresses. {% hint style="warning" %} **Action creator notice** When an action is created via the REST API, the creator is stored as the API key label, which is not an email address and does not receive creator mail. For API-driven workflows, add additional emails or enable admin recipients. {% endhint %} {% hint style="info" %} **Notification attribution** Every notification displays the original creator of the action. For disable, re-enable, and archive events, the notification also identifies who performed the action: the signed-in user (dashboard) or the API key label (REST API). Expiring and expired notifications are system-triggered and display only the original creator. {% endhint %}

### Available Events Each event can be enabled or disabled separately for Slack and email. | Event | What triggers it | | --------------------- | ------------------------------------------------------------------------------------------------------ | | **Action created** | A new action is created. | | **Action disabled** | An action is manually disabled while it has not yet expired. | | **Action re-enabled** | A disabled action is re-enabled while it has not yet expired. | | **Action archived** | An action is archived (soft-deleted) via the REST API. | | **Action expiring** | An active action will expire within the next 12 hours. | | **Action expired** | An action's expiration time passed within the last 12 hours (older expirations do not trigger alerts). | ### Important Notes **Expiring** and **expired** notifications both use a 12-hour window. Expiring looks ahead: the expiration falls within the next 12 hours. Expired looks back: the expiration occurred within the last 12 hours. If an expiration is set or changed very close to the actual moment, within that same 12-hour window, Currents may skip the expiring or expired notification to avoid redundant alerts. Additional edge cases: * **Already expired, then disabled:** no "action disabled" notification is sent. * **Re-enabled while still expired:** no "action re-enabled" notification is sent. This event applies only when the action is not expired at the time it is re-enabled. * **Bulk changes:** each qualifying action receives its own notification. There is no combined digest for batch operations.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.currents.dev/guides/currents-actions/lifecycle-notifications.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.