Service Usage Consumer
No longer used. Can be removed.
27 Matching Annotations
- Mar 2026
-
docs.sprinto.com docs.sprinto.com
-
-
Post-Connection Flow
We need to attach the screenshot here. And ask the user to click Sync under the purpose where they want to start monitoring in Sprinto. Please check other docs and follow the same
-
(Security Reviewer)
I don't think we need this to be mentioned here.
-
Access clarification:roles/monitoring.editor provides write access, which is required to create Cloud Monitoring policies from Sprinto.All other roles grant read-only access and are used strictly for visibility and compliance checks.These roles are required by Sprinto when integrating with GCP.
What is the purpose of this section? Its explaining whats there in the above table.
-
Sprinto requires the following predefined roles on the configured project(s):
You mean these are the permissions of the Service account that gets created during setup?
-
(Post-Setup Access)
What does this mean? Its confusing.
-
Connect GCP Using Workload Identity Federation (New Flow)
Can be removed right? This document explains only the new flow now and its already mentioned in the above section that its new.
-
Connect GCP Using Previous Methods
Can these moved to separate page altogether? And add the links to them here at the bottom? Will make the document more easier to follow
-
This replaces the previous JSON upload step. Once complete, return to Sprinto and click Connect to finalise the setup.hashtag
Unnecessary information for a new user.
-
(WIF Based)
Remove
-
You can optionally adjust API permissions before running the script. Copy the bash code again if you make any changes.
Why is this needed?
-
A single service account created under this project can connect all listed projects.
Always add full screenshots please and not specific part
-
(Recommended – WIF Based)
Is this needed here? Both methods are WIF based right?
-
Review the permissions required for this integration here.
This is the permission that the Service account that we create will have. Not the permission of the user that needs to perform this integration. That needs to be changed. Pre-reqs should contain the required permission of the user who is about to perform the integration.
-
New Integration Methods (Recommended)hashtag
I think we can avoid the New integration method here. Its the 3rd time from the top we are calling out that it is new
-
GCP API Resources
Add some details / title here. Feels like a sudden list of resources without any context.
-
If your organisation has inherited users in GCP assigned via groups, please contact your Customer Success Manager (CSM) or email support@sprinto.com to enable this feature for your account.
Can we place this entire note at the bottom where they assign permissions? Is it required at the beginning of the doc?
-
-
docs.sprinto.com docs.sprinto.com
-
The service account has Jira Admin permissions.
As mentioned in the notion document, will be good to add this note.
To clarify, the Jira Admin permission is required solely to satisfy the permission check for the above API. The OAuth 2.0 scopes strictly govern what actions the integration can perform. Even if the Service Account has Jira Admin access, it cannot perform any write or administrative actions beyond the scopes explicitly granted. This ensures the integration remains limited to the provided scopes. Reference document
-
Ensure your account can grant:manage:jira-configurationread:jira-workwrite:jira-workread:jira-user
Let's not add this here. This will differ based on the chosen option of setup method
-
You can connect using:
Recheck and update. We have Client credentials also now
-
Projects → App admin
Why is this needed?
-
The service account has Jira Admin permissions.
Mention why we need this. Already added the reason above and added link for ref.
-
This approach gives your organisation greater control over authentication credentials and permissions.
One of the main advanatage is its not tied to a User's account. So any changes made to the Users account - Like user getting offboarded, user losing some permissions etc will not affect the integration.
-
The manage:jira-configuration scope requires Jira admin access.
The scope doesn't require the admin permission. The API we are using requires admin permission in addition to these Scopes. Ref: https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-workflows/#api-rest-api-3-workflows-post
-
In the Setup Jira Integration screen, select Use your organization's service account.
This section is for OAuth app but we are asking the user to select the other option. Both copy and image needs to be fixed
-
Prerequisites
At the top can we first mention what are the available methods of setup?
API Token - We should mention as Deprecated. OAuth 2.0 - Should be recommended. Client Credential using Service Account
-
Before you begin:
Better to add Pre-requisites based on the type of integration method they choose. Different methods have different pre-reqs. Having a common one is confusing.
-