We plan on having all of our Help Desk email sent to our email listener address. When an address is not recognized as a user or external contact in the system, how will that email be handled? When the software processes an email it moves it to the archive folder and marks it as read. We want to make sure nothing is missed or buried in an archive folder. Interested in hearing how other organizations handle these emails.
These settings are defined within the Admin UI: Configure > Email Configuration > Mailbox > Inbox
For reasons unknown to me, we are currently using the selected option above. Personally I would prefer to use the top '...by creating or linking...' choice. This would ensure any unrecognised senders are created on the system which is better suited to our organisation.
As for how the email itself is processed, the following documentation should provide suitable insight:
Unless the middle '...only when - exists' option is selected, I wouldn't expect any issues with missing emails. If there were any problems with record creation (Incident, Problem etc.), an email record should be created and failing that, there should be log entries which detail why this is not the case. I think the key thing would be to keep an eye on issues, at the moment we have added log checks to our morning 'Pre-flight' routine as we previously had issues with emails which was due our outgoing Email configuration.
Hi DTurner, thank you for your suggestion.
I changed the settings and sent a test from my gmail account. We still get an error.
Failed to create Incident record Error: System.ServiceModel.FaultException: Unhandled system exception: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> DataLayer.DataObjectFieldValidationException: Incident((newsrvE34907EE33AF4CDE87F074CF520DD7F3)): 'West Coast' is not in the validation list of validated field Incident.CustomerLocation.
Server stack trace:
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object ins, Object outs, TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)
Exception rethrown at :
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at com.frontrange.saas.ws.data.IPCMServiceSoap.CreateObject(String sessionKey, String tenantId, ObjectCommandData commandData)
at com.frontrange.Services.IPCMServiceClientImpl.<>c__DisplayClass5_0.b__0(String s)
at com.frontrange.Services.ClientServiceBase.ExecuteWithRetryOnInvalidSession[T](Func`2 function, String sessionKey, String tenantId)
at com.frontrange.Services.IPCMServiceClientImpl.CreateObject(String sessionKey, String tenantId, ObjectCommandData commandData)
at com.frontrange.saas.EmailService.DataAccessLayer.Incident.Insert(String description)
at com.frontrange.saas.EmailService.SaaS.CreateIncident(IncidentCreationContext context, String description, String& incidentId)
1 of 1 people found this helpful
The reason for the error is that the ticket is being logged under that method to a user called Internal Services. Look them up in the Employee workspace, then change their Department, Location etc. to values that match your system. The values there are system defaults from the installation.
Do not change the Team of the Internal Services account as that can cause problems with Discovery if you are using it. Also do not change the roles of that account it is the super account that all workflows and escalation etc. run under.
The exception highlights an issue with the location field:
Incident((newsrvE34907EE33AF4CDE87F074CF520DD7F3)): 'West Coast' is not in the validation list of validated field Incident.CustomerLocation.
If you are using the 'Create record without creating...' method then this is likely an issue with the InternalServices employee as Alasdair mentioned.
This potentially could be an issue with initialisation rules on the Employee object but I would defer to Alasdair as I believe the InternalServices location is set to 'West Coast' by default so I would guess this record, or the validation list, has been changed.
Thank you for your reply! I added the location West Coast to the Location list and this resolved the issue. Thank you for your help!
You can use one of your locations, you do not need to add a default one in if it is not needed.