While planing for the data migration item for one of my project, found this great article by Bruce Buxton which explains top 10 data migration traps. It was good to know as prevention is always better than cure 🙂
[Referencing The Microsoft Dynamics CRM Blog]
The Dynamics CRM to SharePoint integration has always been a key solution to document management within CRM. With two currently available solutions, the List Component and new server-based SharePoint integration, CRM is pleased to focus our efforts on the server-based integration. Dynamics CRM 2015 Update 1 will deprecate the List Component as a result of SharePoint’s deprecation of the sandbox solution, a dependency of the List Component.
Customers with List Component are advised to upgrade to the server-based SharePoint integration. With CRM 2015 Update 1, server-based integration gains hybrid support between CRM Online and SharePoint On-Prem. In a subsequent release, CRM will support CRM On-Prem to SharePoint Online and CRM On-Prem to SharePoint On-Prem. SharePoint Online or SharePoint Server 2013 SP1 and above is required for server-based integration.
Recently I found that many people have issues importing old Invoices either from legacy system into Dynamics CRM. This is manly in scenarios where Products are not maintained in CRM. In this case import of Invoice Line throws error as the data import template for Invoice line do not have relationship with Invoice. Below are the steps that can be followed to fix the issue.
Invoice lines is a relationship between invoice and products. Thus if you need to add invoice lines, you need to add products using the “Product.xml” template file. But in our case as we don’t maintain Products in CRM, while importing Invoice lines, add invoice number of imported invoices in CRM in a separate column and select the Product as write-in in import file.
For importing Invoice lines, you need to download the “Invoice Product.xml” template file.
All the mentioned templates can be downloaded from “templates for Data Import” in Data Management section in Settings.
- Export Invoice Product.xml
Add Invoice Line data in the xml with below values.
- Set “Select Product” column value to “Write In”.
- Add a new column “Invoice ID” and set the value to Invoice ID field of respective Invoice.
- Save and import the file.
4. Import the above xml file.
5. During Import wizard, on Review Mapping Summary Page, click on Edit.
6. In Map Fields, for Invoice ID row click on the look up reference and select “Invoice ID” field and click Ok.
7. Click Next and progress with the import process.
Probably issue with many users follow is at step 7. Invoice ID field is by default map to Invoice name and Invoice GUID field.
Hope this helps!
Yammer gives colleagues at your organization a central place to have conversations, create and edit documents, and share information without sending a single email or attending any meetings.
After you set up your organization to work with Yammer, employees will see posts in a newsfeed on their Microsoft Dynamics CRM dashboard whenever people update customer info, and they’ll be able to join in the conversation with their own posts.
If you are connecting a Microsoft Dynamics CRM (on-premises) deployment to Yammer that is not using Internet-facing deployment (IFD), you need to run the following PowerShell commands to disable secure channel HTTPS.
You shouldn’t run these commands if you are deploying Microsoft Dynamics CRM (on-premises) with IFD.
- Open a Windows PowerShell command window.
Add the Microsoft Dynamics CRM PowerShell snap-in:
Enter the following:
$itemSetting = new-object ‘System.Collections.Generic.KeyValuePair[String,Object]'(“AllowCredentialsEntryViaInsecureChannels”,1)
$configEntity = New-Object “Microsoft.Xrm.Sdk.Deployment.ConfigurationEntity”
$configEntity.Attributes = New-Object “Microsoft.Xrm.Sdk.Deployment.AttributeCollection”
Set-CrmAdvancedSetting -Entity $configEntity
- Then, run the following command at a command prompt: iisreset
More details steps can be found here.
New system setting is introduced Sales territory change in CRM 2015 to set default price list in opportunity. If this setting is set to No following territory configuration won’t work. This setting comes in picture while setting Territory based default price list.
For this, create a territory (e.g. USA) -> add Manager. Multiple members can be added by clicking Members in Common section in left navigation -> Add members.
Once territory is created, create price list –> add price list items -> in territory relationship grid add territories (e.g. USA) for which current price list should be default.
Save changes and now as per our configuration, for territory manager and members inside territory, Shirts Price list becomes default i.e. pre-populated while creating new opportunity. Price list can be changed if required.
Another approach to set default pricelist for opportunity is to create a simple business rule on opportunity form which sets value of field Pricelist. Once business rule is activated, for every new opportunity default price list is set.
Note: Business rule overrides Sales Territory settings. System setting shown above does not affect business rule.
Please refer below link for more information
***[Referencing to Microsoft Dynamics CRM Team Blog]
|In Microsoft Dynamics CRM Online 2015 Update 1 (v7.1), a new form renderer was built to provide better performance. Forms will load significantly faster and more efficiently. The new renderer is based on previous generations and has the same functionality and behavior. However there are some things that admins and developers need to do to ensure full compatibility when upgrading.
What will users notice?
End users will not notice anything different, other than forms loading faster. The new form rendering engine has full support for client scripting (Write code for Microsoft Dynamics CRM forms), uses the same XML definition (Form XML schema), and has the same behaviors all around. There have been no fundamental changes made in terms of what the form does.
In order to help catch unsupported customizations, we added a dialog that displays the issue when script errors occur so that they do not fail silently. If these symptoms occur then it is likely there are unsupported customizations in the system.
All the changes have been focused on how the form load process can be optimized. There are 2 main changes that have been made: loading process of the form, and handling of cache.
In terms of loading process, we have parallelized as many operations as possible to eliminate time wasted because the browser is idle. We increased the content that’s cached, moved rendering processes partially to server-side, and optimized the initialization of controls.
Form load used to be a very linear process. Since the new form renderer is more parallelized, the rendering engine now constructs the form and XRM model first and binds the data whenever the server responds. The diagram below is a rough approximation in order to illustrate the differences between the 2 rendering engines and may not reflect the exact changes.
Forms also used to waste a lot of resources. Since they were hosted in iframes, the iframe would be discarded and reloaded on each form load. The new form renderer does not discard iframes and instead keeps the iframe around. All common scripts are already parsed and never need to be loaded again. This introduced the design to load custom scripts and ISV scripts in a separate iframe which is the one that’s discarded when the form closes. Previously, these scripts would be loaded in the same iframe as the form.
What do I need to do?
As an admin or developer there are some things to be aware of. Because the new form rendering engine makes changes to how iframes are organized, any attempt to access unsupported APIs or use direct DOM manipulations may fail and need to be fixed.
Customers should all make sure to test their organization in sandbox mode to preview before upgrade. This way, should any symptoms show up around forms not loading/script errors, you will be able to catch and fix it
Examples of things that will break:
In order to help identify potential issues, the CRM 2015 custom code validator can be used. It’s primary purpose is to identify usage of deprecated APIs but it will also attempt to flag usage of unsupported APIs. The tool can be found here: https://www.microsoft.com/en-us/download/details.aspx?id=45535. Developers should also review their scripts to ensure only supported APIs are being used.
Customers that have 3rd party solutions should reach out to their partners for updated solutions that have been verified to work with the new form rendering engine. While most are expected to continue to work, those with unsupported customizations need to be updated.
In case there is difficulty identifying the issue or a backup plan is needed post-upgrade, we have introduced an organizational-level fallback to temporarily allow usage of the legacy rendering engine. This will ensure compatibility at the cost of performance. Do not rely on this solution long term as the plan is to remove this option in the following release.
This setting can be found under Settings -> Administration -> System Settings -> General. Select “Yes” under “Use legacy form rendering” to enable this mode for all users.
If script errors are showing up, or if forms are not behaving as intended, this setting can be used to diagnose if the problem is specific to the new form rendering or not. If it is due to the new form rendering engine, then most likely there are some unsupported customizations.
If you are the owner of the scripts, make sure that there are no unsupported customizations. Otherwise reach out to the provider of the solutions for an updated solution.
In the world of Microsoft Dynamics CRM, the shift to the cloud is well underway. Microsoft Dynamics CRM Online is growing by leaps and bounds, including sales to massive customers with huge user counts.
You may believe that the difference between building a solution for an on-premises and an online deployment consists of a few technical details, like the requirement to use FetchXML for reports in online deployments, or the requirement to sandbox plugins. But in reality, the differences are much deeper than that. To truly build a high-quality solution for Microsoft Dynamics CRM Online, you need to do more than simply build the on-premises way and then check a few extra boxes.
The Microsoft Dynamics CRM Online patterns & principles for solution builders whitepaper describes the new mindset required to successfully design solutions for online deployment. Check it out at the following location!
View the original article here.
If you’ve used Product Kits in the past, you’ll be familiar with Product Bundles. Bundles are an enhanced version of Product Kits (e.g., you cannot view Kit Items when selling a Kit, but you can with a Bundle – see the Opportunity screenshot below). Product Kits will not be going away with CRM 2015, but instead Bundles will be an additional option users can use along with Kits.
Product bundles provide a superior way to group common products together to be sold with more attractive package pricing (using price lists). Bundles are similar to kits (which still exist and have not changed) but are greatly enhanced. For example, unlike kits, bundled products are visible to the salesperson on the opportunity, quote, order or invoices as they are entering line items. Additionally, the quantities and properties of the bundled products can be edited on the line items.
The following table highlights the key differences between Kits and Bundles.
|All the products in a kit are mandatory.||Some products in a bundle can be optional.|
|Kits support nesting; you can add a kit to another kit.||You can’t add a bundle to another bundle. You can only add products to a bundle.|
|While adding a kit to an opportunity, quote, order, or invoice, you can only see the kit level details; you can’t see individual products in the kit.||While adding a bundle to opportunity, quote, order, or invoice, you can see the bundle level details as well as individual products in the bundle.|