Data Processing Addendum — Alert Relay for Jira Service Management
Last updated: 20 October 2026 Draft for Owner review; this product is not yet publicly listed.
This service-specific schedule describes processing for Alert Relay. It is intended to accompany the data-processing terms accepted for the customer's Marketplace purchase, where applicable.
Parties and service
| Item | Details |
|---|---|
| Provider / Processor | Individual Entrepreneur (FOP) Ivan Danyleiko, trading as Darkwood Apps. |
| Customer / Controller | The customer identified in the applicable order. The customer is the Controller unless it processes data for another Controller, in which case it acts as a Processor and must pass through documented instructions. |
| Service | Alert Relay for Jira Service Management, an Atlassian Forge app that routes selected JSM Operations alerts to a customer-selected Google Chat destination. |
| Duration | For the term of the agreement that incorporates this schedule, followed by the retention and deletion periods below. |
Processing details
- Purpose: validate and normalize alert requests, apply the configured priority/digest policy, queue and deduplicate events, deliver selected alert information, show delivery health, and provide support and security.
- Instructions: the customer's configuration and use, including mapped JSM actions, selected Google Chat destination, delivery threshold, digest interval, and any optional Automation rules.
- Data subjects: customer administrators and, when Automation supplies display names, JSM responders or alert owners. Alert IDs and event metadata may also relate to individuals depending on the customer's use.
- Personal data: transient administrator account ID for the permission check; alert IDs, action, timestamp, priority and status; optional Automation owner/responder display names and validated same-site alert link; connection settings and delivery state; Google Chat webhook URL and JSM token.
- Special-category data: the service is not designed to request or process special-category data. Customers should not configure payloads to send such data.
- Operations: receipt, validation, field allow-listing, temporary Forge KVS queueing, replay/state hashing, disclosure to the selected Chat destination, bounded delivery journaling, expiry, and deletion.
Retention and deletion
- Pending and digest queues 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 markers expire after ten minutes. Hashed state and sent markers expire after 35 days.
- Each connection retains at most 100 delivery-journal entries. The app does not set a per-entry TTL; connection deletion or uninstall triggers the cleanup path.
- The app does not persist the administrator's Atlassian account ID. The pre-uninstall handler attempts to remove app records. Atlassian may retain soft-deleted Forge data for up to 28 days under its platform policy; the app cannot access that copy.
- Google Chat messages already delivered are separate copies governed by the customer's Workspace retention settings.
Providers and destination
Atlassian Forge provides runtime, events, installation-scoped storage, and secret storage. See the Alert Relay Subprocessor List and Atlassian's official subprocessor list.
Google Chat is the destination selected and controlled by the customer. It is an external recipient and processing path, not a provider appointed by Darkwood Apps as a subprocessor for Alert Relay.
Security measures
- Connection secrets use Forge secret storage; the destination URL is masked in the app UI.
- Backend egress is limited to the configured Google Chat webhook endpoint over HTTPS. Darkwood Apps does not operate a backend that receives alert payloads.
- The native Operations path uses an allow-list and ignores descriptions, details, notes, messages, user IDs, teams, and recipients. The optional Automation path validates alert links against the connected Jira site.
- Diagnostic logs omit alert payloads, identifiers, names, tokens, webhook URLs, and exception details. The bounded journal contains delivery metadata only.
- The customer controls access to Jira administration and the destination Chat space.
Incident notice
The Provider will notify the customer at support@darkwoodapps.com without undue delay and no later than 48 hours after becoming aware of a personal data breach affecting the Service, subject to applicable law and the agreement incorporated between the parties.
International transfers
Atlassian Forge and Google Workspace process data under their respective terms and customer configurations. This schedule does not promise that customer content is processed only in Ukraine. If and only if the EU Standard Contractual Clauses module in the incorporated DPA applies, the designated governing law and courts for that module are those of Ireland.
For privacy practices, see the Alert Relay Privacy Policy. Contact support@darkwoodapps.com with questions about this schedule.