Every organization undergoes the inevitable process of offboarding employees, and admins often find a difficult balance between keeping the directory clean and ensuring nothing relevant is missing. Should offboarded users be retained in the local directory? And what happens to their group memberships?

In this step-by-step guide, we show you the process that IBM is following to retain unlicensed user identities in a dedicated group within the Jira and Confluence local directories while removing them from every company workflow – including automated notifications and, of course, application access.

IBM’s Offboarding Requirements

We currently have a use case where we would like to implement the existing feature to “Remove group memberships during cleanup”. However, we were wondering if it would be possible to have an exclusionary option that prevents removal from specific groups.

In our use case we manage users who have left the company by adding them to a specific group so we can track them separately from those who have simply not logged in in a while. Our goal is to revoke their group membership from all groups when inactive except for the specified group that identified the users who have left the company.

we have recently identified that if project teams use automation for Jira to setup custom notifications that are sent to group memberships then all users in that group including those with inactive licenses are still sent the notification.

IBM´s feature request

IBM is one of our most loyal customers. They regularly share questions and feature requests, and we regularly improve the product based on their feedback.

This time, they wrote us with a challenge around effectively managing users who have left the company. They had two goals:

1. To streamline user offboarding, finding a clean process to deactivate leavers.
2. To maintain a record of offboarded users within the Jira and Confluence directories for future actions, like anonymization or other privacy compliance requirements. The desired method was the inclusion of a dedicated group for offboarded users.

Unfortunately, at some point, IBM admins realized that the two goals were at odds:

• the retention requirement implied that unlicensed users needed to retain one group
• however, the offboarding could only be completed by removing every other group. The reason it was not acceptable to retain the remaining group memberships was that users who had left the company were still receiving Jira notifications triggered by custom automation. Had this not been addressed, notifications to unlicensed users would start impacting the instance’s performance.

At the time of this request, the User Sync connector already allowed to automatically remove group memberships of users who have been deactivated on the IdP – but it did not allow to make any exceptions, and thereby protecting any groups from removal

That’s exactly what we added.

The Solution

To address IBM’s need, we enhanced our SAML SSO and User Sync apps.

The solution was to build and release a new feature that allows admins to include exceptions when removing group memberships during cleanup.

Let’s break down the solution using IBM’s requirements:

1. Initial Cleanup: The app identifies users who haven’t logged in for 60 days. Whenever a user passes this threshold, it is automatically deactivated, and removed from all groups. This feature already existed and ensured inactive users didn’t occupy unnecessary licenses.
2. Exclusionary Cleanup: Here’s the twist: If a user is a member of the “off-boarded” group, they shouldn’t be removed from it. This ensures that the organization can still track users who’ve left while still disabling them from Atlassian licensing. This feature was built to cover the necessities of this and a few extra customers.
3. Immediate Action for Off-boarded Users: Identify and deactivate users who are members of the “off-boarded” group, thus removing any time constraints without the need to wait for 60 days of inactivity. For this specific scenario, we opened a development ticket, and the feature will be released in the future. Currently, this is achievable by performing bulk group deactivations with our recognized License and user Deactivator app.
4. Compliance-centric Cleanup: Lastly, track members of the “off-boarded” group who haven’t logged in for 60 days to fully anonymize their accounts in order to comply with data privacy rules and policies. This last point still needs automation but is part of the development ticket created for the above point.

Step-by-step Guide:

1. Disabling users while removing groups with exceptions

We will show how to do it in two ways, depending on how you provision your users:

Step 1. Enable the group membership removal during cleanup.

Click on the checkbox to enable the group membership removal during the cleanup.

Step 2. Add exceptions to group removal

Below the “Remove group membership during cleanup” checkbox, you will find a text field where you can add all the groups you want to exclude from the group removal.

Simply click in the pencil beside the text field and add the desired groups. You can select a group or add a regular expression. In this case, we are adding all groups that start with “offboarding”.

After clicking OK, save the configuration by clicking on the “Save and Return” button.

For customers using Just in time provisioning (JiT), just like IBM, they can use the Cleanup Inactive Users connector.

Step 1. Enable group membership removal during cleanup.

After defining the cleanup conditions that fit your needs, click on the checkbox to enable the group membership removal during the cleanup in the Cleanup Actions section.

Step 2. Add exceptions to group removal

Below the “Remove group membership during cleanup” checkbox, you will find a text field where you can add all the groups you want to exclude from the group removal.

Simply click in the pencil beside the text field and add the desired groups. You can select a group or add a regular expression.

At the end, don’t forget to save the configuration.

2. Disable users from specific groups immediately

A new feature is currently in development to cover the 3rd and 4rth points required by the customer and detailed in The Solution section. This feature will allow to:

• automatically deactivate users assigned to a certain group
• and to anonymize these users automatically to comply with privacy regulations.

However, as an alternative course of action, it’s currently possible to meet IBM’s requirements with the License and User Deactivator app. The following instructions apply to this second product.

Step 1. Filter users by the desired group

• In the “In Group” filter option, type the desired group and click on the “Filter” button.

In the case of IBM, the filtering group would be obviously “offboarding“.

Step 2. Select Users to deactivate

• After filtering, quickly review that the results are correct. Then, click on “Select All” to pick all users from the list, and then click on “Choose Bulk Action”.

Step 3. Deactivate Users

After clicking on “Choose Bulk Action,” a popup with several bulk options will show. Select “Deactivate” and click on Next.

Confirm the operation, and you are all done!

Conclusion

Effective offboarding is as crucial as onboarding. It ensures security, compliance, and efficient resource management. With the new release of SAML SSO for Atlassian products (6.7.0), organizations can now manage their offboarding processes more effectively and smartly. Taking cues from real-life challenges, we are committed to improving continuously to serve you better. So, next time you’re offboarding an employee, remember you have the tools to do it like IBM.

Remember that this is only one specific use case, but the new group exclusion field could apply to many other use cases depending on your company’s needs; we will be happy to assist you if you need help to implement it. Also, don’t forget that we are always eager to improve our app, so if you have a feature request that could make your user or group management process easier, let us know, and we will do our best to develop it.