Notification Service Description and Assumptions

Description

Initiates notification messages pertaining to relevant events, workflow milestones, etc. Notification may use a variety of mechanisms internal to the CollectionSpace system, such as sending an event message to another service, writing a message to a log or audit trail; adding a Dashboard item; or generating a pop-up window. It may also use delivery mechanisms external to the system, such as sending email and SMS text messages.

Notification mechanisms generally will be abstract, and should invoke a messaging layer.

Assumptions

• Notification mechanisms may be real-time or asynchronous.

• Multiple notification mechanisms may be used to send a single message.

• Notifications can be sent to any "person in the system," or to any "referenced person," whose contact information corresponds to one or more supported notification mechanisms.

Key Concepts

• Especially things that become common sense, and so usually missed by new reviewers

Dependencies

• Services that are consumed by or that are closely related to this one include Contact, Person, and Organization.

• To send automated notifications triggered by scheduled events or a monitored stream of system events, this service may also depend on Scheduler and Generic Eventing.

Background Documentation

• Requirements for audit trails. (Megan is adding this to the Functional Requirements; this is a placeholder until she does.)

• If we have notes from community design meetings, link to them here.
• If we have relevant sections in Spectrum or another such document, link to them here (or cite section numbers, etc.)

Key Team Members

• (Name(s) of members) is/are the primary tech team member(s) for this service
• Need to identify the community members acting as Domain Experts.