Admin Automation is a no-code rule builder that enables customers to schedule automation rules to run whenever they like. It allows admins to automate their security and product access processes, save time and keeps their user management up to date.
There are 3 parts to each automation rule:
Common Use Cases
There are a number of common problems that our customers use the Admin Automation app to solve.
I want to add my SCIM users into the default Atlassian groups
This is usually a problem for customers, as they want to utilise the default Atlassian groups to simply their Jira project setup. When they create a new Jira project, they don't want to have to also mess with 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.
I want to SCIM sync my admins into the site-admin and org-admin groups
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.
I want to prevent invited users from getting access to Jira or Confluence
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 in 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
Customers can create an empty group, and create an automation rule to sync the empty group to 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.
e.g. Create a group called empty-group, and create a rule to run hourly; If a user is not in empty-group, then remove them from jira-software-users group
I need to move 1000's of users from one group to another
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.
I need to merge different groups
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. Mergings multiple SCIM groups makes managing product access much easier.
The Admin Automation app can be used to create multiple rules that run to add or remove users from a single group, based on if those users exist in one or more SCIM sync'd groups.
I want to enable JIT provisioning for my org admins
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 perminant org admin permissions, to avoid breaking/loosing access to your org and needing Atlassian Support to get it back.
In your IdP, create a new group called temp-admins, this is the group your users will be added to in your IdP to get 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 Add user to group rule to run hourly to add users from the temp-admins group into the org-admin group.
Schedule a Remove user from group rule to daily/weekly/how ever often you want to remove all unnecessary org admins; IF a user is not in the permanent-admins group, THEN remove the user from org-admins group.
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).
Security
Access to Admin Automations is restricted to only users who are able to obtain an Organisation API Key. Organization admins are the only users who can create an API Key, but once it's created the key can be used by any user. Learn more about Atlassian API keys.
All API keys are encrypted and stored in AWS Secrets Manager and are only accessible via the Atlassian Admin Automation app. This aids in compliance with regulatory requirements that mandate key rotation and access logging. It’s a robust solution for modern cloud-native applications where managing sensitive information securely is critical.