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.