Cloud Migration Resources
Planning a Cloud migration? These resources can help you get started:
→ Time to SLA Cloud features – Review Cloud features and understand key differences between DC and Cloud.
→ Migration support from Appfire – Learn how we can help you migrate smoothly.
Manage permissions
The Permissions page lets you control who can view, configure, and manage Time to SLA features.
You can grant permissions to:
TTS Admins – A group that you can define that has admin privileges only within the app. Jira Administrators are the default TTS Admins. Once you define a TTS Admins group, you can delegate administrative control within the app without granting Jira Administrator privileges.
Specific Jira groups
Specific users
All logged-in users
Anonymous users (if applicable)
Or restrict access completely
How permissions are evaluated
Permissions in Time to SLA follow these rules:
Granting a higher-level permission (such as Delete SLA) automatically includes lower-level permissions (such as View and Update).
If a user does not have View permission for an item, they cannot access it, even if they have related permissions (such as Update or Delete).
Prerequisites
Before starting, we highly recommend defining a TTS Admins group that will have admin privileges only within the app. You can do this by clicking the Define TTS Admins button in the top-right corner of the page.
This way, you can grant users admin authorization only within the Time to SLA app itself, without requiring them to be Jira administrators.
How to manage user permissions
Log in to your Jira account.
Click Time to SLA in the header menu to see the TTS menu.
Go to Permissions. The Time to SLA Permissions screen appears, where permissions for all Time to SLA categories can be viewed.
Below is a detailed explanation of the different Time to SLA menus and their respective access permissions:
Calendar Configuration | These permissions control who can manage Time to SLA calendars.
|
SLA Configuration | These permissions control access to SLA definitions.
To clone an SLA, users must have both permissions:
|
Notifier Configuration | Notifiers are used to trigger actions such as email notifications, webhooks, or automation when SLA events occur.
Having permission to create or manage Notifiers is not sufficient to see them. Users must also have View Notifiers permission. Without View permission, notifier configurations will not be visible.
|
SLA Fields/Panels | These permissions control visibility of SLA-related TTS custom fields.
By default, SLA viewing permissions are granted to All logged-in users so agents can see SLA status directly in work items. |
SLA Panel Customization | Allows users to customize the layout and behavior of the SLA Panel. |
Custom Fields Configuration | Allows users to manage Time to SLA custom fields. Managing includes:
|
SLA Recalculation | Allows users to recalculate SLAs for multiple work items at once. |
Report |
|
Import/Export |
|
Issue View Menu SLA Actions | These permissions control which SLA-related actions are available from the Issue Actions menu.
|
Click Edit for each permission type, and select a User Type that you would like to give permission to.
Select TTS Admins if you want users with TTS administrator privileges to view/create/edit the TTS item.
Select Group if you want users in a particular group to view/create/edit the TTS item.
Select Users if you want only specific users to be able to view/create/edit the TTS item.
Select All logged in users if you want anyone who has logged into the project to view/create/edit the TTS item.
Select Anonymous if you want users to view TTS items without logging in.
Select None if you don't want anyone to view/create/edit the TTS items.
If you grant a group/user the ability to delete an SLA, for example, they will automatically also be able to see and change it.
Click Save.
The Project Role cannot be selected on the Permissions page. For example, since SLA fields are project-based, you can select the project role on the Permissions page; however, since things like SLA or calendar are not project-based and are global, we do not allow them to be selected for the project role.