Workflow templates for
HCM Processes and Forms
have the same meaning as workflow templates for other applications. You use them to define the flow of a process. In the workflow steps, you specify what happens when a step is executed, and how the system determines the agent responsible for a process step. The advantage of the workflow templates for
HCM Processes and Forms
is that you create a close link to other
HCM Processes and Forms
objects in the workflow objects.
In the workflow templates for
HCM Processes and Forms
, you must create a close link with the objects specific to
HCM Processes and Forms
, such as the form scenario or the process object, when setting up the workflow.
If you set up the workflow templates for
HCM Processes and Forms
to depict the processes in your enterprise, you should always take note of how a workflow template is linked to other objects, and the subobjects (steps, tasks, agent assignment rules, and so on) of the workflow template that are involved.
To facilitate the creation of these links, a wide range of standard workflow objects are available in which these relationships with other
HCM Processes and Forms
objects are already depicted:
Either exemplary, such as in the demo workflow templates,
Or as directly usable for your processes in the form of technical workflow templates and standard tasks
The workflow templates in
HCM Processes and Forms
have the following special features:
Process control
You use the workflow templates to specify which steps are to be processed by users or by the system, and the conditions under which they are processed. In addition, the workflow template is integrated with the Start Application and the Form Application .
The start application triggers the event that then starts the workflow. The form application is called when an interactive workflow step is executed.
Control of the execution of the workflow steps
When defining the workflow steps, you specify which functions are to be available in the form application. By using certain standard tasks, you specify which views are provided in the form application.
The
Approve Form
standard task provides two views: an approval view and a confirmation view.
The
Edit Form
standard task provides three views: a processing view, a check view, and a confirmation view.
You also specify for each workflow step which functions the user can execute.
For a workflow step
Edit Form
, you can decide, for example, whether the following buttons can be seen on the form application:
Save Draft
Back to Author
Withdraw Process
Send to Expert
When setting up the workflow steps, you specify which form scenario is used in the workflow step. In assigning the form scenario, you have the following options:
If you run the process using a start application, you specify the required form scenario in the Customizing settings for the start application. If you want to retain the form scenario of the start application throughout the entire workflow, you transfer the form scenario with the container element FORM into the workflow container and the individual workflow steps.
If you want to use more than one form scenario in a process, you can specify the required form scenario at the relevant workflow step with the container element FORM.
Control of the agent determination
The agent determination rules developed especially for
HCM Processes and Forms
enable you not only to determine the correct agent for a process step, but also to run authorization checks.
The following graphic shows the elements of the workflow templates at which you can create links to other
HCM Processes and Forms
objects.
Name |
Link |
---|---|
Identifier |
|
Name |
|
Workflow Step |
You can use the standard tasks to map the interactive steps in the process and the background activities in the system, such as the processing of data in the backend system. |
Workflow Container |
The following container elements are especially important: PROCESS_OBJECT (process object) FORM_SCENARIO_STAGE (form scenario step) PROCSTATE (processing status) FORM (form scenario) For a description of these and other important container elements, see the documentation for the standard tasks. |
Start Events |
As the start event for all workflow templates, you use the triggering event
This ensures that the workflow instances receive the correct information from the Customizing settings and the start application. |
The following graphic illustrates how the various
HCM Processes and Forms
components work together when a process is run, from the point of view of
SAP Business Workflow
.
See also: