Our Sharepoint/D365 Sales integration worked great, until one day it didn’t.
When trying to access a document folder, and also when trying to run the “Enable Server-Based SharePoint integration wizard, “we got the following error: “The remote server returned a 401 unauthorized error.”
This was odd, because Sharepoint had previously been configured successfully, and the user had been able to store documents under the entity for many months prior. The solution turned out to be entering the user’s email address on the System User form.
By default, the SharePoint Email Address field is not exposed on the System User main form. You will have to customize the form to expose the field, and then you can populate it.
Once you have customized the form, go to Settings -> Security -> Users. Open the user record, and enter the email address with which the user is logging into Dynamics 365 in the SharePoint Email Address field . Usually, but not always, this is the same address as in the Primary Email field. Save the user record.
Then test access to the Documents folder again. The change should take effect immediately, and you will be back in business.
Recently, we encountered an error in Dynamics 365 Project Service Automation. Whenever the Bookable Resource form was loaded, an undefined error popped up saying there was an error with “this field’s customized event.” However, there was no information on which field the error referenced.
After some investigation, the error was finally traced by Microsoft support to the Legacy Form Rendering setting. Once Legacy Form Rendering was turned off, the error disappeared.
To change this setting, go to Settings -> Administration -> System Settings. On the General Tab, if “Use Legacy Form Rendering” is set to Yes, set it to No.
Migrating Dynamics 365 Sales to a new tenant must be done by Microsoft Support. The first step is to open a support ticket through the Office 365 portal to request the migration. (UPDATE: Microsoft does not yet support tenant-to-tenant migrations for version 9.0 organizations. This is expected to be available in Q2 2019.)
Once they have confirmed the specific information about the source and target tenants, MS Support will ask you to request a date and time for the migration. The date must be at least two days in advance. They will then schedule the specific date and time of the migration.
Microsoft support will need some information from you to validate and perform the migration. At a minimum, be prepared to supply the following. You can save a step by including it in the initial support request:
- Are the Source tenant and Destination tenant in different Regions (NA, APAC, EMEA)? If so, then indicate the region of both the source and target tenants.
- Is Voice of the Customer installed in either organization?
- For each organization, what is the:
- Unique organization name
- Organization ID
The URL is the same one you use to log in, typically <YourOrg>.crm. dynamics.com. You can find the Organization Name and ID by going to Settings -> Customizations -> Developer Resources -> Instant Reference Information.
Relevance search uses Azure to index your CRM data. This means that you are exposing the data to a service external to your CRM instance, so you need to take that into account before you enable Relevance Search. You may have entities and fields that you do NOT want to expose this way because they contain confidential information.
More information can be found in this TechNet article, which says:
“We strongly recommend that you configure the entities and entity fields participating in Relevance Search before you enable the search, to prevent sensitive data from being indexed in a service external to Microsoft Dynamics 365 (online). “
On a global basis, Relevance Search is enabled in System Settings. The user selects it in Personal Options -> General -> Search Experience.
We recently ran into an issue restoring the a production CRM instance to the corresponding sandbox instance. Although the field security profiles appeared to be copied correctly, the secured fields were not accessible, even with the System Administrator security role.
The workaround is to:
- Toggle field security off on the field and save it.
- Toggle field security back on and save it.
Do this for each secured field. Then rebuild the Field Security profiles.