Choose your path Increase your proficiency with the Dynamics 365 applications that you already use and learn more about the apps that interest you. Up your game with a learning path tailored to today's Dynamics 365 masterminds and designed to prepare you for industry-recognized Microsoft certifications.
Visit Microsoft Learn
2020 release wave 1 Discover the latest updates and new features to Dynamics 365 planned through September 2020
Release overview guides and videos Release Plan | Preview 2020 Release Wave 1 Timeline
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Upcoming TechTalks
For small changes like new workflow creation, adding one field, etc what would be the best way suggested.
Make a solution for each (small thing) within the production and publish.
As small changes can be made at - production customization area
but how we can mitigate risk that (once we hit publish / publish all) then any unsaved changes not to be published / affect environment ?
will making a solution in Dev/ sandbox, export as managed and deploy at prod can ever affect existing configs of particular entity?
There is a lead object with 50 custom fields, 5 scripts, ....
One custom field need to be added and one workflow.
As far as I have seen, you can make such changes on a Dev/Sandbox instance and create a solution with just the subcomponents that are modified to that solution. Later, you can export it as a managed or unmanaged solution and import to Production org. Further down the line, you can use version control and build pipeline features (Azure Dev Ops) to automate this.
Here's a link for Azure DevOps:
It is highly recommend to add your new functionalities on a dev environment (Adding workflows, creating fields, views, forms...) because making customizations on production might directly affect your prod data, especially if your customizations didn't went as expected.
Thus, it is always to follow the best practice to add your changes in a solution on the dev, test your changes on the testing instance and finally import them into the prod instance.
You can create new solution and add only the customizations done and as per Palani mentioned, you can work with solution versioning.
Hope this helps!
If found useful, please mark it as verified in order to help other community members.
Charles Abi Khirs.
The best practice is to create a minimal solution in your Dev instance containing only the components you have updated. Then export the solution and import it into your Test, UAT, and Production instances.
The recommendation is to create a solution in Dev environment and add the required components in the solution. Export the solution from Dev and import into any of the testing environment, if you have any, otherwise test the functionality change is on Dev environment. Once you tested properly then deploy the solution on Prod.
This will ensure that all the environments have the same customization and configuration.
Business Applications communities