!--a11y-->
Subscription Service 
The
subscription service enables users to keep track of changes to documents and
folders. It informs users about changes to subscribed resources by sending
notification e-mails at defined intervals (see
Subscriptions).
A variant of the subscription service is used for managing subscriptions in discussions.
The following services are configured and activated:
The following parameters determine the behavior of the subscription service:
Subscription Service Parameters
Parameters |
Required |
Description |
Name |
Yes |
ID of the service. |
Allowed AdminNotifications |
No |
Selection of subscription events for which a notification is sent. The following values can be entered separated by commas: create
(default): Sends a
notification when the subscription is created. When the events
listed above take place, the owner of the subscription in question, and the
users who have subscribed to the resource, receive a notification. When this event takes place, the owner of the subscription, and any users who have newly subscribed to the resource, receive a notification. unsubscribe: Sends a notification when a user has removed himself from the recipient list. When this event takes place, the owner of the subscription, and the user who has canceled his subscription, receive a notification. |
Service User |
No |
The user used by the subscription service for polling resources (for example, subscription_service). The user
must be configured as a system
principal). |
Subscription Service ID in Database |
No |
ID of subscription service entries in the database. More than one subscription service can have the same Subscription Service ID. This makes sense if the subscriptions of a repository are to be distributed among several subscription services. If no specification is made, the system enters the Name as the Subscription Service ID by default. |
Send Admin Notifications to Action Inbox |
No
|
|
Send Notifications to Action Inbox |
No |
Boolean property that determines whether notifications sent by e-mail also appear in the universal worklist. By default, this parameter is activated. If the parameter is deactivated, notifications only appear in the client of the e-mail server specified in the configuration of the e-mail communication channels . |
Originators |
Yes |
List of originators that appear as sender names in notifications sent by the subscription service using various communication channels (see Channel Originators). A channel originator of the type EMAIL (for example, subscription.EMAIL) has to be specified so that you can receive subscriptions by e-mail. |
The KM standard configuration comes with two preconfigured variants of the subscription service:
· Subscription (uses standard event mapping of low-level events to events relevant for subscriptions)
· subscription_collaboration (uses a special event mapping for subscriptions to discussions).
If you want
notifications only to be sent to the universal worklist, you have to select
the value NULL in the
configuration of the notificator
service in the parameter Channels. Then select
the channel None when
creating a subscription (see
Subscriptions).
Normally, you do not need to change the configuration of these services.
To check or modify the configuration of the subscription service, choose Content Management ® Repository Services ® Subscription Service.

You need to register the subscription service with every repository in which you want to use subscriptions. The subscription_collaboration service has to be registered with the repository that contains the collaboration data.