Privacy Policy — Alert Relay for Jira Service Management

• Provider: Individual Entrepreneur (FOP) Ivan Danyleiko, trading as Darkwood Apps
• Product: Alert Relay for Jira Service Management
• Website: darkwoodapps.com
• Privacy and support contact: support@darkwoodapps.com
• Last updated: 20 October 2026

1. Scope

This Policy explains information handled when a customer installs or uses Alert Relay. The app runs on Atlassian Forge and routes selected Jira Service Management Operations alerts to a Google Chat destination configured by the customer's administrator. Jira Service Management, Atlassian Marketplace, Google Workspace, and Google Chat are also subject to their own terms and privacy notices.

2. Information processed

For a native Operations Webhook request, the app receives the configured JSON request and uses an allow-list: action, alert ID, update timestamp, and recognized priority. For an escalation action whose sample omits an update timestamp, the app can use escalation time and repeat count. The app ignores descriptions, details, notes, message text, usernames, user IDs, teams, recipients, tags, and integration metadata.

An optional Jira Automation web-request fallback can provide an execution marker, alert ID, priority, status, owner or responder display names, and an alert link on the connected Jira site. The app validates that link against the connected site. Those display names may be personal data. The fallback is separate from the native Operations integration and depends on the customer's plan and Automation triggers.

During setup, the app reads the Jira site base URL and uses the signed-in administrator's account ID transiently to verify Jira administrator permission. It does not persist that Atlassian account ID. Connection settings include a connection name, site URL, active and audience-confirmation state, delivery policy, and timestamps.

3. Storage, destination, and logs

Pending alert records contain the allow-listed alert fields, delivery state, and metadata. Replay-deduplication and alert-state keys are hashes. The Google Chat incoming webhook URL and the per-connection JSM token are stored using Forge secret storage and are masked in the app interface.

Google Chat receives only the fields used in the selected alert card. For native Operations events that is the alert ID, action, and optional priority. Automation cards may also include status, owner or responder display names, and a validated alert link. The customer chooses the destination space and is responsible for its membership and retention.

The app does not operate a separate backend for Jira alert payloads. Runtime diagnostic logs use fixed codes and omit request bodies, alert IDs, names, token values, destination URLs, and exception details. The bounded in-app delivery journal contains delivery metadata such as connection, timestamps, outcome, HTTP status, and reason; it does not contain alert content.

4. Purposes and customer responsibilities

The app uses the information above to validate requests, apply delivery policies, queue and deduplicate events, send notifications, show delivery health, and support security and troubleshooting. The customer chooses which JSM actions to map and which Chat audience may receive alert information. Jira access permissions do not control membership of the destination Chat space.

5. Retention and deletion

• Pending and digest queue values use a two-day Forge KVS time-to-live, refreshed when queued data is updated. Failed immediate deliveries are retried up to five attempts before the app stops retrying that item.
• Accepted-event idempotency markers expire after ten minutes; hashed alert-state and sent markers expire after 35 days.
• The app retains at most the latest 100 delivery-journal entries per connection. The app does not set a per-entry TTL for those entries; deleting a connection or uninstalling the app removes its journal data through the cleanup path.
• Connection health data contains delivery counts, timestamps, and failure state, not alert content.
• A Forge pre-uninstall handler attempts to remove app records. Atlassian may retain soft-deleted Forge data for up to 28 days under its platform retention policy; the app cannot access that copy.
• Messages already delivered to Google Chat are separate copies governed by the customer's Workspace settings.

6. Access and security

The app uses the read:jira-work scope to read the site base URL and check the administrator's permission during setup; it does not read Jira issue records or subscribe to Jira issue events. The storage:app scope supports installation-scoped settings and queue state. Destination secrets use Forge secret storage. Outbound application requests are limited to the configured Google Chat webhook over HTTPS.

The customer should restrict access to the app administration page, store the one-time JSM token securely, and limit membership of the destination Chat space. Alert Relay does not sell information or use it for advertising.

7. Providers and international processing

Atlassian Forge hosts the app runtime and storage in the region selected for the customer's Atlassian site, subject to Atlassian's terms and subprocessor list. Google Chat is an external destination selected and controlled by the customer, not a destination selected by Darkwood Apps. Its processing and message retention follow the customer's Google Workspace configuration.

8. Requests and contact

For privacy, access, deletion, or security questions about Alert Relay, contact support@darkwoodapps.com. The customer may also need to contact Atlassian or Google about their respective services.

9. Children, advertising, and changes

Alert Relay is a business product and is not designed for children. The Provider does not sell personal information or use it for targeted advertising. This Policy will be updated if the app's processing changes.

See the Alert Relay Data Processing Addendum and Alert Relay Subprocessor List. Contact support@darkwoodapps.com with questions.