-
Suggestion
-
Resolution: Unresolved
-
None
-
5
-
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations:
- With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments.
- With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side.
The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field Sync users only in specific groups become too overcrowded and difficult to manage:
- jira-<project-key>admin
- jira-<project-key>user
- confluence<space-key>-admin.
- confluence<space-key>-user.
- etc
Suggestion:
- Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace.
- Improve the UI so it can better handle a high number of groups. The current UI might work well for companies with fewer groups on Google, but it doesn’t get displayed well for a company with thousands. The workaround consists in checking Directory -> Groups to check which groups have the padlock icon, which adds a lot of extra effort for admins.
- Ideally, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort.
- relates to
-
ACCESS-1486 Add option to Google Workspace sync settings to sync all groups
- Gathering Interest
-
ENT-1528 Failed to load
[ACCESS-1566] Google Workspace - Group assignment redesign
Support reference count | Original: 4 | New: 5 |
Link | New: This issue relates to ACCESS-1486 [ ACCESS-1486 ] |
Support reference count | Original: 3 | New: 4 |
Support reference count | Original: 2 | New: 3 |
Support reference count | Original: 1 | New: 2 |
Remote Link | New: This issue links to "ENT-1528 (Hello Jira)" [ 788653 ] |
Description |
Original:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. The current UI might work well for companies having with fewer groups, but it doesn’t fit well for a company with thousands. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
New:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. The current UI might work well for companies with fewer groups on Google, but it doesn’t get displayed well for a company with thousands. The workaround consists in checking Directory -> Groups to check which groups have the padlock icon, which adds a lot of extra effort for admins. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
Description |
Original:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. The current visualization might work well for companies with fewer groups, but doesn’t fit well for a company with thousands. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
New:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. The current UI might work well for companies having with fewer groups, but it doesn’t fit well for a company with thousands. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
Description |
Original:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
New:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. The current visualization might work well for companies with fewer groups, but doesn’t fit well for a company with thousands. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |
Description |
Original:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace or improve the UI so it can better handle a high number of groups. |
New:
With an active Atlassian Access subscription, you can decide which groups from your Google Workspace should be synced to an Atlassian Organization.
However, the mechanism that makes that happen is different when compared to the other SCIM integrations: * With SCIM, it's possible to manage which groups should be synced by assigning them to the Atlassian Cloud application on the Identity Provider side. This is beneficial because it provides a centralized place to manage all users and group assignments. * With the Google Workspace integration, the group has to be created on the Identity Provider first and then assigned in the Google Workspace configuration on Atlassian side. The Google Workspace integration ends up requiring work from 2 different teams. Besides that, when using groups to manage a highly granular level of permissions, as shown below, the field _*Sync users only in specific groups*_ become too overcrowded and difficult to manage: * jira-<project-key>admin * jira-<project-key>user * confluence<space-key>-admin. * confluence<space-key>-user. * etc *Suggestion:* * Provide an option to decide which groups should be synced to Atlassian directly from Google Workspace. * Improve the UI so it can better handle a high number of groups. * {*}Ideally{*}, include Regex as an alternative to select which groups should be synced instead of manually adding each one of them. This option could be available on Atlassian side and would allow syncing new groups that were created on Google that satisfy the Regex pattern without requiring additional manual effort. |