If you are thinking about a Dynamics 365 implementation for your organisation, here are some of the IT tools/portals/apps that we believe your team is going to need to work with - and that you will need to make available or prepare.
Plan ahead and estimate the effort/licenses needed as these costs and timings should be budgeted for.
We are not going to make you wade through a long verbiage to extract some value from this article, instead we will start with the list and then breakdown for each component key things we tell our customers to help them understand the why, when and what not to do?
Microsoft Teams or similar
SharePoint [OneDrive]
DevOps
Azure
Lifecycle Services (for Dynamics 365 Finance, Supply Chain or Commerce)
Microsoft 365 Admin Portal
Power Platform Admin Portal
Power Automate
Power Apps
Prerequisites:
Whilst not truly speaking to any element on the list above something we often see missed or time not allowed for, is the full completion of your Vendor Onboarding Processes for your chosen Dynamics partners and supporting partners like us at ERPWorks - D365 Assurance & Leadership.
This often causes delays at the start of the project where tasks that take IT minutes to execute are held up for days and sometimes weeks awaiting completion of approvals that should have been done during onboarding.
Microsoft Teams
Communication has to be at the heart of any successful project, so get started from day 1Â by giving your teams (INTERNAL & EXTERNAL) access to a secure location they can communicate. However, we have some recommendations for MS Teams as below:
      
Make sure this MS Teams is hosted in your Microsoft tenant, not your partners. Your data (and potentially that of your own customers) should remain in your control as much as possible and ideally never leave the safety of your network. Â
Ask your IT people if the external partners helping you with this project can have a level of federated access (just to MS Teams at this point) so you can all communicate without having to constantly switch between 'personas'. This switching causes many communication delays and unnecessary frustration to all parties. There are a few ways this access can be granted; your IT team will need to decide what best fits with your organisations security policies. Useful Link: https://learn.microsoft.com/en-us/microsoftteams/communicate-with-users-from-other-organizations
Note:Â This activity will probably trigger the first of your organisations 'security concerns' and hopefully your own security protocol will define a process the partners can go through to get approved for access such as the completion of DPA's and DPIA's where relevant.
Make your PM an 'Owner' of the MS Teams Team. This makes it easier for add users on-demand during meetings etc. Removing a common 'I cannot access that' complaint....
Encourage the use of the Chat feature to avoid emails - the less emails the better as things get lost in emails and only people who are actively included in that chain can later see/find the information. Often key information/risks get buried in emails for 'CYA' purposes when its actually much safer for all concerned if that was visible in a chat log within the projects team site.
Use the Channels feature to segregate groups of people, chats and documents logically:
We recommend you create a structure of sub-channels where 'stream' specific conversations can be held. The example below is from our 'ERPWorks-Control' toolset that we offer to customers for free as part of an engagement with ERPWorks - D365 Assurance & Leadership.
      
We recommend each sub-channel is private, allowing some conversations to have a limited audience but available to the Programme Leaders as needed.
SharePoint / One Drive
Keeping your documents in a place that all team members can easily get to them, share them and also share 'where' they are to new team members really helps. We recommend using the MS Teams >< Files SharePoint location to store these files. We believe this should include the original 'sales pitch' documents you received from your partners as well as all SoW's and NDA's etc all stored neatly and available to be reviewed.
Tip: Use MS Teams as the front end to your 'SharePoint' site. This normally has all the features you need and reduce the number of applications your project users need to interact with directly. All sharing can be managed from within the MS Teams site.
We recommend you create a folder structure within your MS Teams / SharePoint site, so your documents are easily found as you get many months into the project!
Azure DevOps
Many organisations will have their preferred 'task tool' but we believe that for D365 you really cannot get better than using Microsoft's Azure DevOps platform.Â
Useful Link: What is DevOps? DevOps Explained | Microsoft Azure
Process Templates:Â Often your partner will come to the project with their preferred process template, that you can deploy. In some cases, they will request permissions in your DevOps environment to be granted to allow them to deploy their process template. Don't be scared to grant this on a temporary basis, because as soon as it's been completed you can rescind those permissions and move them back to a more normal external party, security role.
In our case we recommend that you establish some clear guidelines from your partner, or your internal IT teams about how the DevOps Work Items should interact/link with each other. Using the ERPWorks - D365 Assurance & Leadership >  ERPWorks-Control process template as an example you can see below how we make sense of it all.
We have 17 Work Item Types in our process template, each record gets a custom set of fields based on our years of experience to save your implementation time.
Azure Portal
Dynamics 365 being a cloud hosted application will require some form of connection into your organisations Azure Tenant and you should prepare your IT teams to become involved in these discussions. The project will need access to a resource that has the Administrator level privileges to your Azure Portal.
You may want to create Resource Groups and pre-define 'Tags' to enable you to track the costs of any D365 related environments back to its source project.
Your users will need multiple D365 environments to be provisioned for use both during the project and some will also last into business as usual (BAU). Keeping a track of 'where' these are hosted, what they are called, how much resources (Storage & compute) they need and how those costs are managed is something that can be easily overlooked.Â
Implementation project teams can be more focused on making sure the applications functionality works, rather than ensuring you have the ability to manage support and secure the environments.
Tip: To deploy a new D365 Finance environment from Lifecycle Services you can expect to see the below components reflected in Azure:
1 Virtual Machine
5 Disks
1 Load balancer
1 Regular NIC
1 Network Security Group - don't forget this as its used for security!
1 Virtual Network
1 Public Facing IP Address
1 Storage Account
Lifecycle Services
Microsoft operate a portal called 'Lifecycle Services': http://eu.lcs.dynamics.com/v2Â from which the Dynamics 365 Finance and Operations Apps are deployed. Someone inside your business is normally assigned to be the 'Organisation Admin'. We have seen this being a variety of people from an IT team member, to a member of the purchasing team. It's worth finding out who this is before you get too far into your project planning.
Note: This is different from the way that Dynamics 365 Sales, Customer Service and Field Service are deployed, as these are directly managed through the Power Platform Admin portal instead (D365FO is moving onto that portal but it's not fully there at the time of writing this article).
Microsoft 365 Admin Portal
This may seem a strange topic to bring up when thinking about deploying a Dynamics 365 product, but you still need to assign certain users with application licenses through the Microsoft 365 Admin Portal. This means you will need to find who in the business has the permissions to do this, and if there is a defined process your project will need to go through to request a license assignment. This is critical when deploying Dynamics 365 Sales, Customer Service or Field Service. This is also a consideration if you need to use any components of the Power Platform (mentioned below).
However, if you are deploying Dynamics 365 Finance, Supply Chain or Commerce then you don't need to pre-assign licenses for these application to users in all circumstances.
Power Platform Admin Portal
Our recommendation is to deploy Power Platform Environments alongside all deployment of the Dynamics 365 products, regardless of their type (CE, CRM or ERP). This is because the toolset in the Power Platform is leveraged by all of them to a greater or lesser degree. Having some 'admin' control in this area of the deployment will be critical to your success and to avoid delays.
If you want to provision D365 Sales, Customer Service or Field service then this process starts in the Power Platform Admin portal.
If you want to provision D365 Finance, Supply Chain or Commerce then that process starts in Lifecycle services but you will need to have the user that does the LCS deployment, also having permissions inside the Power Platform environment as well. This is because it's during the 'deployment' activity that you must link D365 Finance, Supply Chain or Commerce to the Power Platform. It's much harder to achieve this after deployment. In some cases, it's impossible!
The admin portal can be accessed through this link: https://admin.powerplatform.microsoft.com/
The resources that are used in the Power Platform (Compute & Storage typically for the VM's you might want to deploy) are consumed from your Azure Subscriptions, that we mentioned earlier in this article. So this ties back to that advice that says make sure you have access to a resource that has the Administrator level privileges to your Azure Portal.
Note: You will have heard a lot about the recent launches of the Microsoft Co Pilots for various apps. This is all powered through the Power Platform. We recommend you make sure that you open this door and put yourselves in a position to be able to take advantage of what we believe is the most invested in area of Microsoft business applications in 2023-25!!
Power Automate
Understanding what Power Automate is, takes you 50% of the way to realising why its something that you are going to need. Note that we have said need and not 'want'. Simply put that workflow engines inside the Dynamics 365 Apps are not as powerful, capable or flexible as Power Automate is.Â
Microsoft have made it easy for you to connect Power Automate with your Dynamics 365 apps - for D365 Finance in particular they have given you fully functioning workflows out of the box as you can see below. In addition, they have created 20+ pre-built options that you can build upon to link D365 with MS Teams, Microsoft 365 and almost any 3rd Party application you can think of.
PowerApps
The last step on your journey, but one not to ignore is the use of Power Apps. There are now many core in-built features of the Dynamics 365 applications, that really only come to life when paired with a solid 'mobile application'. These mobile applications are now delivered as Power Apps.
Some good examples are:
Expense Management - This uses a Power App, that connects to your D365 Finance application (Dynamics 365 expense management mobile app overview | Microsoft Learn)
Time Entry for Projects
Financial Reporter Add-In
We do not recommend you create Power Apps without an experienced internal team that can confirm your app is secure, efficient and not going to open doors to data that shouldn't be opened. That said the Microsoft deployable 'solutions' that deliver pre-built apps for given circumstances are very useful.
Summary
We hope that you have some appreciation of the available tools and why as a set of topics you will benefit from knowing about them, preparing for their use as part of your Dynamics 365 journey.