Jira Ticket Creation
Create Jira work items in the right project and type, with the fields that project requires.
What it adds
A server-side path from an in-app record to a Jira work item, with per-project field discovery, mapping, and a stored ticket reference.
What your agent is told to do
5
What your agent is told to do
5-
1
Discover the destination project's issue types and their required fields at configuration time and again before creating, and present the administrator with a mapping screen. Do not hardcode a field set; every Jira instance is configured differently and a hardcoded schema fails on the second customer.
-
2
Make the deployment type and site part of the connection so hosted and supported self-managed instances are handled deliberately, and keep the credential and site details server-side only.
-
3
Map app users to Jira identities through an explicit, administrator-maintained mapping, and fall back to leaving the field unset with the reporter named in the description rather than guessing an account from an email address.
-
4
Key each submission by the originating record and check for an existing ticket reference before creating, because Jira requests time out often enough that blind retries are the main source of duplicates.
-
5
GitHub Issue Creation, GitLab Issue Creation, Linear Issue Creation, Trello Card Creation, and Asana Task Creation are siblings. Capture, redaction, deduplication, and reference storage belong to the shared path; this brief owns only Jira's field discovery, user mapping, and rich-text handling.
Edge cases it handles
8
Edge cases it handles
8- Required custom fields differ per project and per issue type and change without notice. Fetch the field metadata for the chosen project and type, validate the mapping against it before submitting, and tell the administrator exactly which required field is unmapped instead of failing at creation.
- Hosted and self-managed deployments differ in authentication, available capabilities, and description formatting. Detect the deployment at setup, exercise each path explicitly, and refuse to run against a deployment that has not been verified.
- User identity is the most dangerous mapping. Never infer a Jira account from an email match alone, and never surface Jira account identifiers back to end users, since they can expose an organisation's directory.
- A request that times out has usually succeeded. Store the idempotency key before the call, check for an existing ticket on retry, and reconcile from the app's own record rather than searching Jira by title.
- Descriptions are rich text with a provider-specific structure, and attachments have size and type limits. Convert content safely, truncate over-long descriptions with a link back to the full detail in the app, and skip attachments that exceed the limit with a note rather than failing the ticket.
- Tokens and OAuth grants expire and get revoked. Treat an authentication failure as terminal for the attempt, keep submissions queued, and prompt an administrator to reconnect.
- Rate limits and instance-level throttling need exponential backoff with jitter and a bounded retry count, with a dead-letter path for submissions that never succeed.
- When the Jira instance is unavailable, record the request in the app and create the ticket later, so the user's report is not lost to someone else's outage.
Definition of done
9
Definition of done
9- Required fields are discovered per project and issue type and mapped before any ticket is created.
- Hosted and supported self-managed deployments are configured and exercised deliberately, not assumed identical.
- User mapping is explicit, with a safe fallback that never guesses an account.
- A timed-out request followed by a retry produces exactly one ticket.
- Descriptions convert cleanly and oversized attachments are skipped with a recorded reason.
- Credentials live only on the server, and expiry queues work while alerting an administrator.
- An outage preserves the request in the app and creates the ticket when the instance returns.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Direct Messages
Direct Messages
Let two users hold a private conversation inside the app instead of leaving to email.
What it does
One-to-one private threads with message history, per-conversation unread counts, and blocking.
How it works
- 1 Build the conversation list, the thread view, and the unread badge. Keep the first version to one-to-one threads only and defer group conversations, reactions, threading, and file attachments rather than shipping all of them half-finished.
- 2 Reuse the app's existing Read and Unread State and Notification Center rather than inventing a second unread mechanism and a second alert path. A message notification should sit alongside every other notification the user gets.
- 3 Reuse the composer, mention handling, and rendering rules from Comments and Mentions instead of writing a second message editor with subtly different escaping.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/direct-messages
Voice Notes
Voice Notes
Say it instead of typing it, and attach the recording where the conversation is.
What it does
In-app recording of short audio notes attached to a record, comment, or message.
How it works
- 1 Add recording to the places where people already leave text, most likely alongside Comments and Mentions, so a voice note is another kind of comment rather than a separate feed nobody checks.
- 2 Store the recording through the app's existing file upload path so a voice note inherits the same retention and access rules as any other attachment on the record, and disappears with the record when it is deleted.
- 3 Show a live duration and a simple level meter while recording, and let the user review and discard before it is sent. Nobody should be committed to a recording the instant they stop.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/voice-notes
Assign Ownership
Assign Ownership
Make it obvious who is responsible for each record.
What it does
An assignee on records, with a picker, notifications on change, and a history of who owned what.
How it works
- 1 Add a nullable assignee to the relevant records. Unassigned is a real, valid state — do not force a default owner just to avoid the null.
- 2 Restrict the picker to users who can actually access the item, and validate that server-side as well as filtering the list.
- 3 Notify the new assignee when they are assigned by someone else, and record every change with the actor and timestamp.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/assign-ownership
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.