Portal users occasionally receive a generic error message that may leave them feeling frustrated and stuck. In today’s blog, we’ll explain why this happens, what’s been done to fix it, and what you can do when this happens to you…

The Problem

Occasionally, portal users report receiving the following error message:

In particular, this seems to occur when requesting a password reset or a confirmation email from the ADX Portal (or similar activities that result in an email being sent from the CRM server). There are several scenarios in which the portal may fail.

The Cause

Portal emails are sent by workflows and activities. When those fail, the exception is not bubbling up to the web application and the generic message is produced.

If the portal is on-premises, users may try going to http:// /trace.axd to see the details of the underlying exception. This may help fix the issue in some simple cases, but certainly not all.

Otherwise, the following checklist may help. In almost all cases, following the checklist will eliminate the problem.

The Solution: Checklist

While our list is extensive, it is not, of course, exhaustive. For example, we assume that the CRM is configured for the Server-Side Synchronization – in cases of Router use, more things could go wrong and they are not covered here. Also, the checklist assumes the email server behaves properly and the portal itself is properly set up.

So far, we have encountered and fixed the following reasons for email failure:

1. CRM User that is set in the workflow “From” is:

   1. Invalid or references the user with the same name but different GUID (just re-assign to the same)
   2. Deactivated
   3. Has no roles or no permission to send emails
   4. Did not accept invitation (flip invitation status on the _user_ record to “Accepted”)
   5. Mail is not allowed in Office 365 console (if user profiles are managed there)
   6. Mail is not approved for this user
   7. User setting to allow other users to send on behalf is not set (in XRMToolbox find User Settings applet, select this user, and flip this setting to “Yes”)
2. Mailbox for the user is not configured
3. Mailbox is not approved and tested
4. Workflow or activity that sends password reset is not activated or does not exist (although unlikely, we have seen this – which results in the need to re-import the ADX solution containing the workflow)
5. Portal Cache invalidation on Email entity is not enabled (on-premises only, you need to check if it is enabled using Plugin registration tool and confirming that the correspondent step exists)
   

Summary

As described herein, nearly all of the causes for the “We’re sorry, but something went wrong” error message have been identified and solutions are available. However, ADX Portal behavior may reveal bigger underlying problems in CRM, and receiving this error may signal a need to check all of the workflows and activities designed to send emails for business purposes. We always recommend regression testing the entire system after substantial configuration changes are applied. Doing so will keep your clients and business happily CRM’ing!

Let’s block ads! (Why?)

PowerObjects- Bringing Focus to Dynamics CRM