Security and permissions
Follow-up Steward reads the Jira information needed for reminders and sends due email through Jira. It does not change issue fields, comments or Due Date.
Where the app runs
The app runs on Atlassian Forge. Reminder settings, notes and technical outcomes are stored in Forge hosted storage, isolated by installation. There is no separate provider-operated reminder database or SMTP service, and no app integration with advertising or external analytics.
The public website and information you choose to send to support have separate data flows. See Misheno website privacy.
Permissions and their purpose
| Permission | Purpose |
|---|---|
read:jira-work | Read permitted issue details, status, assignment and project context. Check issue access again before reminders are shown or sent. |
read:jira-user | Identify eligible internal recipients and their current account and product access. |
send:notification:jira | Submit a due notification to Jira for a selected, checked recipient. |
storage:app | Store schedules, notes, preferences, ownership, technical history and deletion controls in Forge. |
report:personal-data | Report stored account references to Atlassian and act on account privacy requests. |
| Project administration checks | Verify that a person is authorized to change project policy, manage team reminders or transfer ownership. |
Background checks use the appropriate user’s Jira access even when that person does not have the app open. Notification permission is separate from permission to edit Jira issues. The app does not require your API token, access to everyone’s email address, or an organization administrator’s credentials.
Who can see a reminder
A self-only reminder is private to its owner. Team reminders are visible to their participants and authorized project administrators, provided they can currently access the issue. Being a site administrator does not grant access to private reminders or restricted issue data.
The app separately checks the current owner and each recipient’s issue access and account eligibility before submitting an email. Sending as the owner does not substitute for checking the recipient. A failed or unknown authorization check blocks that recipient’s send. Opt-out is respected independently of issue access.
Current assignee is resolved to a particular person for each occurrence. Only selected, eligible recipients are submitted; the app does not add watchers, voters or the reporter automatically.
Email and access changes
Jira builds each notification. It contains the reminder note and an authenticated link, and Jira adds the issue key and summary. The app cannot remove that issue context from Jira’s email. No email is sent merely because a reminder was created or edited.
Reminders to colleagues and Current assignee are submitted as the current owner, so Jira also applies the owner’s access. Reminders to the owner are submitted by the app, which requires the app itself to have access to the issue. A team-managed issue restriction can exclude the app while the owner still has access; the reminder is then not sent and its outcome explains why. The app never grants itself access, changes restrictions or retries as a different sender.
Access checks happen immediately before submission to Jira. Access changes afterward cannot recall an accepted email. The app does not claim to recheck permissions when a mailbox receives or opens it. Jira’s acceptance is shown as Queued, never as Delivered or Read.
Email links require authentication for protected content. Opening a link alone does not snooze, cancel or opt out. Those actions require an authenticated, explicit request.
Stored data and deletion controls
The app stores issue and account identifiers, schedules and time zones, the note, recipient choices, personal snoozes, opt-outs, ownership and technical outcomes. Current issue summaries are read for display and email without keeping historical summary copies. It does not copy issue descriptions, comments or attachments.
Conditional updates prevent an old edit or background task from overwriting a later cancellation or deletion. An uncertain notification outcome is not retried automatically. A send that started before cancellation or deletion may still complete; the interface explains that boundary.
Settings remain while a schedule or valid personal return is active. Terminal settings and rolling history follow the 90-day retention rules. Privacy erasure and explicit deletion stop future work before content cleanup.
Data residency
Persistent reminder data is kept in Forge hosted storage and follows the linked Jira product’s supported data residency location. See Forge data residency for Atlassian’s platform scope.
Email in recipient mailboxes, browser memory, voluntary support correspondence and Atlassian platform diagnostics are outside that stored-reminder residency scope. This is not a guarantee that every processing step or mailbox stays in one region.
Diagnostics and support
Application diagnostics record operational stages and error information without intentionally logging reminder notes, issue summaries, email addresses or lists of names. Atlassian provides platform logs and operational metadata under its controls.
For security or privacy concerns, use private support. This page describes the app’s safeguards; it is not a claim of independent security certification.