powerobjects: Decommissioning a System Administrator
What happens when your Dynamics 365 for Customer Engagement system administrator decides to leave the company? Ugh, right? It’s not something we like to think about, but it is certainly a very real business scenario. In today’s post we’ll walk through all the things that need to be considered, contemplated, and changed when this happens, as well as how to avoid these potential problems the next time your system admin jumps ship.
First, when this scenario does reveal its ugly head in your organization, which of the following should you do? (Hint: there’s only one right answer.)
2. Offer him/her a much higher salary to stay.
3. Disable his/her user record and just pretend everything is going to be ok.
4. Quickly, carefully, and efficiently analyze your system and make the necessary adjustments.
Hopefully, your answer is option 4 – after all, it’s the right answer. (Well, unless you have an unlimited budget, in which case you may want to consider option 2.) So, let’s get started on quickly, carefully, and efficiently analyzing the system and making necessary adjustments.
For Immediate Consideration
Most D365 for Customer Engagement system admins have a variety of roles within a company. They may be responsible for:
But from a security perspective, they can’t remain an active user either. So, once again… what can you do – specifically – to avoid those headaches? And no, enticing them to stay by doubling their paycheck still isn’t the right answer. Instead, let’s go step-by-step to ensure we keep your system up and running at full functionality.
Processes (Workflows and Business Process Flows)
Since workflows run in a user’s context, we need to first reassign any workflows and business process flows that are owned by the former system admin. In Settings > Processes, find any activated processes that are owned by him/her and reassign them – ideally to the new system admin, but if that person is not identified or hired yet, reassign them in the interim either to someone with sufficient system privileges or to a Service Account (more on this later). Importantly, don’t forget to reactivate each process afterwards.
If your system has any automation in terms of sending emails, you must check whether any of those emails are being sent from your former system admin. If they exist in any To, Cc, or Bcc fields, that’s ok – you can (if you choose to) leave them without causing future failures. Having said that, our recommended best practice is to remove them.
If they exist in the From field of any emails – typically created via workflow send email steps, it means all those emails will be sent in the context of that user’s mailbox. Once the person if disabled from the system, those emails cannot be delivered. This is likely to occur when you have workflows designed to send notifications in the event of certain activities within Dynamics 365. For example, you may have a case assignment workflow that emails the new owner when they have been assigned a case – if you want that email to be sent and received, you’ll need to change it so that the From field is an active user (more on this later).
This is where it gets fun!
So, what if your departing system admin used his/her credentials to set up external connections into CRM? If so, you now know two things:
1. This admin was either doing a lackadaisical job or was focused strictly on guaranteeing job security – in either case, at least now you know for sure that you don’t want to double that salary!
2. You have problems that need to be dealt with right away.
You must examine all of your external integrations, including:
Personal Views, Dashboards, and Other Records
This is not as critical as the previous items because a personal view or dashboard that has been shared to multiple people will not be affected if the original owner is disabled. However, unless Assign (or other rights beyond just Read) have also been shared, you may be stuck with these Views and Dashboards… forever! That’s right, you’ll never be able to change them. What that means is that if your departing system admin (let’s call him Aaron) created a Contact View called Aaron’s Team and shared it to others with read-only access, every person with whom he/she shared it will forever have this View – and because views are listed alphabetically, they’ll suffer the added inconvenience of Aaron’s Team showing up first forevermore!
Luckily, that’s not exactly true. How do you make it go away? Use the magical REASSIGN RECORDS button (highlighted below) on the user record – it will reassign all records and views to someone else. Phew!
The time it takes to complete reassignment will depend on a few different things, including the number of records to be reassigned and whether or not the reassignments cross business units (reassigning records leads to Dynamics 365 adjusting the record-sharing table in the background).
Disabling the User
The last step – disabling the user – is the easiest. You can do this from the Office 365 portal by simply removing the user’s Customer Engagement license (alternatively, you can remove all security roles).
Preventing this in the Future
So, what’s the biggest lesson learned here? “SERVICE ACCOUNTS!”
Need to see that again? Here it is, in more detail this time: “USE SERVICE ACCOUNTS!”
Here’s what we mean:
In many Dynamics 365 for Customer Engagement deployments – and in all CRM on-premises environments – user logins are tied to an Active Directory user within the company (or you can also authenticate users directly within Office 365). In either scenario, you have the option to create non-user accounts. These are logins that only a handful of people in the company have access to and that are not tied to any particular individual. These logins have many different uses, and they can be configured to have full access to your Dynamics 365 application. There are different ways to reference this type of login, but for the purposes of this blog, we’ll refer to it as a Service Account (recall that we mentioned these earlier and promised to get back to them).
So, if you have an activated workflow that does not need to be assigned to a specific individual, the best practice is to not assign yourself (or the developer) as the owner. Instead, assign it to a Service Account and activate it. And if you have a more complex setup where workflow owners belong to different business units, you can easily create a unique Service Account for each use case.
The end result of this approach? In the event that a system admin leaves your company, you can quickly and safely change the password of the Service Account(s) being used to run workflows – without impacting anything.
Note that it is also a must to always use a Service Account for any integration that connects to Dynamics 365 externally, such as SSIS, Scribe, Email router, etc. And we always recommend using a different account for each process, as doing so provides two clear benefits:
So, there you have it… what to do when your system admin jumps ship and how to avoid the ensuing problems in the future. We hope this was helpful (and saves you some money and headaches in the process).
Don’t forget to subscribe to our blog for more Dynamics 365 tips!
Happy Dynamics 365’ing!
The post Decommissioning a System Administrator appeared first on Microsoft Dynamics 365 | PowerObjects.
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
|powerobjects: Hide System Views, Forms, and More via Custom Apps!||Blog bot||Dynamics CRM: Blogs||0||11.05.2018 22:14|
|Удаленная работа с CRM и расширеный поиск||ASheff||Dynamics CRM: Разработка||64||04.06.2010 17:44|
|Ошибка бизнес-процесса||Tarasov E||Dynamics CRM: Разработка||9||18.02.2010 14:02|
|Не публикуется бизнес-процес||Soulcar||Dynamics CRM: Администрирование||6||04.02.2010 19:35|
|wiki.dynamicsbook: Changes Made in Navision Attain 3.60||Blog bot||Dynamics CRM: Blogs||0||02.09.2008 13:23|
|Опции темы||Поиск в этой теме|