SAP Workflow. Business Objects and Events

I'll try to create a small series of notes about workflows and their application. Since it's impossible to cover everything in one, two, or even three notes, I’ll go through the workflow process part by part. I hope the sequence of material will remain clear.

Workflows are often used for approving documents/requests, or simply for sending notifications to certain users or user groups. If we look at workflow usage specifically in the HCM area, it’s worth mentioning Performance Management, E-Recruiting, and LSO. Workflow is essential for automating certain functions within a company’s business processes. A workflow can include a certain number of participants, who, according to their business roles, will perform specific actions (such as approving a request, making changes, etc.).

Each workflow must have a triggering event defined — for example, a created recruitment request or changes in an employee’s master data. You can track such events in the system using a class or a business object. To link a triggering event with a workflow, transaction SWETYPV is used.

A business object from the system's perspective represents a set of attributes, methods, and events for a particular area (e.g., HCM, FI, PM). You can view the list of available business objects using transaction SWO1.

Let’s consider a situation where a functional consultant needs to configure a workflow related to Performance Management. As a triggering event to start the workflow, the consultant decides to use an event from the business object APPR_DOC. Suppose after reviewing the list of standard events, the consultant concludes that the required event is not available in the standard business object.
Task: create a new business object, setting the standard one as the "parent," and create the required event in the new business object.

Open transaction SWO1, enter the name of the new business object, and click Create.

In this example, the name ZAPPR_DOC will be used.
In the window that opens, fill in the fields as shown in the following screenshot.

Pay attention to the Supertype field:
You must specify the standard business object name here. The existing events, methods, and attributes from the standard object will be copied into the new business object. In our case, the supertype is APPR_DOC.

You can compare the results: the new business object (on the left) and the standard object (on the right) will be shown side-by-side.

For the newly created business object ZAPPR_DOC, delegation from the standard APPR_DOC must be set up.

In transaction SWO1, choose Settings -> Delegation and create a new entry.

Open the created business object in change mode. Set the cursor on the Events area and click Create.

In the window that opens, enter the necessary data.

The new event should appear in the list.

Set the cursor on the newly created event and choose Change Release Status -> Object Type Component -> To Implemented.

After successful execution, you will see a confirmation message.

Then, set the cursor on the object type and choose Change Release Status -> Object Type -> To Implemented.

After successful execution, you will see another confirmation message

To fully test the setup, we need a workflow and a created link between the new business object event and the workflow.

Since the workflow does not exist at this stage, we will use transaction SWETYPV to create a record for the business object APPR_DOC and check whether the newly created event is available. Success! The event appears in the list.

We have created an event that can now be used as a triggering event for a workflow.
In the next note about Workflow, I will describe the process of starting a workflow for an appraisal document at the moment when the status of that document changes.