Do you have to many languages available in the system?
Then delete unwanted languages:
Then Flush cache: https:// XXXXXX.YYY.ZZZ.COM /?cmp=dat&mi=SysDataCacheParameters
And then the language lookup on customers/vendors etc is nicer:
PS! It does not work for languages on the usersettings.
Companies change, merge, sell, purchase each other, and we encounter requirements where it is a requirement to move to a new/other Azure AD tenant.
But…. That’s not a small thing. We requested through a Microsoft support ticket on how to do this, and hoping this was a small formality, and that Microsoft had some magic tricks of doing this. But they don’t. But I can explain the process we are on to achieve this.
In the process you will lose all documents that is record attached/stored in the old environment. There are also some other expected issues.
Do expect to spend some time on such a process. And it’s a good thing to perform the DB copy two times (first time just for validation and test). Microsoft is looking into how to improve this process, but this is how we are performing it.
If any in the community have better ideas, feel free to share it
BIG credits to my colleague HAKAM.
What we currently see is that more and more power user functionality is introduced step-by-step to make Dynamics 365 ready for the next natural technological step; to become a true SaaS solution built as a Azure service fabric. Check out this video from Microsoft for what I hope is the future and architecture direction for Dynamics 365. But before we get there, there have to be a natural transition of making Dynamics 365 more configurable and less dependent on creating your own customizations and extensions.
Now and then I try to keep an eye on the D365 roadmap for signs on this transition, and today I found these nice features that I think will be highly valuable. I have copied the descriptions from the roadmap, and the release date is not clear, but I look forward to present these great enhancements to my customers.
1. Power users can add custom fields to forms without developer customization
Many application customizations involve adding one or more fields to existing tables and including them in application forms. Most of your customizations may be comprised of adding fields.
Customizations are expensive because they require developer intervention for development, test, and code life cycle management. Customizations also need to be managed and migrated from one environment to another.
We are making it easier to add custom fields to forms in Dynamics 365 for Finance and Operations, Enterprise edition. No longer will developer customization be needed. Instead, a power user will be able to add a custom field to a table and then place that field on the form using personalization. An IT administrator will then be able to share the personalization with others in your organization.
2. Product lifecycle state
The product lifecycle state will be introduced for released products and product variants. You can define any number of product lifecycle states by assigning a state name and description. You can select one lifecycle state as the default state for new released products. Released product variants inherit the product lifecycle state from their released product masters. When changing the lifecycle state on a released product master, you can choose to update all existing variants that have the same original state.
To control and understand the situation of a specific product or product variant in its lifecycle, it is a best practice in Product lifecycle management solutions (PLM) to associate a lifecycle state with a variable state model to products. This capability will be added to the released product model. The main purpose of this extension is to provide a scalable solution that can exclude obsolete products and product variants, including configurations, from master planning and BOM-level calculation.
Impact on master planning – The product lifecycle state has only one control flag: Is active for planning. By default, this is set to Yes for all product lifecycle states. When the field is set to No, the associated released products or product variants are:
For performance reasons, it is highly recommended to associate all obsolete released products or product variants to a product lifecycle state that is deactivated for master planning, especially when you work with non-reusable product configuration variants.
Find obsolete released products and products variants – You can run an analysis to find and update obsolete released products or product variants.
If you run the analysis in a simulation mode, the released products and product variants that are identified as obsolete will be displayed on a specific page for you to view. The analysis searches for transactions and specific master data to find the released products or product variants that have no demand within a specific period. New released products that are created within the specific period can be excluded from the analysis.
When the analysis simulation returns the expected result, you can run the analysis by assigning a new product lifecycle state to all the products that are identified as obsolete.
Default value during migration, import, and export
When migrating from previous releases, the lifecycle state for all released products and product variants will be blank.
When importing released products through a data entity, the default lifecycle state will be applied.
When importing released product variants through a data entity, the product lifecycle state of the released product master will be applied.
Note, the ability to set individual product lifecycle states using the data entities for released products or product variants is not supported.
3. Users can pin PowerApps to forms and share with peers to augment functionality
Have you built a PowerApp that uses or shows data from Dynamics 365 for Finance and Operations, Enterprise edition? Or have you been using a PowerApp built by someone in your organization? Would you like to use PowerApps to build last-mile applications that augment the functionality of Finance and Operations?
Your users can build PowerApps without having to be expert developers to extend ERP functionality. PowerApps developed by yourself, your organization, or the broader ecosystem can now be used to augment ERP functionality by including them within the Finance and Operations client.
Your users will be able to pin PowerApps to pages in Finance and Operations. After they’ve been added, these changes can be shared with peers in your organization as personalizations.
Disclaimer: The opinions and views expressed in this blog are those of the author and do not necessarily state or reflect those of Microsoft, my employer EG or other parties.
In Dynamics 365 we are using number sequences to automatically create identifiers like product number, customer number etc. I’m a fan of having these numbers as “clean” as possible, and I always try to convince my customers use pure numbers. Why ? Take a look at the keyboard:
The numb-pad is the fastest way of typing in data. I also see that users normally perform lookup and see the description of what they are selecting anyway.
But let take a scenario; We will use a number sequence to create products numbers. We will then typical get product numbers like this :
Then I have often seen that another problem arises; typing errors from the num-pad are actually getting a “hit”, because when using a number sequence we can almost always find a product that have the same number as the user wrongly typed.
If you try using your credit card online you will see that the number is not accepted if any number is wrong. The solution there is to build in check-digits in the number.
I created a very small extension to solve this in Dynamics 365, with just a few lines of code. In the following example The “green” part is from the number sequence, and the yellow part is from the modulo 10 check digit calculation.
In this way the user can never type the wrong product(or any other identifier), unless it is 100% correct.
In the screen for number sequences I added an option to add the check digit to my generated numbers.
I wanted to share this with you, because it is so simple:
1. Create an extension on the table “NumberSequencetable”. Then add the extended datatype (YesNo) as a field, and name it “AddCheckDigit”.
2. Add this field to the “Setup field group”
Then we have the parameter in place, and it is available on the number sequence as shown earlier.
3. Then create a new class and replace all code with the following :
Here I’m creating an extension to the NumberSeq class, and I’m creating one method; Num, that will add the modulo10 number to my number sequence.
Where I check if my new “AddCheckDigit” is enabled, and I’m also saying that do not do this for continuos number sequences, manual, and I also say that the number sequence must be allowed to be changed to a higher number.
Now you can have check-digits on products, customers, vendors, sales orders, purchase orders etc.
PS! I have not tested this code 100%, but the community is full of brainpower that hopefully can share additional findings on bugs or flaws.
If you like this, vote at idea sat https://ideas.dynamics.com/ideas/dynamics-operations/ID0002954
Have you ever seen the TV-series “House of Lies“. This is a quite funny TV comedy series that focuses on the extrovert lifestyle of a management consulting team. First of all it is a comedy and not very realistic, but it manages to illustrate the concept of how to create the most efficient organization form for solving problems; The Agile POD.
Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output. This blogpost is about how to organize a consulting business that is non-silo organized around an actual service product.
In many consulting companies today, we see increasingly alarming signs that prevents the full utilization of the people and resources. Some of the signs can be seen as:
– Many non-direct-operative managers. (If you have >5 levels from bottom to top you have an issue)
– To many internal meetings. (Why Meetings Kill Productivity)
– To much time are used to generate budgets, forecasts and excel spreadsheets. (No actual customer value)
– Organized into silo-team with similar expertise. (Functional, Technical, Support etc)
– New project teams for each project. (Spends 2 months of getting to know your team members)
– Outdated internal systems and processes.
– Mixed marketing message and costly (pre) sales and implementation processes
– Many partners is currently not ready for the Dynamics 365 cloud based disruption (Sticks to waterfall, while agile accelerate)
Agile POD’s is a different way of organizing a team for efficiency. How does a agile POD look like? In this example we have a small 5 person permanent team. This team is specialized for running a some tasks/phases in the initial Dynamics 365 implementation; The Agile preparation phase.
In this example the POD owner is the Solution Architect. The roles in the POD can be described as:
The solution architect:
He runs the POD, and he also have all the responsibility of the POD. It is the POD owner that recruit the POD-members. The Solution Architect is the “face” of the POD, and will organize the work in the POD and also discuss the solutions with the key decision takers at the customer. Very often the solution architect have lot’s experience. In agile terms this is also the SCRUM-master and also very operational.
The Finance expert:
When implementing Dynamics 365, there is an always a need to know how to connect the operational processes into accounting and reporting. This person is highly knowledgeable in Financial Management reporting, Power BI, Excel. He also knows how to improve the reporting from the financial perspective by defining financial dimensions, setting up Tax, Bank, Fixed Assets, HR and Budgeting/Forecasting.
The Vertical Domain Expert:
How to implement best-of-breed processes is the vertical domain experts expertise. In Retail-domains this means expert on Master data, Categorization, Stores, POS, Devices etc.
The Technical Architect:
In a cloud based system, there is a need to understand how environments are deployed, setup and make it all ready for an efficient Application Lifecycle Management. The Architect knows the ITIL-framework. When a change is needed the technical architect will create the necessary documentation/VSTS backlogs for developers to execute on.
The Junior consultant:
The junior consultant is here to learn, offload and support the team. As experience increases the junior will eventually more responsibility and hopefully some day move into other positions in the team.
Within the team we are looking to T-shaped person, that have a width to their expertise, and also a few deep expert knowledge domains. A gaming company called Valve(That delivers the Steam gaming store) described what we are looking for with the following picture of the T-shaped model. Take a look at their employee handbook. This same concept and idea is relevant for Dynamics 365 consulting companies.
The Agile POD’s must therefore specialize their own services. Each POD-team must therefore build WBS (Work-Breakdown-Structures) that enables the delivery to combinedly utilizes the entire POD.
The idea is that a POD-team is sent out to the field, then delivers the pre-defined services, and returns safely afterwards. Then it is off to the next client to again deliver the same service. As you may understand, it is therefore important that the services delivered is predefined. In this concept there is not one team that delivers a complete implementation. In larger implementations it would be a sequence of Agile POD’s that cover the implementation.
This way of organizing is not a new way of doing things. This working concept have been applied for decades at entrepreneurs and building companies. When building a house this is not done with a single team. It is done by a sequence of teams that is specialized. A POD team will have responsibility of a limited set of tasks, that needs to be performed in a predefined sequence.
By organizing operational skills into POD’s executed in a sequence, we now have a balanced unit. One pain in Dynamics 365 consulting companies I often see is that bottlenecks arises around a few selected roles. Typical on the solution architects. This unbalance will result on high utilization on these roles, with other roles have low utilization, because work is not correctly distributed. We also see that consultants are being placed into project teams because they have free time, and not because they have the right knowledge. This increases costs and reduces satisfaction for customers. Ultimately it also reduces profitability for the implementation partner.
Agile POD’s does not solve every thing, but it makes the center core operational services lean and efficient. Any consulting company still needs sales, project management and customer support as separate functions.
As seen in the figure above the each vertical focus area will have a management functions, that focuses on building Agile POD’s. The idea is not to hire single consultants but to create new POD’s. The POD itself must define the services that the POD can deliver. The role of a vertical department management is therefore to how on recruiting new POD’s. As Valve explains it, the hiring becomes the most important thing in the universe.
A model for money and revenue must also be established. All departments must be self-financing and make sure that they are balanced according to how the revenue stream is defined. One element that is common in the consulting business is bonuses. I personally don’t like the idea of bonuses but I see that it is very difficult without it.(Necessary evil) In the model below is a an example on how different departments can be revarded.
Marketing and Sales: The concept of cloud based systems it that the customer don’t need to purchase all the software upfront. They rent/hire the software in the cloud, and only pays a monthly fee. The Marketing and Sales divisions must therefore be financed by the monthly license revenue, and the bonus would be accumulating. The purpose is therefore to make sure new customers are onboarding and that existing customers hare happy with the services. As a new seller in this way of organizing it, there will not be much bonus in the start, as you have few customers onboarded. But as more customers get’s on board, the bonus will be accumulating, and after 2-3 years there will be a decent bonus and a decent ground for investing more in marketing.
Project and Management consulting: As described earlier, these roles are the only more “permanent” roles that exists in the project. They will ask Agile POD’s to come inn and solve specific tasks. Their services are based on T&M(Time and Material), and their bonus will be based on the revenue(not margin) on the project.
The Agile POD’s: These services are charged in a combination of T&M and Predefined Product Services. The Predefined Product Services is the key here. Create WBS-structures where the price and delivery is clearly defined. The bonus here is a team bonus. Internally in the team it is distributed according to a key. But the POD-team can also choose to use the bonus for other purposes also like training or conferences. Remember that an agile POD is a self-contained unit with costs, revenues and margins. If the POD is not profitable it will be dissolved and the team unattached/fired.
Platform Services: This department is making sure all services/software around the Dynamics 365 is working as expected. This means making sure the azure/tendents are set up correctly, that Office is working and that services like CDS(Common Data Services) and PowerApps are setup as expected. All their services should be Predefined Product Services. And the bonus would be based on margin. Why ? Because we want to become better and better delivering these predefined services. The faster this is delivered the more margin is generated. This is a Win-Win situation for both the customer and for the consulting company.
Customer support/After Sales: Customer support and aftersales is all about delivering excellent customer service after the project have gone live. It’s revenue should be based on support agreements and add-ons. The bonus for the department is based on accumulated revenue, because these services should be reoccurring services that the customer pays for each month. If the customer is happy about the services provided then they will continue to use this service. The alternative for the customer is to use Microsoft Premier Support that can be quite costly and not that relevant in most cases.
At the end of this blogpost I would like to visualize how we envision the Agile POD’s, where we have training on our services and delivering excellent customer services on time and on budget.
And if we don’t, then this is the consequence:
Additional details on Agile POD’s can be found here:
Video : https://www.youtube.com/watch?v=IwJKRaocdxI