Offboarding

Like what you see??

"Ask Sympraxis" is a bi-weekly webinar series, where we discuss an array of topics and answer your submitted questions. Join us by downloading our recurring calendar event. You can also join us directly in the meeting without downloading the event.

See a listing of Ask Sympraxis episodes by topic covered: Topic List, Series List, or a full listing Archive

Life happens. People join an organization and folks leave organizations. It can be a personal decision, a termination, or maybe even just a temporary leave, but regardless of the reason we’ve compiled our suggestions of better practices to minimize the impact when offboarding an individual.

First off, clean onboarding leads to easier offboarding. This means that there are certain suggestions we have for when you set up your accounts that will better prepare your organization for if/when an individual leaves.

  • Build dynamic groups with a rule including accountEnabled equal to active. We highly suggest taking advantage of dynamic groups. A dynamic group is built on a specific attribute instead of the users themselves. If you set the dynamic group rules to accountEnabled equal to active then as soon as you deactivate an account, that individual will be automatically removed from the group as the attributes no longer match.

  • Use Microsoft 365 groups for team calendaring. Usually there is a designated person who is the owner of a recurring meeting meaning they are also the owner of the calendar invite and that invite is tied to their account. Thus, we suggest instead of rebuilding all these recurring meetings off personal accounts, build them in the M365 group accounts instead. When that individual leaves, the meetings then stay the same.

  • Power Platform Governance Once an item in the Power Platform is launched, add a group of owners or service account. When you’re building Power Platform things (PowerApps, Power Automate flows, etc.) you can build that in the context of your user account, but you’ll want to change it to a group of owners. Our better practice we suggest is having those apps or flows use a service account, so you don’t have to worry about the user leaving. If your flows are using connections to data, you’ll need to verify that the connection is changed to a service account or user that is active.

  • License by Group. If you don’t delete the user and just deactivate them, then they likely still possess some licensing that you’ll need to go in and delete manually. Instead, you can now apply a license to a group, so anyone assigned to that group has access but once an individual is removed, their licensing is also immediately removed.

Document your offboarding in Learning Pathways

Visual demonstration of various sites leading into a Learning Pathways playlist that is hosted on the HR Communication Site as a Learning Pathways Web Part.

Another helpful tip to ease the offboarding process is to document your offboarding process in Learning Pathways. Offboarding generally crosses a lot of different departments (HR, Finance, IT) and it’s super helpful to increase the transparency of that process within your organization. Learning pathways lets you distribute the content authoring to the users that manage the processes (HR, Finance, IT, etc) and then bring all the content together in one playlist for everyone to consume.

Implication of maintaining user accounts

Visual list of the pros and cons of maintaining accounts. The following paragraph describes most of these.

Overall, we believe in most cases it makes sense to not delete users when they leave (or at least not right away) but instead to deactivate them. The slide above lists the pros and cons we have seen based on offboarding this way. By deactivating you can actually log back into their account and see what they’ve done. You can also easily reactivate the account if the individual returns to your organization. Deactivating also protects you against login or email reuse. For example, if your employee, John Doe, leaves the company and you delete the account instead of deactivating and a new John Doe joins, then you risk email address reuse and emails meant for the old John might go to the new John. This could have security or compliance related concerns.

We have seen other workarounds to this including changing the username in some way. For example, some organizations add “zzz” to the individuals first name when they have left the org so that their account is accessible but clearly indicated as having left and filters to the bottom of lists. We argue this looks and feels a little odd. Although there are plenty of reasons for why deactivation is better in our opinion, there are a few cons. For example, unfortunately those phantom users can show up in the SharePoint search. Also, although there is a slim chance of this, there is a potential increase in the attack vector as there are additional accounts available to be attacked.

When they leave

Visual representation of the steps you should take when someone leaves. The majority of these are covered in the following paragraph.

These are the steps we suggest if you want to deactivate an account but not delete it. First thing is you must disable the account and reset the password so in the off chance the account is re-enabled, the employee who left cannot log back in. You should also wipe all devices that the account was logged in on. Also, if you haven’t done licensing by group, then remove the license. For their email, we suggest converting their inbox into a shared mailbox. This will prevent you from losing all the content in the mailbox. You can also set up an autoreply or have the mail forwarded to another address.

For Power Platform, you need to know which flows the individual owns and reassign them to someone else. For SharePoint, our best practice suggestion is to require each site to have a minimum of 2 owners. You can create this rule in groups. When you have this rule and someone leaves the organization, then you’re required to replace that individual with someone else. See below how to find sites and Teams where an individual is an owner.

List of how to find  sites and team if an individual is an owner. Include filter SharePoint admin, run report in audit log, run custom report in Sharegate, and create PowerShell, C#, Type/JavaScript custom solution.

Content implications and next steps

When an individual leaves, we argue that it is still important to maintain that individual’s name on content they wrote and/or modified. This historical documentation is scrubbed by fully deleting someone. If you reassign the ownership of the content (which you can in Sharegate) then you’ve lost the aforementioned connection. However, in some cases this might make sense. You might need the new person to have ownership for Power Automate Flows.

Overall, the decision to delete versus deactivate is primarily an IT decision as you might have organization specific compliance requirements that force you to delete the accounts. Therefore, make sure you check with your IT department on what practices are required at your organization. Thus, depending on your industry and corporate regulations, any one of these things might not be the right thing for your organization but overall, we believe these to be better practices.

All Resources


Do you have any questions for us? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.