Getting started

Install without API tokens

A Jira administrator installs the app through its approved installation route and reviews the site-wide permissions. Users do not create API tokens, give the app an administrator password or paste credentials into a settings page. Atlassian may ask a user to consent to calls made in their name.

A fresh installation starts with no projects enabled and change requests off. Setup and approvals belong to that installation; they are not copied from another site. Separate project-administrator roles depend on the Jira plan and permission scheme.

Complete the first privacy check

Before enabling a project in a production installation, open Data & privacy. Review the reporting description, turn on Report stored account references to Atlassian, and choose Save. Then select Check Atlassian reporting now. Wait for Reporting is up to date; projects remain protected until the check succeeds. A Jira administrator must resolve any reported account notice or unconfirmed outcome first.

The check reports stored Atlassian account identifiers and update times to Atlassian. It sends no issue contents, notes or email addresses. Later checks run automatically and respect Atlassian's reporting interval. A check does not delete history, enable projects or resume Jira changes or approval emails. Automatic history deletion starts off and requires its own deliberate setting.

Enable a project

Open Jira settings → Apps → Screen Self-Service for Jira → Projects, find the project and select Enable. The app checks its configuration and your current Jira-admin authority, then enables all current issue types in one action. Epic and types without existing issues are included. Types added in Jira later appear automatically. There are no ticket numbers, type checklists or reasons to enter.

Only enabled projects can apply supported changes. Project enablement constrains the app's actions; Atlassian's underlying app permissions remain site-wide. A project administrator must have current project administrator rights. Global access and optional group checks are verified on the server.

Add a group restriction when needed

An enabled project has Settings. Turn on Limit access to selected groups and choose up to ten existing Jira groups. Members must also have administrator rights in this project. With the restriction off, current project administrators can use the enabled project. The app does not grant Jira permissions or change group membership.

Saving access settings invalidates earlier unexecuted requests. Disabling and re-enabling a project also requires fresh requests; restoring the previous options does not revive an old approval. A running operation can prevent setup changes.

Choose the approval policy

In Approval policy, enable change requests, select a mode and choose Save:

• For new screens and schemes: project admins may save supported isolated edits to existing screens. Creating a screen or screen scheme needs another Jira-admin account's approval.
• For every change: another Jira-admin account reviews every supported request before execution.

Saving a policy does not resume paused Jira changes or emails. Earlier unexecuted requests need fresh validation. The app checks distinct accounts; it cannot establish that they belong to different people.

Before your first change

Start with a company-managed project your organisation uses for testing. Check the enabled project, the project administrator's access and the chosen approval policy before making a change.

Open Operations. If Jira configuration changes are paused, a Jira administrator can select Resume Jira changes when the project is ready for changes. This permits freshly checked work; it does not repeat a saved or interrupted action. Administrator emails are optional and have their own Resume administrator emails control. Requests remain available in Approvals while emails are paused.

Edit a screen

Open the app in the enabled project's settings. Choose an issue type and Create, Edit or View, then Load screen. Reorder existing fields on the supported tab. Create/Edit can also add or remove existing fields that pass Jira checks. Required fields cannot be removed.

Use the field search to find an eligible unused field. Searching filters the loaded list; it does not call Jira on every keystroke. Unavailable fields have an explanation. If an Edit check needs an existing issue, the app finds and verifies one automatically. Without a suitable editable issue, that particular field addition may be unavailable; the issue type and its screens remain accessible. The app creates or edits no issue contents for these checks.

Select Review and save to see the before/after layout, affected selections and any required configuration copies. Save changes applies an eligible existing-screen change. Send for approval saves a request without executing it. After another Jira admin approves, the requester explicitly applies the approved change. The app verifies the actual result.

Understand a shared screen

A physical screen can serve several issue types and Create/Edit/View operations. The screen view names the other issue types and operations that use it. Isolated changes keep those other uses unchanged, creating only the supported copies when necessary and requiring structural approval.

A Jira admin can separately opt into shared changes within one project and allow the project admin to confirm the full impact. The requester must explicitly acknowledge every affected use. Current permissions, field rules, ownership, workflow references and dependencies still apply to all of them. Direct shared writes across projects stay blocked. New configuration still needs approval; every-change review overrides self-service.

Find and review requests

Jira admins use Jira settings → Apps → Screen Self-Service for Jira → Approvals → Awaiting review. Open a request, compare its layout and impact, add a review note and approve or reject it. Requesters follow their work in Requests. Review and execution are separate actions.

Optional Jira emails link to the admin inbox. The app verifies recipients and an existing issue used by Jira's notification service. It creates no notification ticket. If no suitable issue is available or emails are paused, the request remains in the inbox with a delivery explanation. Jira accepting an email is not proof of mailbox delivery.

Pause, inspect and back up

Pause Jira changes prevents the next app configuration-change step. It does not stop ordinary issue editing or undo a Jira call already sent. Resume Jira changes permits freshly verified work; it does not replay an interrupted request. Approval emails have their own pause control.

Operations shows active work, delivery and capacity. If an outcome is uncertain, stop further app changes and inspect the saved request before retrying. Backups prepares an encrypted history file: save it, then verify it locally with the passphrase. History import restores readable records, not Jira configuration or old authority. A forgotten passphrase cannot be recovered.

V1 boundaries

Supported: company-managed software/business projects; one-tab existing-field ordering in Create/Edit/View; eligible existing-field addition/removal in Create/Edit; supported isolated Screen/Screen-Scheme copies; project/group access, approval, audit and controlled recovery.

Unavailable: View field additions/removals, multi-tab editing, direct cross-project shared writes, Issue Type Screen Scheme copies, replacement of existing type mappings, team-managed targets, JSM portal-form changes, workflow editing, custom-field creation and field-context administration. Jira layouts and other apps can affect what users see.

Inspection stops above 100 discovered projects, 250 entries in each screen/scheme/Issue Type Screen Scheme/workflow catalogue or 1,000 field definitions. Combined API and time budgets can be reached earlier. Incomplete dependencies block a change. These are bounded capabilities, not a guarantee that every configuration at those maxima will work.

The working list stops admitting new requests before 400 records or an earlier storage threshold; its hard ceiling is 500. Eligible completed work can be archived to make room, so this is not a lifetime change limit. The archive, privacy cleanup and backups also have documented bounds. Archiving retains data; it is not deletion.

Beta and help

The initial beta is free. A future paid version requires separate notice and agreement; these pages create no payment obligation. See Support, Privacy, Security and Provider terms. If the support portal is unavailable to your account, use the email contact on the Support page.