Using Statuses and Workflows for Portfolio Items

The status in PPM documents the status of objects, such as portfolio items, decision points, reviews, or what-if scenarios. Unlike in Project Management, the status in PPM does not control which business transactions are allowed or not allowed by default. However, the change of status can trigger workflows that automatically inform the person responsible of these status changes.

Statuses are defined centrally in PPM Customizing in the portfolio-independent settings. Examples of statuses that are delivered as a standard are Inactive, In Preparation, In Progress, Approved, or Closed. You can also create your own statuses in Customizing. The definition of a status requires only an identification and a text. You define which statuses can be used for portfolio items and their decision points in the definition of the portfolio item types. When you do this, you also decide the sequence of the statuses in the items or decision points. In the definition of the portfolio types, you define which statuses should be available for reviews and what-if scenarios, and the possible sequence of these statuses.

When you assign a status to a portfolio item type, you can also define a status group. The status group controls the tab pages of the item dashboard on which a portfolio item should be displayed when the corresponding status is active. The tab pages enable you to limit the display of portfolio items in the dashboard. There are different tab pages like All Items, Active Items, , Active SuggestionsActive Escalations, or Inactive Items.

When defining the status sequence for items and decision points, you can also make a setting, which ensures that the users responsible receive an e-mail due to this status change. For this, assign a workflow ID to the corresponding status change.

When you change attributes (fields) or statuses of portfolio items or decision points, workflows can be triggered automatically in PPM, which informs the responsible users by e-mail. To be able to use this function, you must configure various settings in the PPM core system.

First, activate the required workflow or event linking. You can do this in PPM Customizing under Portfolio Management → Global Customizing → Global Settings → Workflow Settings → activate Workflows.

For workflows with attribute changes, you must also activate a classic BAdI implementation using the transaction SE19. For attribute changes in portfolio items, RPM_PROJ_CUST_WF is the implementation. For attribute changes in decision points, /RPM/DES_POINT_WF is the implementation. For workflows with status changes, you must define the status changes for which e-mails are to be sent in the definition of the portfolio item type. You can do this by assigning workflow IDs to the corresponding status changes.

A workflow ID consists of a key and a description, and is created in PPM Customizing under Portfolio Management → Global Customizing → Global Settings → Workflow Settings → Define Workflow IDs.

Workflow IDs are already predefined for attribute changes, for deletion, and for status changes as a standard. The workflow IDs are used to determine the recipient list for the corresponding workflow. To do this, choose the Customizing activity Portfolio Management → Global Customizing → Global Settings → Workflow Settings → Maintain Configuration for Workflow Recipients, and assign authorization activities such as admin, read, or write to the workflow IDs. If a workflow is now triggered, for example with a status change, the system uses the workflow ID to determine all users in the portfolio item who have authorization for the activity that is assigned to the workflow ID. These users are then transferred to the recipient list of the workflow. For the system to successfully send notifications to these recipients, the e-mail addresses must be defined in the user data of the relevant users.

If required, the notification may also contain a link to the object, for example, the portfolio item. For this, you must define a suitable web server alias in Customizing. The alias must contain the identification of the logical system which is assigned to the client. If you use SAP Enterprise Portal, you must assign the parameter PORTALLINK to this alias and enter the URL of the portal as a parameter value.