App support — Screen Self-Service for Jira

Contact us

Contact tfitzner90@gmail.com or use the support portal if you have access. The portal may require an account; if access is unavailable, use email. We accept:

App support: setup questions, a blocked field or a problem using the app.
Privacy request: a question about your data, an access/correction/deletion request or retention.
Security report: a suspected vulnerability, unexpected access or possible exposure.

Your case should be visible only to you, authorised participants and the support team. Do not add other participants or share a case with an organisation if it contains private information. For email, state whether your request concerns support, privacy or security. Do not include confidential Jira data in your first message.

Hours and responsibility

Timo Fitzner handles the beta personally; no fixed deputy or 24/7 cover is offered. Planned absence is announced in advance where practicable and includes the next expected handling time. This does not postpone statutory privacy or security obligations. The published first-response target remains a target; no resolution deadline is promised.

Closed support cases and related provider-held copies are reviewed no later than 90 days after closure. Unnecessary material is removed or minimised; any justified further retention has a recorded purpose, restricted access and a further review date. This manual review does not run the app's automatic retention cleanup or erase customer-owned backups.

Information that helps us

Provide the affected app version, approximate time and time zone, page or action, readable error/support code and a short account of what you expected. Include the short request reference if one exists. State whether the result is known, still running or uncertain. Site and project identifiers are optional for the first message; provide them only when needed to investigate. Screenshots should conceal unrelated projects, user details and issue contents.

Never send a password, API token, backup passphrase, session URL, browser-cookie export or unredacted console dump. Start with a sanitised description. Do not grant Jira-administrator access to diagnose an ordinary case. A necessary support access or confidential transfer is agreed separately with its purpose, scope and duration.

A save or execution did not finish

Ask your Jira administrator to inspect Operations and the saved request. If the outcome is uncertain, stop new app writes and do not repeatedly save, approve, execute or make a direct API call to force a result. A Jira operation already sent can finish after a pause or a browser timeout. The administrator should compare the durable checkpoint with the actual Jira configuration before deciding how to proceed.

App recovery is a controlled inspection and decision. It is not a guarantee of automatic rollback or of an atomic Jira transaction. A request may remain blocked when a safe result cannot be established.

Changed accounts or missing access

Choose Reload Jira and reconnect. This reloads the Jira page for the current account without repeating a saved action. Unsaved edits are cleared. After reconnecting, inspect Requests before submitting another change. Reloading does not grant missing project or global administrator rights.

Field is unavailable or a change is blocked

The app checks screen placement, field context, required fields, operation metadata and configuration dependencies. A field can be unsuitable for a particular issue type or operation. Ask the Jira administrator to check the relevant configuration; do not bypass the checks by editing technical identifiers. V1 does not add new fields to View screens, edit multiple tabs, change workflows or create custom fields.

Approval email did not arrive

The administrator inbox in Jira settings → Apps → Screen Self-Service for Jira → Approvals is the primary place to review requests. Check whether emails are paused. A waiting message is not a delivery guarantee; Jira accepting a message does not prove mailbox receipt. Closed or cancelled requests do not start further approval messages. Already-started or uncertain sends must not be blindly resent.

Backup help

Verify a saved encrypted file locally using Backups → Verify a saved backup. Enter the passphrase only in the app's local verification flow. A verified file is a history backup, not a Jira screen/scheme rollback. Keep your own protected copy and store the passphrase separately. Do not attach the file to a routine support case.

Service scope

Support covers the documented V1 features in company-managed Jira Cloud projects. Jira Cloud availability, customer permission schemes, mailbox delivery and other apps can affect the result. We may ask you to reproduce an issue in a dedicated test project. Any provider-operated live test or Jira configuration change requires an agreed scope; the provider does not have automatic access to your Jira site.

See Getting started, Security and Privacy.

Project groups and Epic setup

A Jira administrator can open Projects → Settings for an enabled project and select allowed groups. Membership alone is insufficient: the person must also have administrator rights in that Jira project. The app does not grant those Jira rights. All project issue types, including Epic, are available automatically. The app finds any existing issue needed for a field check itself. If Jira cannot verify a particular field change, that action remains unavailable; there is no extra issue-type setup form.

Why is an issue needed for approval email?

The app currently uses Jira’s issue-notification endpoint, which requires an existing issue ID. The app finds and verifies an existing issue automatically as the notification anchor; it creates no ticket or comment for approval. If no verified issue exists, email is unavailable and the request remains in the administrator inbox. Email is a convenience: the administrator inbox remains the place to review pending requests. A separate issue-free mail provider would be an additional service and data recipient requiring its own configuration and review; it is not part of this release.

Working capacity and audit filters

Operations → Capacity distinguishes the working list from archived history. The 500-record hard working limit reserves space for safe completion and recovery; new work stops earlier. Archive eligible completed work to free working capacity. The Audit log filter searches the latest 50 administration entries loaded on the page, not every archived request. Use history and individual request audit for older records.

Free beta and feedback

The first release is a free beta. Feedback on confusing steps, blocked supported changes and readable errors is welcome. State the affected action and expected result; start with synthetic or redacted examples. A later paid offer requires separate notice and agreement. No payment details or customer API token are needed for the beta.