Configure SmartPost for receiving messages

A service workflow named e-Boks Message Handler handles the receiving of messages from e-Boks. The service workflow contacts e-Boks at regular intervals and checks for unread messages. In case of unread messages, a receipt workflow starts. When this workflow has been completed, the message is marked as read.

When SmartPost receives a message from e-Boks, SmartPost checks if the message is a reply to a message that was sent from SmartPost. If the message is not a reply but an unsolicited messages, the message is saved as a document with possible supplementary documents on a default case. If the unsolicited message is sent to a subunit in your organization, it is saved on a specific case, which is mapped to the subunit (the unit's dossier). See Handle e-Boks messages sent to subunits.

If the message is a reply, the message is saved as a document with possible supplementary documents on the case that the original SmartPost message was sent from. The case must be open. If the case is closed, the letter is saved as a document on the default case.

You can configure SmartPost for receiving messages in WorkZone Configurator.

See also Receive messages from SmartPost in the WorkZone Process User Guide.

Configure SmartPost settings for receiving messages

  1. Open WorkZone Configurator, and click Process > Process dispatchers.

  2. Point to next to the e-Boks dispatcher you use, and click Edit dispatcher parameters.

  3. Specify the following parameters:

  • ReceiverSystemID
  • CertificateThumbprint

See Configure dispatchers.


Configure an e-Boks Message Handler service workflow

You set up the e-Boks Message Handler service workflow in WorkZone Configurator.

  1. In WorkZone Configurator, click Process.
  2. Click Service workflows.
  3. Add a new service workflow of the type e-Boks message handler, and enter a name and description, and then click Create.
  4. Point to the e-Boks message handler service workflow that you just created, and click Edit parameters, and fill in the parameters. For descriptions and examples, refer to the table below.
Name Description Value

DispatcherName

The dispatch type listed in the Dispatch Type list in the Process Dispatchers. It is used when retrieving unread messages.

  

WatchInterval

Interval in seconds between SmartPost checking e-Boks for receipt of new messages.

300

RetryCount

The number of retries before messages are abandoned.

5

DefaultCaseNo

The case number a predefined case (a dossier) on which incoming messages that cannot be saved on a specific case will be saved. The case must always be open.

  

EBoksInboundMessagePartyRole

The role of the party on the received e-Boks message. If the setting is not specified, the Sender role (Afsender) will be used.

Sender

IncomingDocumentType

The document type that will be assigned to the e-Boks message when it is saved on a case.

For example, I (Incoming). The setting must match the settings for the custom domain AT.

I

DPIncomingSource

Origin of the incoming messages and their attachments as retrieved from e-Boks.

For example, DP (Digital Post). The setting must match the settings for the custom domain AKTOPR.

DP

UseEBoksMailMap

If turned on, unsolicited messages sent from e-Boks to subunits in your organization will be saved on specific cases that are defined for each of the subunits. You specify the cases when you map e-Boks mailboxes for subunits to cases in Configuration Management.

Note: If the mapping of e-Boks mailboxes and subdivisions does not work, the received messages will be saved on the default case that you have specified in the DefaultCaseNo parameter.

 

ValidationHour

The time of the day when the validation of the contact hierarchy is scheduled. By default, it is 01:00 in the morning. e-Boks only allows access to the contact hierarchy once a day between midnight and 06:00. Enter time in the format 1 (01:00), 2 (02:00), and so on.

See Configure validation of a contact hierarchy.

1

ValidateAtStartup

Starts the validation of the contact hierarchy when the service workflow is started. Use this parameter primarily for testing purposes. In production, this parameter has no effect. In production, the validation will only happen when the time specified in the ValidationHour parameter is met. By default, this parameter is turned off.

 

OpenClosedCase

If turned on, a closed case is reopened if a message is received. The case will remain open.