Common Use Cases
Discover common uses for the Admin Automation rules and how to create them.
Last updated
Discover common uses for the Admin Automation rules and how to create them.
Last updated
There are a number of common problems that our customers use the Admin Automation app to solve.
Many Atlassian customers want to utilise the default Atlassian groups to simply their Jira project setup while using SCIM (). When they create a new Jira project, they don't want to have to also change the Global, Product and Project settings to ensure the right users have access to the right projects.
The Admin Automation app allows customers to automatically add and remove users from any of the default Atlassian product access groups.
e.g. I want to add all users from Group X and Group Y into the default jira-software-users group
Create a new rule
Enter the rule name, description and schedule
Choose the "Users from groups" selection component
Select Group X and Group Y from the Source groups list
Choose the action component "Add users to groups"
Select jira-software-users from the Target groups list
Save the rule
Next, create a corresponding rule to remove users from the jira-software-users group when they're no longer in Group X or Group Y.
Create a new rule
Enter the rule name, description and schedule
Choose the "Users from groups" selection component
Select jira-software-users from the Source groups list
Add a filter component 'Exclude Group Members' with the groups Group X and Group Y. This will leave you with users who have Jira Software access, but should be removed.
Choose the action component "Remove users from groups"
Select jira-software-users from the Target groups list
Save the rule
The site-admin and org-admin groups are 'protected' groups within the Atlassian products, and cannot be sync'd to with SCIM. The Admin Automation app allows customers to automatically add and remove users from the site-admin and org-admin groups, as well as any of the other administration groups in admin.atlassian.com.
Be careful to never allow the site-admin or org-admin groups to be empty. We recommend to only manually remove users from the org-admins group.
e.g. I want to add all users from scim-admins into the default org-admins group
Create a new rule
Enter the rule name, description and schedule
Choose the "Users from groups" selection component
Select scim-admins from the Source groups list
Choose the action component "Add users to groups"
Select org-admins from the Target groups list
Save the rule
Having random users that are invited by other users, users that self-join or users that are manually added via a site or org admin, who are using public email addresses such as gmail.com, can put the security of your data at risk.
You can use the Select Users by Email Domain and corresponding filters to keep your data secure.
e.g. I want to suspend any user without a smolsoftware.com email address from my org
Create a new rule
Enter the rule name, description and schedule
Choose the "Users by Email Domain" selection component
Enter gmail.com into the Exact email domains field.
Choose the action component "Suspend User Access"
Save the rule
Many Atlassian customers find that the 'User Access Settings' are hard to lock down; they want to completely remove any user that isn't from their company. This includes users that are invited by other users, users that self-join and users that are manually added via a site or org admin.
You can use the Select Users by Email Domain and corresponding filters to keep your data secure.
e.g. I want to suspend any user who does not have a smolsoftware.com email address in my org.
Create a new rule
Enter the rule name, description and schedule.
Choose the Users by Email Domain selection component
Enter "." into the Domain contains field. This will match all user email domains with a . (dot) in it, which will be every user in your org.
Add a filter component Users by Email Domain
Enter "smolsoftware.com" in the Exact Email Domains field and toggle Exclude Mode to on. This will leave you with users who are in your org, but who are not Smol Software staff.
Choose the action component Suspend User Access, to suspend all the non-smol software staff.
Save the rule
If you’re using SCIM to sync your users to your Atlassian products, you can configure two rules to allow a Just In Time (JIT) provisioning process to occur for a majority of your org admins.
Note: You should always have one or two users with permanent org admin permissions, to avoid breaking/loosing access to your org and needing Atlassian Support to get it back.
In your IdP (Identity Provider), create a new group called temp-admins, this is the group your users will be added to in your IdP to give them temporary org admin permissions. In your Atlassian User Directory, create a group called permanent-org-admins and add your one or two trusted users that will always have org admin permissions.
The two rules to create are:
Schedule a rule to run hourly, to add the temp and permanent admins to your Org Admin group. Add the following components:
Choose the Select Users from Groups selection component and add the temp-admins and permanent-org-admins group.
For the Action component, choose Add Users to Groups and choose the org-admin group.
Save the rule.
Schedule a second rule to run hourly, to remove temp admins who should no longer have access. Add the following components:
Choose the Select Users from Groups selection component, for the org-admins group.
Add the Exclude Group Members filter component, for the permanent-org-admins and temp-admins group.
For the Action component, choose Remove Users to Groups and choose the org-admin group.
Save the rule. This will ensure that any user removed from the temp-admins group by your IdP are also removed from the org-admin group within the hour.
Then you just need to trigger a group change in your IdP to get what you need. That trigger could be as simple as a manual task after an approval process (such as via ServiceNow or Jira Service Management).
Unfortunately, Atlassian admins don't have many options to perform bulk actions on users and groups. The Admin Automation app allows 'Run Once' rules to be run, to add or remove 1000's of users from one group to another, quickly and easily. After the rule has been run once, it will automatically disable itself and be available if you want to run it again in the future.
e.g. I want to copy all users from Group X into Group Y
Create a new rule
Enter the rule name, description, for the schedule make sure you select "Run Once".
Choose the "Users from groups" selection component
Select Group X from the Source groups list
Choose the action component "Add users to groups"
Select Group Y from the Target groups list
Save the rule
Many Atlassian customers find that the 'User Access Settings' are hard to lock down; they want to completely remove any user that isn't added via SCIM sync. This includes users that are invited by other users, users that self-join and users that are manually added via a site or org admin. There are two ways that the Admin Automation app can help with this:
Customers can designate a 'key' SCIM group, and only users that exist in that group can be added to a default Atlassian product access group. e.g. If a user exists in the idp-jira-users group, then add them to jira-software-users group. If a user doesn't exist in the idp-jira-users group, then remove them from the jira-software-users group
Create a new rule
Enter the rule name, description and schedule
Choose the "Users from groups" selection component
Select idp-jira-users from the Source groups list
Choose the action component "Add users to groups"
Select jira-software-users from the Target groups list
Save the rule
Next, create a corresponding rule to remove users from the jira-software-users group if they're not in the idp-jira-users group.
Create a new rule
Enter the rule name, description and schedule
Choose the "Users from groups" selection component
Select jira-software-users from the Source groups list
Add a filter component 'Exclude Group Members' with the group idp-jira-users. This will leave you with users who have Jira Software access, but should be removed.
Choose the action component "Remove users from groups"
Select jira-software-users from the Target groups list
Save the rule
Alternatively:
Customers can create an automation rule to remove users from the default Atlassian product access groups. This ensures that the default groups are always empty and anyone manually invited or added via another user will be removed automatically. This only works if there are alternative SCIM sync'd groups controlling access to the Atlassian products.
Create a new rule
Enter the rule name, description and schedule.
Choose the "Users from groups" selection component
Select a default Atlassian product access group, such as jira-software-users from the Source groups list
Choose the action component "Remove users from groups"
Select jira-software-users from the Target groups list
Save the rule
Many Atlassian customers find that it's difficult to lock down their Atlassian products. They want to completely remove any user that isn't added via SCIM sync. This includes users that are invited by other users, users that self-join and users that are manually added via a site or org admin.
Customers can create an automation rule to remove users from the default Atlassian product access groups. This ensures that the default groups are always empty and anyone manually invited or added via another user will be removed automatically. This only works if there are alternative SCIM sync'd groups controlling access to the Atlassian products.
Create a new rule
Enter the rule name, description and schedule.
Choose the "Users from groups" selection component
Select a default Atlassian product access group, such as jira-software-users from the Source groups list
Choose the action component "Remove users from groups"
Select jira-software-users from the Target groups list
Save the rule
There are a few situations where customers want to merge different groups. The most common is related to having multiple SCIM groups, but not wanting to have to manually grant each of those groups product access:
Merging multiple SCIM groups into one, to give that one group Jira or Confluence user access.
Merging multiple 'Customer' SCIM groups into one, to give that one group the Customer Role in Jira Service Management.
There's also the use case where the Site Admin or Org Admin doesn't have control over the groups created in their IdP. They have too many groups with small numbers of users in them, and no way to control which groups are created in the IdP. Merging multiple SCIM groups makes managing product access much easier.
The Admin Automation app can be used to merge two or more groups into one.
Got a question? Check out our or email us at
