See what Scroll Support Hub can read and write in Jira, what it stores, what it records on each request it creates, and its limits.
The app is built on Atlassian Forge, so it runs inside Atlassian's infrastructure under Atlassian's security and data residency controls. Your requests, comments, and attachments never pass through servers run by K15t.
What the App Can Access in Jira
The app requests these permissions when you install it. The Scope column gives the exact Forge scope behind each one.
|
Permission |
Scope |
What it is used for |
|---|---|---|
|
Read and write service management requests |
|
List a customer's requests, open one, post their replies, and create new requests. |
|
Read and write Jira work items |
|
Read request fields and attachments, and mark each widget request so you can find it with JQL. |
|
Read user details |
|
Identify the signed-in customer's account. |
|
Manage service desk customers |
|
Add a visitor as a customer of the service space when they send a request. |
|
Manage project and Jira configuration |
|
Read the options of custom fields, so dropdowns on the request form show the right choices. Jira only gives apps these options through the configuration scope. |
|
Read a user's email address |
|
Match a signed-in customer to the requests they sent before they signed in. |
|
App storage |
|
Store the list of connected sites. |
|
Act on behalf of a customer |
Impersonation on the user, work item, request, and customer scopes above |
Show each person only their own requests, and attribute their replies to them instead of to the app. |
Because the app acts on behalf of the signed-in customer, Jira applies the same permissions as in the portal. A customer can only see a request in the widget if they can also see it in Jira Service Management (JSM).
What the App Stores
The app stores only the list of connected sites. For each site, this is the address, the Connection ID, and the service space.
It does not store requests, comments, attachments, customer names, email addresses, or sessions. All of that stays in JSM, and the app reads it live each time it needs it.
Only Approved Websites Can Show the Widget
The widget only works on a website you have added to Connected sites. Two independent checks enforce this:
-
The widget tells the browser which single website may display it. The browser blocks the widget on any other website.
-
Every call the widget makes is checked against the approved list before Jira answers.
These checks stop someone from copying your widget onto their own website and using your service space. You can only add addresses that use https://. The list is checked live, so removing a site takes effect at once.
Attachments are downloaded as the signed-in customer, and only from the request they belong to. Nobody can use a link to reach a file from someone else's request. Uploads are limited to an allow-list of file types. For the list, see Limits.
What Is Recorded on Each Request
Every request created through the widget carries two markers.
The first is a set of properties you can search with JQL: the website the request came from, its Connection ID, and whether the visitor was signed in. See Find Widget Requests in Jira With JQL.
The second is an internal comment that your agents can see and the customer cannot. It names the website the request came from. If the visitor searched the help center first, the comment also lists what they searched for and which articles the widget showed them.
The comment gives agents useful context. It also means your support team can see what the visitor typed into the search box. Tell your team about the comment, and consider it when you write your own privacy notice.
Cookies and Sessions
The widget sets two cookies, both on the app's own address instead of on your help center, so they do not interfere with a consent tool you already run there. Neither cookie is used for advertising, tracking across websites, or building a profile. A visitor who never starts signing in gets neither of them.
|
Name |
Purpose |
Lifetime |
Set when |
|---|---|---|---|
|
|
Holds the signed-in session, so the widget knows whose requests to show. Scripts on the page cannot read it, it is only sent over HTTPS, and it is kept separately for each help center. |
24 hours |
A visitor signs in |
|
|
Checks that the visitor who comes back from the Atlassian sign-in is the one who started it. |
10 minutes |
A visitor clicks Log in or sign up |
A signed-in session lasts 24 hours. Signing out clears it from that browser. Both cookies are strictly necessary for a feature the visitor asked for, so in most jurisdictions they do not need consent. Check this with your own legal advisers.
Browsers that signed in before version 1.0.0 may still hold an older access_token cookie. The widget removes it the next time the visitor signs in.
Limits
The widget enforces these limits. A limit per network address is shared by everyone behind that address, for example all visitors on one office network. When a visitor reaches a limit, the widget asks them to wait before they try again.
|
Limit |
Value |
|---|---|
|
Largest attachment |
3.5 MB per file |
|
Attachment file types |
Images: |
|
Requests from visitors without an account |
3 per minute per network address, and 10 attempts per minute including failed ones |
|
Uploads, replies, and requests from signed-in visitors |
30 per minute per network address |
|
Opening requests and lists |
100 per minute per network address |
|
Sign-in attempts |
10 per minute per account |
|
Request summary |
255 characters |
|
Requests in the list |
The 100 most recent, 10 per page |
|
Session |
24 hours |
|
Suggested articles |
Up to 3. The widget waits about 7 seconds for the search. |
|
Changes to request types and portal settings |
Reach visitors within 15 minutes |
Related Articles