Skip to Content

Workflow Development Standards

This is a subsequent document to SAP Workflow Strategy posted here on SCN - The Workflow Strategy forms the basis of Workflow Development Standards.

I have tried to draft the following Workflow Development Standards for one of my projects. I thought it would be useful to share it and most importantly get some reviews, comments and suggestions from our esteemed workflow fraternity so that we can improve these further. I have already tried to include whatever I have learnt from the experienced members of this group. Please feel free to provide your suggestions



Workflow Developments


Before any workflow development can begin, it is expected that Automatic Workflow Customizing has been performed in your system.


1.1.1.    Important questions to ask before starting your Workflow development

Here is a neat blog which explains some basic questions to ask before starting a workflow development. It is important to know these requirements because these can impact the design and delivery timelines if discovered later on. Please refer the link Workflow functional specifications design



1.1.2.    Workflow Task Development

1.1.2.1. Workflow Prefix Number Range

Definition: Range of numbers that can be assigned to workflow development objects e.g. Workflow Templates, Standard tasks and Standard Rules.

Standard: Number Range used should be between 900 and 999.

Each SAP system (ECC, CRM, HCM etc.) should use a different number to help differentiate different workflows

No number ranges should be defined in QA and production as no development will be done in these systems.



1.1.2.2. Multi Step Tasks (Workflow Template / Definition)

A multi-step task (workflow template) consists of a sequence of steps to be performed either by a person in dialog, or by the workflow batch user in background. A number of steps types (e.g. conditions, events, forks, operations etc.) inside the workflow can be used to control the processing sequence of the tasks.

Workflow Template Naming Standard

The following is a guide only, but should be adhered to when practical. When using a copy of a SAP standard template with only minor modifications it may be preferable to just put a Z in front of the original name.


Mask

Z

XX

_

XXXXX

_

Vn

|

|

|

|

|

Version

Number  to control

|

|

|

|

major changes    after    Go-

|

|

|

|

|

Live

|

|

|

|

|

Underscore

|

|

|

Abbreviated  Description  – May  also  include

|

|

|

an indicator for sub flows

|

|

Underscore

|

Process Area

|

  1. E.g. PS – Project Systems

|

MM – Materials Management

|

FI – Finance

Custom development character indicator

Please note that the naming convention can vary based on your project settings. Another approach can be to add functional meaning into the abbreviation that is not found elsewhere. e.g. "Apr" for approvals, "Auto" for automation, "Exc" for exception handling. We can also add BG/Dlg where it is not obvious.

One could even argue the z isn't needed as the leading '9' already makes it clear it's a custom workflow. Moreover, focus on using the right package for the workflow to be able to list them via package in SE80. 

In summary, use the Naming which best suits your project.

1.1.2.3. Basic Data:

Always have the business object key of the triggering object in the workflow work item text.


1.1.2.4. Description:

In the workflow template description record the triggering mechanism (e.g. transactions, user exits, reports, change documents) and a basic process overview. When standard workflows are copied, note down the SAP template name and abbreviation in the task description.



1.1.2.5. Triggering Event:

Always ensure that the binding to the initiator is complete, and the object is bound in correctly to an element used in the workflow process. N.B. if you are using object container elements created by inserting tasks in the process then ensure these are checked as Import Parameters before inserting the event.


1.1.2.6. Agent Assignment:

When using Start forms/Transactions, or ‘Start Workflow’ functionality, ensure that the agent assignment is maintained, otherwise leave unassigned. This will always need to be assigned for SRM workflows and those directly started by web forms (such as ESS Leave Request). Include the agent assignment in a Customizing TR using RHMOVE30 (Refer following article on the details of RHMOVE30 usage http://scn.sap.com/docs/DOC-51922)


1.1.2.7. Container Elements:

Create container elements for all known import parameters (whether objects or single fields) before inserting the triggering events, this will make bindings easier. E.g. Workflow is triggered from a material create event – create a container element called BUS1001_OBJ first (for objects use the technical name of the object plus _OBJ (indicator for object)) and then bind the event object to this element.


1.1.2.8. Header Data (Workflow Builder)

Where appropriate maintain a workflow administrator in the Responsible tab


1.1.2.9. Step Data:

Always maintain step outcome names (useful for workflow logs).

Only foreground steps should be marked visible in "All workflow Logs" (tab Details) - rest of the steps should be marked "Only in Technical Workflow Logs".


1.1.2.10. Agent assignment:

Always try to use Rules for Agent determination instead of object methods called in preceding steps.

Never assign a step directly to an organizational object or user id. Instead either use an Expression, a rule, or if specific enough, just use possible agents. The idea is to only use soft links rather than entering ids that would have to be changed by a transport. Include the agent assignment in a Customizing TR using RHMOVE30 (Refer following article on the details of RHMOVE30 usage http://scn.sap.com/docs/DOC-51922)


1.1.2.11. Single Step tasks (Standard Tasks)

IMPORTANT: As a base rule, always club functionality of multiple background steps into one, as much as possible. Each background step involves a tRFC call, which in itself takes about a second. So if your workflow has 5 background steps to do different activities before a dialog step, the workflow runtime
would need 5 seconds minimum (plus the execution time of those steps) to get to the dialog step. Best approach is to combine them into one step (of course you can call five individual methods in one method and call that one in a single
background step).

A standard task is a step executed either by a user in dialog, or the workflow batch user in background. Standard Tasks typically call object methods to deliver the required functionality to a user, however, when linked to web functionality a variety of techniques can be used to link the task and the web screen.

Standard Task Naming Standard

Mask

Z

XX

_

XXXXXX

_

N

|

|

|

|

|

One Digit Number (optional)

|

|

|

|

|

|

|

|

|

Underscore

|

|

|

Abbreviated Description

|

|

|

|

|

Underscore

|

Process Area

|       E.g. QM – Quality Management

|

MM – Materials Management

|

FI - Finance

Custom development character indicator (Z or Y)

Length

12 Characters

Please note that the naming convention can vary based on your project settings. Another approach can be to add functional meaning into the abbreviation that is not found elsewhere. e.g. "Apr" for approvals, "Auto" for automation, "Exc" for exception handling. We can also add BG/Dlg where it is not obvious.

One could even argue the z isn't needed as the leading '9' already makes it clear it's a custom workflow. Moreover, focus on using the right package for the workflow to be able to list them via package in SE80. 

In summary, use the Naming which best suits your project.

1.1.2.12. Use of Super Type Objects

Always use standard (super type) business objects in the object method section. Any enhancements should be available through delegation.


1.1.2.13. Work Item Text

Always maintain a work item text, even if the item is to be executed in the Background (in this case begin the text with ‘BCKGRD :’). If the requested text is too long for the field then create short container elements to help fit in extra variables – populate with the step binding from object attributes. 

For Foreground Steps, always start with a verb, example Approve: Leave Request by user XYZ...

Ensure to have dynamic values in the Workitems text, preferably the key (example the PO number or Document number) so that the task can be differentiated for a specific document in transactions like SWI1 or SWI5 or SBWP.


1.1.2.14. Deadline Texts

If ‘Simple Deadlines’ are to be used then ensure the relevant texts are maintained.


1.1.2.15. Terminating Events

Use terminating events when appropriate to ensure a user has completed the relevant tasks required and to allow the workflow to respond standard transactions outside of workflow.


1.1.2.16. Possible Agents

Ensure that relevant possible agents are maintained. The task should at very least be classified as a General Task. Include the agent assignment in a Customizing TR using RHMOVE30 (Refer following article on the details of RHMOVE30 usage http://scn.sap.com/docs/DOC-51922)


1.1.2.17. Task Groups

Task Groups are a collection of standard tasks, workflow templates and other task groups, which are used in a common context. You can set up hierarchies of task groups by inserting task groups into other task groups.

Tasks groups are the preferred option for possible agent assignment where more than one task shares a possible agent assignment – this speeds up agent assignment after transports.

Task Group Naming Standard

The following standard should be used where practical:

Mask

Z

XX

_

XX

_

XXXXX

|

|

|

|

|

Task

Group

Abbreviated

|

|

|

|

Description

|

|

|

|

|

Underscore

|

|

|

Functional area

|

|

|

  1. E.g. PR – Purchase Requisition

|

|

|

QN – Quality Notification

|

|

|

QB – Quantity Block

|

|

Underscore

|

Process Area

|       E.g. QM – Quality Management

|

MM – Materials Management

|

FI - Finance

Custom development character indicator

Length

12 Characters

1.1.3. Using ABAP Classes in Workflow

1.1.3.1. Custom Class Development

A relatively new feature within SAP Business Workflow is the possibility to use ABAP objects instead of BOR objects. ABAP objects use the newer ABAP editor and enforce improved coding standards by only allowing the use of object-oriented ABAP standards and syntax.

Object Type which was earlier the base building block of workflow development, could still be used within or in combination of the ABAP class to make use of existing functionality delivered by SAP.

Object Types encapsulate functionality within SAP in an ‘object wrapper’ and can be accessed uniquely under an identifying key, normally comprising the keys of an ABAP Dictionary table.

Objects are instantiated at runtime by assigning key fields to an object type. There are many events associated with BOR objects that happen natively in the SAP system and these must be considered for triggering a workflow in SAP business suite applications.


Enhancing standard objects or using Subtypes is not a best practice anymore and we must make use of ABAP classes instead.

Refer the following links (in the given order) for further details of using classes in Workflows:

  1.     Why use ABAP OO with Workflow?
  2.     Getting started with ABAP OO for workflow
  3.     Using ABAP OO Methods in Workflow tasks
  4.     Raising ABAP OO Events for Workflows
  5.     Using ABAP OO Attributes in Tasks
  6.     Using Functional Methods in Workflow Tasks
  7.     Referencing BOR Objects in ABAP OO Classes


1.1.3.2.     Extending existing Objects: - [Avoid using subtypes for custom functionality. Instead, use ABAP Classes]

When extending an existing business object through subtypes, add ‘Z’ as a prefix to the SAP business object.

Always use delegation in order to use the standard SAP business object in all tasks and workflows. As well as enabling the use of standard functionality which may already be in the system, this also enables features such as Generic Object Services.


1.1.3.3.     Program Name, Object Name, Name and Description – [Relevant for Subtypes; Avoid using subtypes for custom functionality. Instead, use ABAP Classes]

Same as Object Type and any additional information could be added to the description.


1.1.3.4.     Defining ABAP Class

The key to enabling a class to be used in workflow is the IF_WORKFLOW interface. Simply defining it in the class makes it available to use in the workflow builder and task editors. We may still use standard business objects to trigger the workflow but for any enhancement, we must use class.


1.1.3.4.1.Methods

Handling Methods of IF_WORKFLOW

Please refer Why use ABAP OO with Workflow for the usage of the IF_WORKFLOW Interface methods. If you will be leaving any method empty, it is good to comment the reason inside the coding block and also place a RETURN statement to avoid unnecessary EPC / CI warnings for empty methods of classes.

Special Method - CREATE_INSTANCE

If your workflow is based on a standard BO and you further need custom attributes and methods, define an ABAP Class with IF_WORKFLOW Interface. Handling of IF_WORKFLOW methods is described in the blogs given above.

However, you would first need to create a runtime instance of your class in the workflow in order to read the Attributes and to access Instance Dependent methods. To achieve this, do the following:

  1. Create the KEY fields (of the base BO) as attributes of the class and set the Key check box for these fields
  2. Create a Constructor for the class and populate the necessary attributes via the Constructor coding
  3. The Constructor should have the Key field(s) as the importing parameter(s) In your ABAP Class, define a Public Static method, example CREATE_INSTANCE with importing parameter as the Key of the base BO and one exporting parameter: TYPE REF TO the same ABAP Class
  4. Within CREATE_INSTANCE, issue the command CREATE OBJECT to create the instance of the same class - this will essentially call the constructor and set the attribute values for you
  5. Pass back that instance in the exporting parameter of the method CREATE_INSTANCE
  6. Within your workflow, as a first step, call this method via an activity step and bind back the class runtime instance to be used later on

A special handling is required for method BI_PERSISTENT~FIND_BY_LPOR to prevent multiple instantiation of the Class Object at runtime.

The concept is explained via an example of a Service Entry Sheet Workflow where the Key field is SES_NUMBER (Type LBLNI - Entry Sheet Number) and the ABAP OO Class name is ZCL_MM_SES_WORKFLOW

The method FIND_BY_LPOR will be called by the workflow runtime to get the Persistent Business Instance (RESULT) by passing the Local Persistent Object Reference (LPOR).

The purpose of this method is to provide an instance of the class. Now, to prevent multiple instantiation at runtime (for multiple calls), ensure to save the first created instance in a STATIC TABLE

In our example, the table is defined as:



This table GT_EXISTING_INSTANCES is of Direct Entry Type, which is defined as:



The TYPE GTY_SES_INSTANCES is defined in the TYPES Section of the class, which again is a Direct Entry Type:



The definition of this type has one field for the KEY (SES_NUMBER) and one field for the Object Reference (reference to self class):

Coming back to method FIND_BY_LPOR, first check if we have an instance in this table, if yes, pass that back else create a new one, save in this table and then pass it back. The following screen shot explains the entire coding process in detail.

ABAP classes have an additional advantage of making use of functional methods unlike BOR methods. Functional methods give flexibility to be directly called from within the binding (Refer Using Functional Methods in Workflow Tasks)

If the method is used as a place holder for web functionality (example Leave request Approval) then it is recommended that if the user could possibly execute the item from SAPGUI they should be displayed a dialog pop-up to inform them that they are using the wrong inbox and then trigger an exception. Refer Standard Task TS12300097 as an example.

Naming Standard:

Follow Class Naming Guidelines.

Development Standards:

Import and export parameters should be used to pass data to and from a method. ABAP class methods do not have a result parameter like the predecessor BOR objects but they do have returning parameter which is used in functional methods. Use functional methods to return the instance of the class.

Public Methods:

Only Public methods can be used inside workflow.

Private Methods:

Private methods are well suited to implement support functions and subroutines.


1.1.3.4.2.Exceptions

Exceptions should be used to trap any errors.  Following exceptional classes are available to be used as a superclass for creating a Z class in SE24.

CX_BO_TEMPORARY

CX_BO_ERROR

CX_BO_APPLICATION

Temporary Exceptions should be used for any temporary errors such as ‘Document Locked by …’ Ensure that when creating a custom exception class, we check the "With Message Class" flag. All messages passed in this manner are visible in the workflow log and the long text can be viewed for further troubleshooting options.

For the message used in exceptions we should include the following to enable the where-used list for the message from SE91:

Note that this will result in an EPC warning for ‘Impossible Condition’, which can be hidden by the pragma ##BOOL_OK (Check with your lead if pragma usage is permitted or it should be an approved exception via ABAP Test Cockpit - Take a look here and here, or scroll down to see a screenshot here)

Example of using an Exception nested within methods is follows.

Here, the method CREATE_INSTANCE is a STATIC PUBLIC method, called from a workflow task to instantiate the class object. This method creates an object of the class and returns it to the caller. CREATE OBJECT statement will call the CONSTRUCTOR, which in turn is responsible to populate the class attributes. In our example, the CONSTRUCTOR issues exceptions based on various conditions. The issued exception has to be propagated upwards by the caller (method CREATE_INSTANCE) so that the messages are visible in the workflow log.



The caller, CREATE_INSTANCE, has to trap the same exception and propagate it upwards:



If this propagation does not happens, the workflow log will not show the exact error message; it will display a generic error "Exception Occurred in Method <Name> of Class <Name> ; which does not gives the exact reason of error.

Naming Standard:

ZCX<Name of standard exception superclass>

Example: ZCX_BO_EXCEPTION



1.1.3.4.3.Attributes

Attributes are the characteristic features of an object. The possible attributes of an object are defined as part of the object type definition in the Business Object Builder. Attributes can be used to formulate conditions in the workflow definition and are also used in work item texts. The object attributes are read or determined at runtime. In case of ABAP class, we should only create public attributes for any fields you want to use in workflow. For any fields to be used internally, we should create private attributes.

Ensure that there is at least ONE KEY Attribute which can uniquely represent the instance.

Naming Standard:

New attributes may start with Z and then any descriptive text, new words starting with uppercase. Please apply the Class naming guidelines

Development Standards:

For static attributes (e.g. created by) ensure that the object buffers are checked before any calculations are performed to improve object efficiency. Only very dynamic attributes should not include a buffer check.

If a virtual attribute is particularly complicated, involving multiple selects, consider how widely it is used in different workflows. If it is only used in very limited places in the workflows (and particularly when a business object is used in multiple processes) then consider using a background method to calculate the value for that process.


1.1.3.4.4.Events

Events signify when something has happened to a business object for example: "Invoice entered", "Purchase order released".

The list of possible events is defined for an object type. This list can be extended according to customer requirements using the delegation concept. However, you have to ensure that the events are actually raised in the application (or can be raised using customizing or development).

Naming Standard:

New events should start with Z and then any descriptive text, new words starting with uppercase.


1.1.4.    Workflow Agent Rules

Rules determine the selection of the specific agents during the running instance of a workflow process. Rule resolution takes place at runtime depending on the information from the current process. The result of rule resolution is an agent, or a list of agents, who are responsible for the actual processing of the task.

Naming Standard

Mask

Z

XX

_

XXXXX

_

NN

|

|

|

|

|

Two character number

|

|

|

|

|

|

|

|

|

Underscore

|

|

|

Abbreviated Description

|

|

|

|

|

|

|

|

Underscore

|

Application Area

|

Custom development character indicator

Length

12 Characters

Development Standards

Default ‘Terminate if rule resolution has no result’.

Description

Short description of how the rule works and in which workflows it is used.

Responsibility Naming Standards

If Responsibility Rules are used then ensure that the responsibility has a meaningful name relating to the data maintained for the responsibility. Please provide clear description of the Rule as it is visible as a help text in OOCU_RESP for the users who will be maintaining these rules.

Also, it would be good to have Rules with Secondary Priorities so that a rule always results in an agent. Refer the following link for further details on Secondary Priorities: Defining Rules Using Responsibilities

1.1.5. Re-evaluate Rules

When work is to be sent to a widening pool of users, e.g. as part of escalation, then the “Re-evaluate Rules of Active Work Items” response should be use to implement this scenario.

This involves:

  1. a) Assigning the original agents to the workflow step in a dynamic pool that can be updated, e.g. using a multiline element of type TSWHACTOR
  2. b) Creating a specific event to trigger re-evaluation, e.g. object.REEVALUATE_AGENTS. 
  3. c) This event should then be placed in the Basic Data of the workflow header in the Events section of the Version Dependent section, using the “Re-evaluate Rules of Active Work Items” response.  If the workflow contains nested subflows, the event must be placed in the basic data of the workflow or subflow that contains the workflow step to be re-evaluated
  4. d) In the steps following the relevant deadline reached outcome, the dynamic pool of agents to be assigned is updated to add the additional agents, and the re-evaluate agents event is then raised using an Event Creator step

1.1.6.    Start Conditions

Start conditions are used for restricting the triggering a workflow to instances where certain conditions are met. These (or check function modules for complicated evaluations) should be used rather than having a condition as the first step in a workflow.

Exception to the above is when a condition involves evaluation of a parameter which gets populated in the SAME LUW of the event trigger. Check function modules and Start conditions are always called in the SAME LUW of the event trigger. Chances are that the Start Condition/ Check FM get executed BEFORE the parameter gets populated and the check condition does not evaluate correctly (example, reading change documents for a particular value change).


1.1.7.    Terminating Events of Workflow

Workflows must always terminate when the workflow is no longer relevant, e.g. when the object is physically or logically deleted, or changed to a status indicating it is no longer relevant, or a form is withdrawn.

If only termination of the workflow is required, then the terminating event should be specified in the Basic Data of the workflow header in the Events section of the Version Dependent section, using the “Cancel Workflow” response.

This simplifies flowchart design and maintenance.

1.1.8. Subject Text Standards

To ensure the subject text is a useful sort criterion in the inbox, and to facilitate prompt understanding and consequently actioning of the work required, standards will be applied to all subject texts for both work items and emails as follows:

  • The first word will be the primary action type in Upper Case. This is used as the primary sort criterion.  For work items this will be a current tense verb describing the action to be performed e.g. APPROVE, REVISE, CREATE, COMPLETE. For emails this will be a past tense verb describing the cause of the email notification, e.g. APPROVED, REJECTED, OVERDUE.
  • The second word will be the primary business entity involved and either the id or name of the business object, e.g. Asset Laptop ABC, G/L account 123456
  • If any there is any capacity for additional text (subject texts are limited to approx. 50 characters in length) this can be used at the discretion of the business process

  Example of full subject texts:

  • APPROVE: Asset maint form 123456 from John Smith
  • APPROVED: Funds transfer 1234789 effective 18.03.2010


1.1.9. Body Text Standards

  To facilitate prompt understanding and consequently actioning of the work required, and to support occasional users, standards will be applied to all body texts for both work items and emails as follows:

  • Critical information for prioritizing work is listed first, e.g. Critical Date, Due Date
  • Brief (1-2 paragraphs) instructions for occasional users are then provided, particularly clarification of what is required to complete the work and therefore remove the work item from the inbox
  • Reference to further instructions or policy documents can be provided as a text or hyperlink at the discretion of the business (if hyperlink this will be implemented as an additional Action type= link tag using UWL XML configuration)

  Body texts should be succinct.  Ideally the complete body text should be able to be displayed in the Preview area when the Internet Browser Window is maximized without requiring the user to scroll through the text.

1.1.10. Work Item Footers

A standard support text such as “For assistance in processing this workflow please contact XXXX”. If practicable the text will be stored and maintained centrally, e.g. as a “General Text” maintained via transaction SE61.


1.1.11. Email Footers

To avoid unnecessary and ineffective email responses, all email notifications should contain a standard footer text such as:

“*** This email has been generated automatically. Please DO NOT REPLY. ***”

The exact text is to be decided with the business. If practicable the text will be stored and maintained centrally, e.g. as a “General Text” maintained via transaction SE61.

1.1.12.  Workflow Related Function Modules

Function modules could be used in business object methods, Rule Resolution (when complicated requirements exist to determine an agent) or in Receiver Type and Check Function Modules.

Rule, Receiver Type and Check function modules have to satisfy standard interface requirements to be able to work in the workflow environment. It is advisable to copy an existing standard function module to get this interface correct.

Please refer to ABAP standards and procedures for function module naming standards.


1.1.13.  Development Class / Packages

A development class or Package is a group of logically related development objects. A development class contains all the development objects that must be developed, maintained, and transported together. The objects that make up a transaction usually belong to one development class. Customer development classes begin with 'Y' or 'Z'.

A new development class for workflow ZWF1 should be used for all workflow developments. If not, please follow the project development package guidelines.


1.1.14.  Transport Procedures

Transports are used to transfer development components from one system to another. The components to be transported are specified in the object list of a transport request.

Please refer to basis standards and procedures for general transport procedures.

For workflow developments it is recommended to transport in the following order

  1. Workbench Requests:
    1. Related developments – e.g. Development classes, Tables, Function Modules etc.
    2. Business Objects
    3. Workflow Templates, Standard Tasks, and Workflow Rules
  2. Agent Assignments (ALWAYS include them in a TR - refer http://scn.sap.com/docs/DOC-51922 ).
  3. Event linkages and activation

It is recommended that in each target system the workflow test environment (SWUD) and consistency checks are used to compile and check the workflows before use.

1.1.15.  Web Enabled Workflow

There are various techniques for linking a workflow step to a web screen. The inbox used will partially determine the best approach.


1.1.16.  Portal

If the portal is used the Universal Worklist acts as the mechanism for launching the correct web screen. This is done through mapping the relevant task to the correct ‘Visualization’ technique (iView, BSP etc.). To help generate this mapping correctly transaction SWFVISU should be maintained in the backend system. It should be noted that the mapping in the UWL overrides any settings in SWFVISU once this has been initially generated.

If custom iViews are called from the workflow then a Task with a Dummy Method will be required in the backend (see section on methods above). The UWL automatically passes the Work Item Id when it calls an iView – the iView will then need to retrieve information from the backend using a remote enabled function module – this can then retrieve data from the workflow container. Once the user has successfully completed processing, the data can be set back to the container and the work item completed using the relevant WAPI calls (wrapped in an RFC Function module).

Helpful links:

SWFVISU

Task Launch Customization

Configure UWL

UWL for WebDynpro Based Decisions

UWL FAQ


1.1.17.  SAPGUI / E-Mail

If no Portal is used web services can be launched using the Web service Handler. If the web service handler is used it is also possible to build a URL to directly launch a service from an e-mail, although a dummy user who is a possible agent will be required to complete the URL.


1.1.18.  E-Mail Connectivity

If E-mail Connectivity is required for a process this can be achieved in a number of ways, all of which have the pre-requisite that SAP Connect has been set up.

Simple notifications can be sent from a workflow process using a Send Mail Step. E-Mail addresses should never be ‘hard-configured’ but should instead be derived from an expression. A good idea is to use TYPEID 'G' (Organizational Object) and the expression should be of type SWHACTOR (or multiple TSWHACTOR), where SWHACTOR-OTYPE is 'US' and SWHACTOR-OBJID is the username. The system will send a notification to the users SBWP inbox. To direct this mail to the user's email address use SO16 -> Tab Mail Sys. Group -> Select "Send to User's Home Address". The Workflow runtime will then pick the email address from SU01 Master Data (if the Communication Method is set to INT - Internet) or the HR Communication Info type 0105. If both are maintained, anyone can be picked up by the workflow runtime, the order is not specific.

NOTE: SO16 settings have to be done in every system - DEV, QA and PRD.

To inform users that they have new workflow items, e-mails can be sent using RSWUWFML2, or from 6.40 onwards transaction SWNCONFIG can be used.

Basics on Extended Notifications

SAP Help on Extended Notifications


1.1.19.  Finally, avoid these common pitfalls

Top 10 Mistakes by Workflow Beginners

Another 10 Mistakes by Workflow Beginners




Thanks for being patient to read till this point ;-)



Tags: