VIVID INSIGHTSecurity, Data Handling, and Current Release Scope
Review Jira permissions, Forge storage, Telegram delivery, data protection, and the capabilities supported by the current release.
- Last verified
- Product
- Vivid Connector for Jira and Telegram
Access model
Vivid Connector for Jira and Telegram runs as an Atlassian Forge app in Jira Cloud and communicates with the Telegram Bot API at api.telegram.org. Configuration takes place on a Jira administration page. Your organization uses its own Telegram bot and controls the chats that bot can access.
Before enabling notifications, an administrator must confirm that the membership of each Telegram chat is appropriate for the sensitivity of the selected Jira projects. After a message is delivered to Telegram, it is available to chat participants according to Telegram's chat settings and retention behavior.
Vivid Connector for Jira and Telegram is a paid Marketplace app. In production, user actions, Jira event handling, scheduled jobs, and Telegram processing require an active Marketplace license. When the subscription is inactive, configuration and delivery are paused; stored customer configuration is not automatically deleted.
Jira permissions requested by the app
read:jira-work— read issues, fields, projects, comments, and other data required for filters and messages;read:jira-user— resolve display names for assignees, reporters, actors, and user-picker custom fields;storage:app— store the secret, channel configuration, and technical delivery state.
Data stored by the app
Data | Purpose and storage |
|---|---|
Telegram bot token | Forge secret storage. The usable token is never returned to the UI. |
Bot name and username, webhook URL, and webhook secret | Forge KVS for status display and webhook maintenance. The webhook secret is stored as a secret and is never shown in the UI. |
Temporary verification code and status | Forge KVS. The code is valid for five minutes, and the outcome is retained temporarily for the setup wizard. |
Chat ID, topic/message-thread ID, type, chat and observed topic names, username, description, member count, and status | Forge SQL for exact root/topic routing, recognizable destination labels, channel management, and availability checks. |
Project keys, event types, ticket-parsing setting, and filter expression | Forge SQL as the configuration for a specific root or topic destination. |
Delivery snapshots and message parts; fingerprint, issue key, event type, status, attempts, and error | Forge SQL for delivery and duplicate prevention. Customer content is cleared after terminal delivery or the one-hour delivery window; non-content operational metadata is retained for 14 days and cleaned up incrementally. |
Ten latest event outcomes | Compact technical history used by Recent activity, including the group/topic destination label when applicable. Outcomes remain until later outcomes overwrite them or the app installation is removed; there is no separate time-based expiry. |
The generated notification text passes through a Forge asynchronous queue and is sent to Telegram. Jira fields included in the message may then be retained by Telegram according to the chat configuration and Telegram policies.
Token and content protection
The token is validated with Telegram before storage.
The UI displays only a masked token value.
Every Telegram webhook request must use POST, stay within the configured body-size limit, and carry the exact installation-scoped secret supplied during webhook registration.
Jira values are escaped before they are inserted into Telegram HTML.
Application logs contain only fixed operational states, counts, status codes, and sanitized error metadata. They omit customer identifiers, Jira and Telegram content, bot tokens, webhook secrets and complete URLs, Jira API response bodies, delivery fingerprints, and arbitrary upstream error messages.
Each outgoing logical event receives a unique fingerprint to prevent duplicate messages when Forge redelivers an event.
Outgoing Telegram sends are serialized and persistently paced per installation to enforce the documented global request limit in addition to per-chat pacing.
Customer bot configuration and its bot token are scoped to the app installation.
Complete legal terms for data processing and retention are provided in the Privacy Policy and Data Processing Addendum. This page is an operational description, not a replacement for those legal documents.
Current release boundaries
The current release supports channel and group notifications, independently configured forum topics, advanced filters, and Jira-key parsing in groups. The following capabilities are unavailable or configured as described below:
Capability | Current status |
|---|---|
Link a personal Telegram account to Jira | Unavailable. The current app has no user page or working account-linking flow. |
Personal direct messages for assignees or watchers | Unavailable. |
Daily due-date reminders | Unavailable. The current release does not run a reminder schedule. |
Create Jira comments from a Telegram discussion group | Unavailable. The current release does not map discussion groups to issues or process replies as comments. |
Edit and preview notification templates | Not published in the UI. Current messages use built-in layouts. |
Manage ticket parsing through a separate parse-chat list | Configured through the Ticket parsing setting for each connected group or supergroup. |
Use ticket parsing in private chats or channels | Unavailable. Only groups and supergroups are supported. |
Recommendations for administrators
Create a dedicated bot for each Jira installation and environment.
Grant the minimum Telegram permissions required: posting for channels and ordinary-message access only where ticket parsing is needed.
Restrict channels to Jira projects before adding advanced filters.
Review Telegram chat membership regularly.
Revoke the token with @BotFather when ownership changes or exposure is suspected.
Do not place secrets or personal data in filter examples, test messages, or screenshots.