Skip to main content
Skip table of contents

Deploying Email-to-Service-Request

When you deploy the Email-to-Service-Request feature, NexJ CRM automatically creates service requests based on incoming emails from your clients to your support team's mailbox, and notifies your clients that the service requests have been created. This automated process enables users to address client issues more efficiently and quickly.

To enable the Email-to-Service-Request feature, you must enable the Email to Serv. Req. system setting at design time. For example, use the ServiceRequest'enableEmailToServiceRequest event to enable the feature.

During deployment, you must set the emailToServiceRequest attribute in the environment file to "true." For more information, see Example environment settings for NexJ CRM deployment.

To deploy Email-to-Service-Request, you must enable a default mailbox (Mail channel connection) in the environment file that will be monitored for Email-to-Service-Request.

The Mail channel connection uses the EmailToServiceRequest service to monitor the service request mailboxes. A new system user (specified in the ServiceRequest class using the EM2SR_SYSTEM_USER* static attributes is used to initially run the service. The service uses the mailbox that received the email to determine which user (for example, the owner of the mailbox) the email was intended for. Next, the remainder of the service is run as that user (for audit and security purposes). Then the email address of the sender is matched against entities in the system to determine which entity the service request would be for, and the email is parsed to determine whether there is a discernible service request identifier. If an existing service request and entity are found, the email is logged against the existing service request, otherwise a new service request is created, and the email is logged against the new service request.

To configure the Mail channel connection:

  1. In NexJ Studio, open the environment file that you want to edit and click the Channel Connections tab.
  2. In the Channel Connections area, click the Select button
    The Select Channel Connections dialog opens.
  3. In the left-hand column, select Mail from the list, then click Add.
    The selected connection is added to the right-hand column.
  4. Click OK to close the Select Channel Connections dialog.
  5. In the Email Account field, enter the email address to which incoming mail is directed. This email address should be for the support team that will receive the emails. For example, enter <>.
  6. If the mail server requires you to authenticate, enter the authentication password in the Password field.
  7. Under the Receiver Properties heading, and in the Folder field, enter a folder name. For example, enter INBOX.
  8. In the Protocol field, enter pop3 as the protocol used for incoming mail.
  9. In the Host field, enter the host name for the incoming mail server. For example, enter <Exchange-Host.DOMAIN.EXT>.
  10. Under the Sender Properties heading, in the Sender E-mail field enter the default email address that outgoing mail is sent from. For example, enter <>.
  11. In the Protocol field, enter smtp as the protocol used for outgoing mail.
  12. In the Host field, enter the host name for the outgoing mail server. For example, enter <Exchange-Host.DOMAIN.EXT>.
  13. Click the Save button 
    in the toolbar to save the changes to the environment.

These changes are reflected in the environment file XML as follows:


<Environment ...>
      <MailConnection channel="Mail" from="" inFolder=
"INBOX" inHost="Exchange-Host.DOMAIN.EXT" inProtocol="pop3"
outHost= "Exchange-Host.DOMAIN.EXT" outProtocol="smtp" password="text:password"

You can set your own specific user in your environment file to process EmailToServiceRequest messages. If you do not, the EmailToServiceRequest service will use the “em2sr” user that is supplied by the Sample Data Seeder to parse the email and create the email log items. For either case, the user that you use to configure the channel connection should have “admin” access to read all contacts data.

Application administrators can configure additional mailboxes to be monitored in the Service Request Management tab on the Customize workspace. For more information, see "Service requests" in the application administration documentation.

Each mailbox must be associated with a user group for security purposes, as each service request that is created will be secured to this group, and an owner, who is automatically assigned service requests arriving from the mailbox. The default mailbox is not persisted in the database and is not editable at run time (except for name and owner) but additional mailboxes are editable at run time. For more information, see "Service requests" in the application administration documentation.

The default mailbox is initially seeded without an owner and deactivated, which means that you must set the owner of the default mailbox and activate it. Unless the default mailbox is active, the service will do nothing, even if additional active mailboxes have been configured.

You can individually enable or disable user groups for Email-to-Service-Request at run time. When Email-to-Service-Request is enabled, a default support user group is seeded with the name specified by the static ServiceRequest'DEFAULT_MAILBOX_NAME attribute. For more information, see Configuring user groups.

Application administrators can also configure email processing restrictions (maximum attachment size and blacklisted email addresses) in the Service Request Management tab on the Customize workspace. For more information, see "Service requests" in the application administration documentation.
JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.