# 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
Many Atlassian customers want to utilise the default Atlassian groups to simply their Jira project setup while using SCIM ([System for Cross-domain Identity Management](https://support.atlassian.com/provisioning-users/docs/understand-user-provisioning/)). 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
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users from groups**" selection component
4. Select *Group X* and *Group Y* from the **Source groups** list
5. Choose the action component "**Add users to groups**"
6. Select *jira-software-users* from the **Target groups** list
7. 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.
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users from groups**" selection component
4. Select *jira-software-users* from the **Source groups** list
5. 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.
6. Choose the action component "**Remove users from groups**"
7. Select *jira-software-users* from the **Target groups** list
8. Save the rule
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. 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
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users from groups**" selection component
4. Select *scim-admins* from the **Source groups** list
5. Choose the action component "**Add users to groups**"
6. Select *org-admins* from the **Target groups** list
7. Save the rule
I want to keep users with gmail.com emails (or any other email domain) out of my org
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
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users by Email Domain**" selection component
4. Enter *gmail.com* into the **Exact email domains** field.
5. Choose the action component "**Suspend User Access**"
6. Save the rule
I want to suspend any users in my org who have any outside email addresses
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.
1. Create a new rule
2. Enter the rule name, description and schedule.
3. Choose the **Users by Email Domain** selection component
4. 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.
5. Add a filter component **Users by Email Domain**
6. 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.
7. Choose the action component **Suspend User Access**, to suspend all the non-smol software staff.
8. Save the rule
I want to enable temporary org admin access for some users via SCIM
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:
1. Schedule a rule to run hourly, to add the temp and permanent admins to your Org Admin group. Add the following components:
1. Choose the **Select Users from Groups** selection component and add the *temp-admins* and *permanent-org-admins* group.
2. For the Action component, choose **Add Users to Groups** and choose the *org-admin* group.
3. Save the rule.
2. Schedule a second rule to run hourly, to remove temp admins who should no longer have access. Add the following components:
1. Choose the **Select Users from Groups** selection component, for the *org-admins* group.
2. Add the **Exclude Group Members** filter component, for the *permanent-org-admins and temp-admins* group.
3. For the Action component, choose **Remove Users to Groups** and choose the *org-admin* group.
4. 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).
I want to copy 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. 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
1. Create a new rule
2. Enter the rule name, description, for the schedule make sure you select "**Run Once**".
3. Choose the "**Users from groups**" selection component
4. Select *Group X* from the **Source groups** list
5. Choose the action component "**Add users to groups**"
6. Select *Group Y* from the **Target groups** list
7. Save the rule
I want to prevent self 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 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
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users from groups**" selection component
4. Select *idp-jira-users* from the **Source groups** list
5. Choose the action component "**Add users to groups**"
6. Select *jira-software-users* from the **Target groups** list
7. 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.
1. Create a new rule
2. Enter the rule name, description and schedule
3. Choose the "**Users from groups**" selection component
4. Select *jira-software-users* from the **Source groups** list
5. 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.
6. Choose the action component "**Remove users from groups**"
7. Select *jira-software-users* from the **Target groups** list
8. 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.
1. Create a new rule
2. Enter the rule name, description and schedule.
3. Choose the "**Users from groups**" selection component
4. Select a default Atlassian product access group, such as *jira-software-users* from the **Source groups** list
5. Choose the action component "**Remove users from groups**"
6. Select *jira-software-users* from the **Target groups** list
7. Save the rule
I don't want anyone to get access to Jira or Confluence via the default Atlassian groups
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.
***
1. Create a new rule
2. Enter the rule name, description and schedule.
3. Choose the "**Users from groups**" selection component
4. Select a default Atlassian product access group, such as *jira-software-users* from the **Source groups** list
5. Choose the action component "**Remove users from groups**"
6. Select *jira-software-users* from the **Target groups** list
7. Save the rule
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:
1. Merging multiple SCIM groups into one, to give that one group Jira or Confluence user access.
2. 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 [FAQs](/features/faqs.md) or email us at
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.smolsoftware.com/features/common-use-cases.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.