Managing Solutions in Dynamics 365 Part-2
Part One: What are my options, and why are they important?
The days of long product life cycles, where nothing materially changes for 2-3 years, are gone. And as we move into a cloud-based world, Dynamics 365 is a game-changer for Microsoft technology partners and our customers alike. Each passing week brings more information on its roadmap and the options we can choose from.
But time and time again we tend to collate and relay this information on without thinking about who needs it the most. There are many amazing blogs and whitepapers out there, but even I (after a decade of living and breathing Dynamics AX), struggle to decipher them. So how can we expect our customers to work out what's happening, and more importantly, what path they should take?
This blog will steer you around the information overload. I'll present the facts in a way that's easy to understand, gets you excited, reduces confusion, and at the same time gives you the knowledge you need to start your Dynamics 365 journey.
Upgrade to Dynamics 365 now - the end of days are upon us!
Ok, it's not as bad as that.
But for people on Dynamics AX 2009 or 2012 RTM and R2, mainstream support ends in April 2018. That's less than a year away.
So if you haven't already started down the path towards Dynamics 365, now's the time to start thinking about it. Extended support for both AX 2009 and 2012 are still available until 2021. See Microsoft's explanation for more information on the differences between mainstream and extended support.
Most of you (and in particular those with ERPs that have been live for a number of years) get support from technology partners. So, the ending of mainstream support from Microsoft may have no real impact. But as time progresses, I confidently predict it will become harder and harder to get quick and skilled support to ageing, outdated versions.
So, what now, and where did you put my Dynamics AX?
Put simply; Dynamics AX is now the 'Operations' portion of the Dynamics 365 solution.
Dynamics 365 brings together a range of core Microsoft business products into a single offering. It has significantly improved integration and interoperability. But the technology changes and the underlying platform are even more important - the entire solution, including Operations, is now available as a true Software as a Service (SaaS) solution.
What does this mean?
Well, for a start, you can throw out your ageing servers and let Microsoft manage everything. You can pay as you go. You can get continual updates. And, as long as you have a decent internet connection, you can access the system from anywhere.
This has major implications for everything from licensing, to development, to implementation and much more. But never fear, for those that can't adopt the SaaS model, Microsoft also offers an on-premise option.
You also have two editions to choose from:
Dynamics 365 Business Edition:
Business Edition is a cut-down version of Dynamics NAV with Dynamics CRM's Sales, Marketing and Customer services modules. It's aimed at smaller businesses and is the less expensive of the two options. It is currently only available in the US and Canada.
Dynamics 365 Enterprise Edition:
Enterprise Edition is the whole kit and caboodle, made up of Dynamics AX and the complete set of CRM modules, including Project and Field services. For customers already operating Dynamics AX 2012 or older, this is the logical choice.
Cloud vs On-premise – surely one's better than the other, right?
There's no easy answer to this question, as every business has its own set of unique operating conditions.
But it's a big decision, not to be made lightly. Work with your technology partner to determine which path to take. I've listed some of the pros and cons to help you get a feel for which option would better suit your business. There are also some business-critical factors that can be non-negotiable – so those could, in essence, make the decision for you.
Options |
|
|
Cloud |
|
|
On-premise |
|
|
The upgrade options – more choices!
When planning an upgrade, you need to choose between two very distinct options:
- Technical Upgrade– utilises technical tools to convert your data and customisations to the latest version.
- Re-implementation – starts with a fresh installation and only migrates the data and code you need/want.
These options are different from each other, and both have advantages and disadvantages. Neither option is a clear winner for most customers. It comes down to what's right for you. Both options are expensive, so it's important you take the time to work through the benefits and drawbacks of each.
Most important of all , leverage your AX partner's knowledge to ensure you make the right decision for your business and situation. This is discussed in more depth in part 2, as it's a big topic.
Part Two: Re-implementation vs Upgrade - what do they entail?
You've made the decision to move to Dynamics 365 for Operations. You've heard there are two main strategies:
- Upgrade - the data and modifications on your current AX environment areconverted into anew Dynamics 365 environment
- Reimplementation - selected data and modifications on your current AX environment aremigrated into anew Dynamics 365 environment
These are two very different approaches. Which do you choose?
First, find out if you have a system that can take an upgrade
At the time of writing AX2012 R3 is the only version you can perform a complete upgrade from. Because 365 for Operations was based on Dynamics AX R3 CU8, any version that came after that should be safe. You can perform acode upgrade from R2, but not full data, so you'd need to do a two-step upgrade: AX2012 R2 > R3 > 365 for Operations if you want both.
Microsoft have released tools for upgrading data from AX2009 - but not code. So, this would still need a re-implementation as it only covers master data, open transactions, opening balances and configuration,not historical transactional data. But it should significantly reduce the data migration aspect which is not recommended without the right tools.
Here are some practical scenarios to consider:
- How long ago was my original implementation?
Direct upgrades aren't possible on older versions like Axapta 3 or Dynamics AX 4. It will take multiple jumps to get to Dynamics 365 for Operations, so upgrading is complicated and the cost may be prohibitive.
- What does my business look like right now?
Perhaps after going live with AX your business went in a completely different direction. Or was acquired by another company. Or maybe you sold off part of the business. In cases like these, it may not make sense to take the entire solution and move it forward to the latest version. It might be more advantageous to start with a clean slate.
- Is my Dynamics AX environment modified?
AX was a wonderfully easy system to customise. And your AX partner would have advised you to adopt standard best-practice for your modified processes. I've seen some truly amazing customisations with fantastic outputs that can be upgraded relatively easily. However, if your AX environment is heavily modified with non-standard processes, then reimplementation may still be the more logical option. Take this opportunity to think critically about your processes and how close they are to standard. Can you rebuild the required enhancement in a way that's in line with best practice and then upgrade? Or will you still need to reimplement?
- Do I have an ISV solution as part of my base product?
Microsoft acquired and assimilated many Independent Software Vendors (ISV) solutions into the core AX product. Examples include Ebec's Lean Manufacturing, Fullscope's Process Manufacturing/Distribution and Blue Horseshoe's WAX and TRAX.
Microsoft re-wrote a lot of the ISV functionality making it impossible to simply move the code forward. Businesses using AX2009 or older will have to drop the ISV layer and remap their processes and data to the new code. I've never seen this achieved before, and am extremely reluctant to suggest it. Re-implementing onto a fresh install of Dynamics 365 for Operations seems the most logical choice.
- Do I want to change my mind about previous setup and configuration decisions?
An ERP implementation is a large and complex beast. Even with the right information, partner and timeframes, it's still possible to end up with a system that isn't quite what you thought it would be. Financial dimensions, for example, can go through multiple iterations of design and build until you settle on the final setup. But don't worry, you don't need a DeLorean to rectify this. By reimplementing you can change core decisions and create a solution that's a much better fit for your business. And as you've already used a version of AX, your knowledge of the ramifications of each decision puts you miles ahead.
Let's go into some details to give you a better idea of which approach is the right one for your business:
Reimplementation
Re-implementing basically means firing up a clean version of Dynamics 365 and migrating the data and modifications you require.
If you're used to system implementations, you know what to expect. And be assured, migrating data and modifications from one AX system to another is much easier than when a completely different ERP is involved. And Microsoft provides some clever and helpful tools. Reimplementation gives you a chance to review, rationalise and cleanse your data, so you only bring across what you need. However, movingtransactional data is nearly impossible, so you won't have your history in the new version. Your opening balances will map across just like they would have during your original implementation. Reporting can bridge the gap between the old data and the new, but this needs to be factored in and planned for. Just be prepared for the fact you won't have seamless reporting across both the old and new data.
Pros
- Gives you a fantastic opportunity to take a good, hard look at processes and remove or rework bad ones.
- Your chance to remove redundant modifications. Each new AX release gives you greater functionality, reducing the need to modify the system.
- You can redesign data to better reflect your business. It's a common theme, either the system wasn't configured ideally to begin with, or the business changed over time and past decisions no longer fit. Now you can change things like the chart of accounts, financial dimensions, product structures and so on.
Cons
- It's intensive. Key users and subject matter experts need to invest time in design workshops, user acceptance and end user training and more. Backfilling temporarily vacated roles is recommended, or the project has a high chance of failure or dragging on. Which usually leads to substandard outcomes.
- Loss of transactional data. While a positive for some, it makes life harder for businesses who rely heavily on this function. Being unable to make quick enquiries on past orders, old item codes, lost sales and so on can be a big drawback.
- It's time-consuming and expensive. Typically, this approach takes more consulting power to redesign processes, configure the new system, unit test, write specifications and so on.
Upgrade
Upgrading is a more technical process. Using a series of tools and scripts, the data, codes and modifications in your current AX environment are converted across into a new Dynamics 365 environment. The conversion itself only takes a single weekend, but there are several practice sessions before doing it for real. You need to run full regression testing because you can't take anything for granted. The conversion tools are incredibly smart, but they won't cater for every possible configuration of a Dynamics AX environment. You need to carry out user acceptance testing for each business process to ensure the data and customisations are working. This is where a good Dynamics 365 partner can make the difference between success and failure, as they'll help find and resolve issues where the scripts haven't worked correctly.
Given the young age of AX 2012 R3, the number of businesses that can upgrade directly is small. And as their implementation will be relatively recent, the motivation and reasons to upgrade will be low. There'd need to be a compelling reason to shift again so soon.
But for businesses on AX2009 or older, it's definitely time to start looking at what Dynamics 365 for Operations can offer from a technology perspective - cloud-based, incredibly tight office integration, operating from any device, part of Dynamics 365 total solution and so on. There's also the functional perspective including access to out-of-the-box verticals such as Process Manufacturing, Lean Manufacturing and Retail.
What next?
The next big question you probably have at this point is how much and how long?
Part Three: "Next-next-next, it's that easy, right?" - internal resource requirements
The most common (and logical) questions I'm asked are 'how long will it take?' and more importantly, 'how much will it cost?'
Unfortunately, some form of discovery is needed up front before I can give an answer. Just like a builder asked to estimate the time and costs of renovating a house, even if the owner can describe the building size, number of rooms, house type etc, an onsite inspection is essential before a realistic estimate can be made. Even putting it in a range is challenging, as influencing factors include:
- company size
- number of users
- business/industry complexity
- geographical spread
- 3rd party solutions
- EDI and other integrations
- wireless warehousing
- your ability to backfill key user roles
- the appetite for change within the business
- executive buy in and direction
- preferred approach e.g. re-implement or upgrade
So to make the time and costs clear from the outset, your Microsoft Partner will create a map which details the complexities of your current solution, and then produce a future-state map of the new version. This demonstrates how all the parts of the new solution integrate, and gives a great visual blueprint to refer back to throughout the project. I've always found my solution maps on the project wall, well viewed and under discussion.
The devil is in the detail
While I draw on the many customer upgrades I've done in the past and my knowledge of the architectural changes in Dynamics 365 for each new project, it's important to remember that there will always be unknowns. You should always factor in contingencies (in terms of time and budget) to any planned upgrade. That way you won't be caught out part-way through the project when those unknowns rear their ugly heads.
Another thing to factor in to a Dynamics 365 upgrade is the code sealing. Microsoft are 'sealing off' the application code over the next year, which means existing customisation must be rewritten as an 'extension', rather than using the old method of 'overlaying'. As this blog is more business level than technical, I won't expand here. However, there are some great blogs out there that dive into the technical details, and your Microsoft Partner can explain further if required. The point is, careful planning and execution is required to deliver an upgraded system that conforms to Dynamics 365's new architectural principles.
Our two project approaches – cooking an egg
The following step by step breakdowns give you a basic idea of the major activities involved in an upgrade or a re-implementation. However, there's more than one way to cook an egg, so bear in mind that these may not describe exactly how your unique project will run.
Re-implementation
As mentioned in parts 1 and 2 of this blog series, a re-implementation runs a lot like a full-blown ERP implementation. So these steps are likely to feel familiar if you've done that already. However, there are some subtle differences when moving from one version of Dynamics AX to another.
Step 1 - Solution Review
Your business consultant runs a series of workshops for each functional area, which fully reviews your current AX processes. The consultant needs to understand your business and identify areas for change in the upgrade to Dynamics 365 Operations, including business processes, data and modifications. At the same time, your subject matter experts have the chance to learn about new opportunities for process improvement. Your consultant documents all these points, and this becomes the macro design of your new system.
Step 2 – Design
A second set of workshop sessions with the consultant and key users from the business drills into the areas where change will occur. These might, for example, look at the effects of increased use of the system, or at modifications that need re-engineering due to changes between versions. The output of the design phase is the functional and technical design specs necessary to build the new system.
Step 3 – Build
The new environments are created once the solution review and design are finalised and signed off. At this point there's usually a development freeze on the current solution, as well as a freeze on new projects to extend the system e.g. implementing new modules. Technical consultants migrate all the agreed customisations from the current solution into the new development environment, and work on them as required. This step requires little or no input from your business.
Step 4 – Configure
This step runs parallel to Step 3. Functional consultants and key users migrate the configuration, master data and opening balances from the current solution to the newly-created configuration environment. The result will look a lot like the final solution.
Step 5 – Unit Testing
Before handing the environment back to you for testing, the work performed in Steps 3 and 4 is checked against the functional and technical specs from the design phase. This may require some rework on the code or data migration steps, which is typically performed by the functional consultants. This step requires little or no input from your business.
Step 6 – User Acceptance Testing
The testing environment is handed back to you, along with a full test plan and test cases to drive the process. This part of the project is structured, documented and transparent. Consultants are available for support, but this stage is owned and driven by your business.
Step 7 – Go-live
Over the go-live weekend, the opening balances migrate and any other cutover activities specific to your business are performed. The new system is up and running with limited access to your old AX environment on the Monday. A full resource plan ensures you have both internal and external resources at your disposal. The success of this phase is hugely impacted by the level of testing done in Step 6. There are no shortcuts: test test test!
Upgrade/Technical Upgrade:
What's the difference? Well, a non-technical upgrade takes a wider view, looking at improving processes, reducing customisation, reorganising data etc. A non-technical upgrade is similar to a re-implementation from a phase perspective. So the following steps focus on a straight-forwardtechnical system upgrade. This doesn't require the same level of input from your business, as the goal is a 'like for like' transfer of processes with no re-engineering (unless forced to by the system). The tasks are, obviously, more technical in nature, but there should still be a full user acceptance testing cycle at the end of the project that requires a high level of input from you to ensure the project's success. The steps below outline the most basic upgrade, and assumes you're moving from Ax2012 R3 to Dynamics 365 for Operations. If you're on an older version, then you need to upgrade to AX2012 R3 first, but this can be done as a double hop in the same project (effectively doing Step 2 twice).
Step 1 - Solution Review
A business consultant runs series of workshops for each functional area of your current AX processes, with a view to understanding which ones will need the most testing, and if any re-design or re-engineering is required. If you're starting out with a standard AX, the process should work smoothly as soon as the upgrade scripts are in place. However, modified areas may upgrade imperfectly without some re-design and re-engineering.
Step 2 – Upgrade
This is where the fun begins! Depending on which version you're moving from and to, what ISVs you have, how many modifications your current solution has and so on, activities in this step will vary. But at a high level there are two objectives:
- Upgrade the code
Developers use a series of tools and techniques to upgrade the code, which is relatively straight forward if your existing environment isn't highly customised. However, the more customisations you have, the more resource intensive this step becomes. If there are changes in the data or code structures between versions, your code may need re-engineering. And as mentioned previously, code in Dynamics 365 should (and soonmust) be done via extending, not overlaying as in the past.
- Upgrade the data
Developers also use Microsoft-provided tools to upgrade the data in the system, and in theory this is straight forward. However, experience has shown me it can be time consuming, because Microsoft scripts can't cater for every possible system configuration. So you may find additional custom scripts are needed to address any issues found during this process.The outcomes of Step 2 are:
- An upgraded test system
- A document of every single step required to upgrade
Documentation is the most critical part, as this process is repeated multiple times, and again on the cutover weekend. Having consultants and developers document all steps is crucial to ensuring repeatability and consistency.
Step 3 – Unit Testing
Before handing the environment back to you for testing, the work performed in Step 2 is checked and the system is matched against the agreed design from Step 1. This may require some rework on the code or data migration steps.
Step 4 – Test/Upgrade/Test/Upgrade/Test
The system is handed back to your key business users, along with a full test plan and test cases to drive the process. This step involves multiple cycles to make absolutely sure the upgrade can be repeated step by step and achieve the same outcome every time. Once proven, the system is ready to go-live.
Step 5– Go-live
The upgrade runs one final time on the go-live weekend. As the process may take both days, you might need to shut your systems down on Friday. But if all goes to plan, then your new system is up and running on Monday with limited access to your old AX. The testing in Step 4 should ensure a smooth journey, but if a new or unexpected issue arises during the cutover (for example, I've seen cases where the live servers had subtle differences which resulted in major knock-on problems), the most prudent thing to do is usually aborting the upgrade and setting a new date for going live.
Who's who in the zoo
Having the right internal resources is critical for project success. And as with everything I've touched on in this blog, who and what you need can vary. This is a table of the most common resources. Ideally you'd have them all, and often one person can cover multiple roles:
This blog should give you sufficient knowledge of the steps and business resources needed at each point in an upgrade.
Fusion5 can carry out an upgrade assessment that helps you work out the right approach for your business and puts your mind at rest on the costs involved in upgrading to Dynamics 365.
So, now you have the information, and you know the effort involved. In the final part of this blog series, I'll help you to answer the question: 'Why is an upgrade the best thing for my business right now?'
Part Four: That's all well and good, but why bother?
This series has given you a high-level overview of the benefits of Dynamics 365, and practical advice on Upgrading your existing environment or re-implementing onto a clean one. But an upgrade or reimplementation is costly, time consuming and disruptive for any business. Obviously you want to be absolutely certain that the effort involved in completing the project is justified and that the benefits significantly outweigh the costs. Obviously. Yes?
However, I've seen upgrade projects where the reasoning was not clearly defined. Or even if it had been, it wasn't front of mind and referred to regularly during the process. I've also seen completed projects where no one thought to measure back against the original objectives. Even when those outcomes are as simple as getting back to a supported version, or make use of wireless warehousing functionality to reduce inventory errors by 25% and increase picking speed by 30%.
If your reasons for upgrading are sound and there's a sensible and achievable ROI, then it's worth your time, cost and effort. In this post, I'll outline some of the common reasons behind an upgrade to get you thinking clearly about your own.
Upgrading to get better technical or functional support
1. Technical - The annual Microsoft software maintenance payment lets you log support calls with Microsoft and gives you access to hotfixes as they're released. Hotfixes that enable AX to work on newer versions of server software or resolve security flaws can be crucial. We've all seen the disruptive power of modern cybersecurity attacks, most notably the recent WannaCry hack. Although this exploited a Windows rather than AX flaw, it highlights the importance of being up to date. I'm aware of at least one Dynamics AX customer whose servers suffered during the WannaCry attack. Microsoft only supports a particular version for so long. Then it expects customers to move to a newer version. On Dynamics 365, these platform updates can be easily applied by Microsoft. Check the chart below for details.
Products Released | Mainstream Support End Date | Extended Support End Date | Service Pack Support End Date |
Microsoft Dynamics AX 4.0 | Not Applicable | Not Applicable | 1/08/2008 |
Microsoft Dynamics AX 4.0 Service Pack 1 | Not Applicable | Not Applicable | 10/13/2009 |
Microsoft Dynamics AX 4.0 Service Pack 2 | 10/11/2011 | 10/11/2016 | |
Microsoft Dynamics AX 2009 | Not Applicable | Not Applicable | 1/11/2011 |
Microsoft Dynamics AX 2009 Service Pack 1 | 4/10/2018 | 10/12/2021 | |
Microsoft Dynamics AX 2012 | 10/09/2018 | 10/12/2021 | |
Microsoft Dynamics AX 2012 R2 | 10/09/2018 | 10/12/2021 | |
Microsoft Dynamics AX 2012 R3 | 10/12/2021 | 1/10/2023 |
it's only natural that a consultant's knowledge of previous ones begins to fade. They're living and breathing the latest version. The changes between V4, 2009, 2012 and D365 are vast. Not only from the user experience perspective, but in terms of technology and functionality as well. This may not be a strong enough justification to upgrade in itself, but it certainly forms part of the reasoning. Using old versions is a constraint on your business operations, making it much harder to get fast, quality support and effective project work done on your existing system.
Upgrading for technological advantage
Moving to the cloud is probably the biggest technological reason for upgrading to Dynamics 365. This one change opens up a host of opportunities:
- There are no servers to purchase and manage - Microsoft provisions and manages everything you need to run Dynamics 365 optimally. This takes a huge amount of stress off your business. You can leverage from the incredible economies of scales within Microsoft datacentres around the world, and there's no need for second guessing when it comes to your infrastructure configuration.
- Simple integration - Now that Dynamics 365 is in Azure it can leverage off the entire Microsoft stack. Integration may not require the writing of even a single line of code. By utilising the common data model alongside apps such as Flow, Logic Apps, Power Apps, connecting data from various software has never been simpler.
- Scalability - If your business has natural or predicable peaks and troughs, Azure lets you scale up and down as required with the click of a button. You can view your user numbers and Azure environment accordingly, only paying for increased sizing when you need it.
- Anytime/anywhere - There are no barriers to accessing Dynamics 365 in the cloud, unlike your internal network. As long as users have an internet connection, a web browser and the right privileges, they can log into AX from any device, anywhere in the world.
- Evolutionary not revolutionary - The days of major releases every 3-4 years, requiring your entire ERP to go through a major overhaul, are long gone. Predictable 6-monthly application releases mean Dynamics 365 continually evolves, getting better and better, without the need for huge upgrade projects. You do need to factor in the overhead of testing and applying the new release. But it can still be scheduled for whenever you're ready within a set time period. And because the system is now enhanced via extensions, rather than using over layering, updates can be applied without the fear of breaking the core system. New functionality is an opt-in approach.
Upgrading to drive or enable change
As mentioned in previous posts in this series, a re-implementation is great opportunity to re-engineer your process and your data to give you a clean slate to work with. You can also correct a configuration or master data setup that came about because of a bad decision or a fundamental change in your business since implementation. Remember, an upgrade does not allow this, because data is upgraded just as it is. However, an upgrade still gives you an opportunity to utilise new functionality all the time you're in project mode.
Upgrading for better functionality
shows in the amount of new functionality each new version brings. Obviously not all of it will be immediately relevant to your business, but having more visibility, more automation and more control can add real value. Here are my top 5 Dynamics 365 for Operations functions:
1. Mobile Workspaces- Dynamics 365 can be viewed directly on a mobile device via a browser, but the challenge with small devices is the amount of screen real estate available. So mobile workspaces use formats that are easy to view on a small screen, and provide simple triggers for particular actions. And you can create your own customised mobile workspaces over and above the out of the box ones. You simply create a new workspace title, click on the parts of the system in the browser you want to add, or click on an action. The system works out what needs to be done and creates the corresponding mobile workspace content. A very powerful tool.
2. Task recorder (on steroids) - Previous versions let users hit the record button and then carry out a process. The system then exported the screens, menu paths and steps into a Word document. But in Dynamics 365 for Operations, task recordings can be played back as a live demonstration, or even better, as a live assistance/training tool. New users can be guided step-by-step with business specific instructions. The system stops users going off track, and pushes them back to the prescribed steps.
3. Power BI - Reporting is the end result of all the processes and inputs going into any ERP, bringing meaning to every interaction with the system. You can't recognise the true value of everyone's hard work without reporting. Power BI is Microsoft's premier reporting platform and can take data from a variety of data sources - from Dynamics 365 itself, all the way down to Excel sheets. You can view data on your network or in the cloud, and see reports via your web browser or mobile app. Reports and tiles can even be embedded directly into Dynamics 365 or SharePoint with a few clicks of the mouse, no techie knowledge required. Microsoft has a bunch of very useful out-of-the-box content packages for Dynamics 365 to get you started, from warehouse performance, to cost management, to production performance.
3. Prospect to Cash integration - The common data model makes integration between Dynamics 365 for Operations and other solutions much simpler than with previous versions. And in addition, Microsoft have just released out-of-the-box integration in the July release, covering these key touchpoints:
- Maintaining accounts in Dynamics 365 for Sales and syncing them to Dynamics 365 for Operations as customers.
- Maintaining contacts in Dynamics 365 for Sales and syncing them to Dynamics 365 for Operations.
- Maintaining products in Dynamics 365 for Operations and syncing them to Dynamics 365 for Sales.
- Creating quotes in Dynamics 365 for Sales and syncing them to Dynamics 365 for Operations.
- Generating sales orders in Dynamics 365 for Sales for existing products and syncing them to Dynamics 365 for Operations.
- Generating invoices in Dynamics 365 for Operations and syncing them to Dynamics 365 for Sales.
4. Company copy - If you have more than one company inside Dynamics, especially if you've created at least one new one, you know this is no easy feat. But given the system knows which tables are defined as configuration vs transactional, why can't we have a copy company button? Well, you're in luck! Microsoft are finally releasing a mechanism to template a company's entire setup with an option to copy and create a whole new company. It's targeted to be released in the upcoming July update -" As new companies are needed, users will be able to save time and potential errors by copying an existing legal entity's setup to the new company. This will allow the onboarding of a new location to be quick and consistent with the company's golden template design."
Honestly, I could go on about the new functionality already released in Dynamics 365, or on the roadmap, for hours. But rather than simply reading about it, why not come and experience it for yourself? Fusion5 can give you a tailored demonstration to help you see the value Dynamics 365 can add to your business. We can also take you through our tailored 'Upgrade Assessment' process to start you on your journey by helping you choose the correct upgrade approach.
BOOK AN ASSESSMENT
Microsoft 365
Managing Solutions in Dynamics 365 Part-2
Source: https://www.fusion5.com.au/microsoft/blogs/upgrading-to-dynamics-365-for-operations-from-dynamics-ax/
0 Response to "Managing Solutions in Dynamics 365 Part-2"
Post a Comment