In most organizations, sending an email to teams is an activity that is performed daily. As an example, if a new lead comes into the CRM organization, the assigned team needs to be notified, so that they can follow up. Unfortunately, sending an email to a team isn’t a simple task in CRM. It comprises quite a lot of steps, involving coding. The reason is that CRM does not allow sending an email to a team through the CRM UI workflow. So, to achieve this functionality, we need to write a custom workflow and call it.
The other option is to use third-party DLLs which can serve the purpose. In our organization, we use Jason Lattimer’s solution. The link to the code base is advised below:
You can download the solution from the link mentioned above and import the solution into your organization.
It is a very useful DLL with other custom workflow activities which can be used also. We have been using Lattimer’s solution for sometime successfully, up until recently.
A couple of weeks ago we had some users complaining that they weren’t receiving the emails intended for the team. We did an investigation and found the following error in the workflow logs:
[LAT.WorkflowUtilities.Email (126.96.36.199): Email Team]
Unhandled Exception: Microsoft.Crm.CrmException: System.ServiceModel.Security.SecurityNegotiationException: Microsoft Dynamics CRM has experienced an error. Reference number for administrators or support: #A581A145
at Microsoft.Crm.Sandbox.SandboxCodeUnit.Execute(IExecutionContext context)
at Microsoft.Crm.Workflow.Services.ProxyCustomActivity.Execute(CodeActivityContext executionContext)
This error was something I had never encountered. Upon further research, I concluded that the issue was not related to the third-party DLL which we are using.
We have four environments – Dev, QA, UAT, and Prod. We found this issue happening only in UAT. If it was related to the DLL the issue should have appeared across all the environments. We contacted the network administration team to get their inputs on this issue since the error seemed to indicate that it was related to some security issues. The network team pulled some logs from UAT and did their research.
We are an on-premise organization running on the 8.2 Microsoft Dynamics CRM version. We restarted the CRM server and checked if that fixed the issue. That did not help. We looked at the different services running on the CRM Server and we found this:
We found that the sandbox processing service had stopped. That was interesting because the error seemed to indicate that it could be related to the sandbox service as well. We manually started the service and that fixed the issue.
The reason why it stopped initially was that the service account under which the SandBox service runs, had all the security permissions removed. We suspected that could be because of a user error.
So, to resolve this issue, the first thing to check would be if the account under which it is running has enough permissions in Active Directory. If that doesn’t change anything, then one needs to check if the SandBox service is running. If that doesn’t work either, then restarting the server would resolve the problem.
We harbor a fact-based approach in solution building. We listen, examine, and understand our client’s strategy and culture, to implement what is fit for the business. We believe in finding out innovative solutions for any challenges in the technical sphere. We look at a problem from different angles and try to implement various solutions. Our approach is always to find a resolution that saves time, cost, and resources and which can get the client’s business back on its feet quickly.