Notifications and Ticket Parsing

Supported notification events

User names and field values are enriched through the Jira REST API when necessary. Missing display values appear as Unassigned, Unknown, or N/A depending on context.

For a notification about one issue, the final message part includes an inline View in Jira button when the app can determine the Jira site and issue URL.

When the configured destination is a Telegram topic, every message part and the final View in Jira button are sent to that exact topic. The connector does not fall back to the group root.

Formatting and message length

Messages use Telegram-supported HTML formatting. Jira values are escaped before insertion so issue or comment content cannot break the markup.

Telegram limits one message to 4096 characters. Longer content is split at paragraph boundaries first, then at line boundaries, and finally at a hard limit when necessary. Parts are sent in order, and the View in Jira button appears only on the final part.

The current interface uses built-in message layouts. A template editor is not published in the admin UI, and the delivery flow does not apply customer-defined templates. Do not rely on message-template customization in this release.

Delivery reliability

• A successfully normalized event is stored before delivery work is queued, so the Jira trigger does not wait for the complete Telegram delivery cycle and queued work contains only a small reference.

• The connector creates a fingerprint for each logical event and channel to prevent duplicate messages when Forge redelivers an event.

• Outgoing sends are serialized per installation and paced to no more than 30 Telegram API message requests per second across that installation.

• The delivery flow limits output to 20 messages per minute for each Telegram chat and honors a Telegram 429 response with its retry_after value.

• Telegram API calls use retries after 1, 2, and 4 seconds, or after the delay supplied by Telegram. Other temporary delivery work is recovered with bounded delays.

• New delivery attempts stop one hour after the original Jira event. If Telegram accepted a message but the connector could not confirm the result, it may resend that one unconfirmed part; a rare duplicate is therefore possible.

• Permanent Telegram errors are not retried indefinitely. If Telegram reports that the bot was removed, the channel is deactivated.

What is ticket parsing?

Ticket parsing lets a Telegram group participant mention a Jira key in an ordinary message and receive issue details without first opening Jira.

Example:

Can someone check PLAT-2841?

When the feature is enabled and the issue is available, the bot replies to the original message with the linked key, summary, status, priority, issue type, and assignee.

In a forum group, ticket parsing is scoped to the connected topic. Messages and replies containing Jira keys are inspected only when that exact topic is Active and has Ticket parsing enabled. The bot replies to the original message in the same topic; settings from another topic or the group root are not reused.

Enable ticket parsing

1. Connect the Telegram group, supergroup, or exact forum topic as a channel. For a topic, send the verification command inside it.

2. Make sure that destination is Active.

3. Open Configure for the matching root or Topic row and expand Ticket parsing.

4. Enable Reply with Jira issue details.

5. If the app reports that the bot cannot read messages, make it an administrator or disable Group Privacy in @BotFather and re-add the bot.

6. Save the configuration and send a test message containing an existing Jira key in that same destination.

Ticket parsing is unavailable for Telegram channels and private chats. The setting applies only to groups and supergroups.

Parsing rules

• A key begins with an uppercase Latin letter, can contain uppercase letters and digits in the project key, and ends with a hyphen and number: for example, ABC-12 or PLAT2-2841.

• Ordinary messages and replies inside the connected topic are processed the same way.

• Repeated keys in one message are processed once.

• The app processes the first three unique keys in one message to prevent excessive replies.

• Nonexistent or unavailable issues are ignored without an error message.

• When the channel is restricted to selected projects, the bot replies only for issues in those projects.

• Event types and Advanced filters control outgoing Jira event notifications; they are not additional ticket-parsing filters.

Bot commands

• /verify CODE — connects a channel, group root, supergroup root, or the exact topic where the command is sent.

• /help — shows brief setup and Jira-key guidance in a private chat with the bot. It does not produce the help response in groups.

Access to Jira data

Issue lookup runs with the app's granted Jira scopes. The response therefore reflects app access, not the individual Jira permissions of the Telegram message author. Enable ticket parsing only in chats whose participants are allowed to see details from the selected Jira projects.

Notification grouping

Each channel or connected forum topic can send events separately, group actions by author, or group by author and issue. Grouping starts disabled. The first matching event opens a fixed 60-second window; the summary is sent when it closes, including when it contains just one event. Events inside the window do not extend it.

A grouped summary about one issue uses only the View in Jira button, without repeating the issue link in the message text, whether it contains one action or several. This applies to author-and-issue grouping and to author grouping when all actions concern one issue. A summary covering several issues includes a View in Jira link under each issue in the text and no single-issue button. Links and buttons are shown only when the issue URL is available.