Best Practices for SAP Workflow Development

Hi friends,

It is very important to follow few rules while developing new workflows. Once developed and moved into Production, it will be tough to alter the workflows, because of the efforts involved in regression testing all the scenarios.

Here are the Workflow development best practices I learnt from my experience.
If you have any more points or questions please reply in comment to this blog.

Agent determination

--> As far as possible do not declare tasks as generic tasks. This will ensure that unauthorized people will never get the work item.
--> If in any case you had to declare a task as generic, ensure that you check the option "Terminate workflow when no agent found"
--> Ensure that agent determination is through Position instead of using users.
--> Handling "Agent not found" scenarios. Better to have rules for redirecting work item when no action was taken by the primary agent for a specific period of time.

Emails
--> Email subject within 50 chars
Ensure that emails originating from workflow have only 50 characters in length. Exceeding characters will appear in workflow log, hence they would look fine if you are looking into workflow log.

But if you see in SOST, you see that characters are truncated after 50 characters

Dialog work items --> Title of dialog workitems are very important. An end user depends on this to identify the type of work item. It also becomes the subject line of extended notifications. Since this is used by the end-user, it has to be less technical and more user or business friendly.

When you create work item texts, you must take different aspects into account, such as multilingual capability or the user-specific formatting of dates and numbers. See SAP Note 1154835. This would also impact the performance while loading these items in UWL or SAP Inbox.

--> Extended notification content
As you know the dialog task description appears as the email content in extended notifications. At the time of developing the dialog task ensure that the task description meets the email (notification) content requirement.

Changing Workflow Template
Version is a beautiful concept SAP has for keeping track of Workflow Template changes. Always create a version before you change an existing template. This will help you to refer back to previous template and even switch to old template if the new changes fail.

Errors in Workflow
Error happens. Regardless of the care you have taken in designing workflows, error happens in workflow. So It is important to handle these errors and develop strategies to handle error scenarios.

--> It is also important to ensure that errors are noticed. To do this you need to ensure workflow is written inside try catch blocks, so that all errors are captured.
--> There should be a strategy at Organization level to handle such scenarios. Errors can be technical or application errors. It is wise to route application errors to Business Process team. Technical errors can be routed to Workflow administrator for resolving.

Workflow Administration
Workflow admins get many routine requests listed as below. It is important to establish business process for below mentioned actions, thus you are with better terms with auditing people.
--> forwarding a work item
--> adding approver to the workflows (to rules or approver tables)
--> killing a workflow ( might be required in case of a wrong WF template moving into prod)

Generic
--> It is mandatory to have a life time for a workflow. That means, if the workflow is pending for action at an agent, it should not be open/ 'live' for indefinite time. There should be time period after which workflow becomes obsolete, thus 'kills' the workflow. Thus you can reduce the load on the system from unnecessary workflows.

--> How the end user will know the current status / history of actions / actual submitted for of Workflow.. ? If you are using processes and forms and if you are in ECC6.0 Enh 2, then SAP provides this functionality.
If you happen to be ECC6.0 (without enh pack) or below, you need to have your own reports/custom applications built to read workflows. In this case it is important to have consistent container names and positions (task level? WF level?) across workflows. This ensures that your report program has less hard coding and thus reducing maintenance costs.

--> Develop a reusable utility class for the WF development : Some functionality in WF that are commonly used and that can be included as methods are listed below.
A method to read a distribution list,
Reading value from a particular customizing table,
Reading manager of an employee,
Reading a rule,
Read if employee is locked

That is it for now. Please let me know your thoughts about this article.