The definition and execution of a workflow can be divided into four main areas. A user executes workflows in their Business Workplace where the work items that they can execute are displayed. A workflow must be defined to be executed. To this end, a workflow definition is created in the Workflow Builder. This definition contains steps that are executed at runtime. The step either control the workflow directly or they contain a reference to a task. The task refers to a method of an object type in the Business Object Repository (BOR) and can be executed at runtime either automatically (background task) or by a user (dialog task).

Work items are displayed to the user for execution in their Business Workplace. Work items are instances of a workflow at runtime. Their are various types of work item. Only certain types are displayed in the Business Workplace.

A workflow must be defined before it can be executed. This workflow definition s made up of steps that control the workflow or refer to the tasks to be executed. You can make additional specifications about agents and deadline monitoring for a step. These specifications are evaluated at runtime by the work item manager. The workflow is started either manually or by the system at runtime. For the system to start a workflow, the workflow definition must contain a triggering event (for example the event "material created"). When the event occurs, the relevant workflow is started automatically.

When you activate a workflow definition , you automatically generate a runtime version. When the workflow is started (manually or automatically), the relevant runtime version is used for the execution. If the workflow definition is changed later and a new runtime version is generated, these changes do not affect workflows that are already being executed.

An object type describes the data with which you want to work in a workflow, for example the object type Material . An object is an individual data record of an object type. Attributes are defined for an object type, which make up its data record (for example, material name or material number). Each object type has methods, in which activities are defined, which can be executed with the data (for example, create material). The transactions and functions of the R/3 System can be called in a method as can your own transactions or other applications. The last important component of an object type are its events. These describe the status changes that an object can undergo (for example, material deleted or material changed). A workflow can be started by an event of this kind being triggered.

The Business Object Repository provides an overview of all object types in the R/3 System. You can use or extend the existing object types as well as create new object types.