Communications
The communications section of RPM allows resources to view all communications that they have sent or have been invited to participate in. These communications can be part of a workflow that requires a resource to respond by voting or completing a checklist, a notification, or a staffing request for a project or proposal.
As shown in Diagram 1, below, the API containers corresponding to each
of these are WorkflowStepNotification, Notification and StaffingRequest:

Creation
A WorkflowStepNotification is automatically created by a running workflow process, when it reaches a voting or checklist step. Once a step arrives in a resource's inbox, the resource must vote if Must Vote was
checked in the Participants tab of the workflow step's configuration. Otherwise, voting is optional for the workflow process to move onto the next step.
A Notification is an e-mail internal to RPM, with proprietary
attachments (work management elements, documents or scope elements). This
function is used to notify team members of changes to their assigned
project elements orto request start/finish re-negotiation or any other
communication relevant to the element under discussion. Notifications
are mostly for messages where a response is not necessarily required or
when a pre-configured workflow process does not exist. Any project
resource can use the Notification function to send messages relating to
a project event or element to any other stakeholder or team member. To create a Notification using the API, the
sendNotification API call must be used.
A StaffingRequest is a mechanism that resource managers can use to communicate resource suggestions or replace profiles with resources, for projects and proposals. Depending on the organization's process, the resource manager may be responsible
for staffing the project or simply responsible for finding the required
resources and preparing a suggested list of possible resources from which the
profiles will eventually be replaced by the project manager. To create a StaffingRequest using the API, the
sendStaffingRequest API call must be used.
When any of these objects are created, the corresponding WorkflowAttachment is also created, linking the communication to the RPMObject that it was sent from. Additionally, a child of type WorkflowResponse is created for each resource that the communication has been sent to, as well as the author. Initially, the WorkflowResponse container only contains information relevant to where the communication can be seen in the resource's view (Inbox or Sent folders), whether the user has read the communication, and whether or not they have responded to the communication. Diagram 2 illustrates the relationship between WorkflowResponse and GenericCommunication, as well as the enumerations used by these containers.

Sending a response
Responses to WorkflowStepNotification and StaffingRequest can be sent using the
sendWorkflowResponse API call. Responses are sent by a specific resource, therefore, sendWorkflowResponse requires a WorkflowResponse object as input.
Saving a response
For WorkflowStepNotifications that have been created by a workflow step of type checklist, it is possible to save the response before sending it.
Responses to WorkflowStepNotification can be saved using the
saveWorkflowResponse API call.
Updating the read and folder attributes
In WorkflowResponse, the read attribute indicates whether or not a communication has been read and the folder attribute determines which folder the communication
is located in. The updateReadAndFolder API call can be used to update these two values, however, certain restrictions apply.
Once a WorkflowResponse object has been moved to the Archived or Deleted folder, it cannot be moved back into the Inbox or Sent folders.
Instances of WorkflowResponse with a WorkflowStepNotification as parent can only be moved into the Archived or Deleted folders if the corresponding RunningWorkflowProcess is not in Open state.
Additionally, a communication cannot be moved into the NotVisible folder, this is performed using the delete API call.
Deleting
The delete method can only be called on instances of GenericCommunication, not any other communication containers. Deleting an instance of GenericCommunication does not delete the object entirely, it deletes it for the resource that is currently logged into the system.
Other resources having received the communication will still be able to load the GenericCommunication object, the only distinction is that the instances of WorkflowResponse for resources that have deleted the communication will have the folder set to NotVisible.
Instances of WorkflowResponse with a WorkflowStepNotification as parent can only be deleted if the corresponding RunningWorkflowProcess is not in Open state.