Form Routing

When a form is submitted back to SAP, either for an on-line scenario or for an off-line scenario, the form is returned with its original status plus the ‘action’ selected by the submitting user.  The system uses the form routing configuration to determine a new status, new form owner etc. for the submitted form during the update to SAP.

Form Routing Configuration

Form Routing Table

Form Routing in FLM is achieved by configuration a Form Status Map in the FLM Routing table.

 The routing table is keyed on customer, form type, form status and action.

 

 The following information is derived from this table:

  • New form status
  • New transportation mode
  • FLM Portal Inbox task instruction
  • Trigger for synchronous FPE posting
  • E-mail notification settings

New form status

The new form status is derived from the existing form status and the selected form action.  For more complex scenarios, where the new status might depend on form data, then the routing user-exit can be used to over-ride the status derived in the routing table.

New transportation mode

The transportation mode enables on-line forms to go off-line or vice versa.  For off-line forms, the e-mail recipient is typically derived using the e-mail user-exit.

Portal task instructions

Portal Task Instructions messages are defined in message class /FLM/nnn where nnn is the Customer Code.    SAP messages can contain variables &1, &2, &3 and &4.  The values from the first 4 Index fields will be substituted in at runtime into the four message variables.

Trigger for synchronous FPE posting

If the form must immediately trigger an SAP update rather than waiting for a batch job to run, then the form posting engine can be triggered synhronously.  Any posting errors can be sent back to the user if required.

E-mail notification settings

If an e-mail notification is required to be sent to the new form owner, then a SAP standard text or FLOE email  can be selected for the e-mail subject and e-mail body.  The e-mail will be sent by default to the e-mail address stored on the SAP user master record of the new form owner.  This can be over-ridden using the Notification/Reminder user-exit. 

Within the routing table we need to map every possible status of the form, and every possible action that can be performed for each status, such that a business process is mapped; it is this table that defines the form’s workflow or lifecycle.

Example of a simple off-line form routing without approval:

Form type

Status OLD

Action

Status NEW

Version OUT

Mode

E-mail

Notification

AB01

Initial

Submit

Submitted

 

 

 

Note that as there are no approval steps, the final form status is ‘Submitted’.

Example of a simple on-line form routing with approval:

Form type

Status   OLD

Action

Status NEW

Mode

E-mail

Notification

AB01

Initial

Submit

Submitted

On-line

X

AB01

Submitted

Approve

Approved

On-line

 

AB01

Submitted

Reject

Rejected

On-line

X

AB01

Rejected

Submit

Submitted

On-line

X

This example represents an on-line form, with an approval step.  When the form is submitted or rejected, an e-mail notification will be triggered to the next person in the business process.

Example of an on-line form with off-line approval:

Form type

Status   OLD

Action

Status NEW

Mode

E-mail

Notification

AB01

Initial

Submit

Submitted

Off-line

 

AB01

Submitted

Approve

Approved

On-line

 

AB01

Submitted

Reject

Rejected

On-line

X

AB01

Rejected

Submit

Submitted

Off-line

 

Form Owner determination

The Routing user-exit is normally used to determine each new form owner.

There is also a table in which you can derive form owners.  This table can be used in scenarios where the number of users is very low, or when there is no other source of organizational data available to determine who should approve a form.  Its main use might be for workshopping or prototyping a business process without the need to develop code to determine the user. The user derivation table is keyed on form type, status, current owner and action.

Escalations and Reminders

FLM Routing Server

The FLM Routing Server program /flm/wf_engine should be scheduled as a background job and performs two functions: (a) Escalate forms, (b) Send e-mail reminders.  The logic for triggering escalations and reminders considers the factory calendar defined by the customer code, or form type, or factory calendar user-exit.

 

Form Escalations

The form escalation table is keyed on customer, form type and status.  The form escalation job should be run at least once per day.  For form escalation the routing server checks on all forms to check whether they need to be escalated to another user. For any form at any particular status an escalation window (in days/hours/minutes) can be set, plus an escalation action, which will be taken for any form that exists in the status for the escalation window.

The route for the current status + escalation action must be defined in the Routing Table.  If this option is to be hidden from the FLM Action field, then the 'Hide' checkbox should be selected.

The escalation action pushes the form one step along its route, for example, a submitted form could be automatically rejected [or approved] if no approval was granted within 5 days.

The effect of the action is to run the full set of routing logic for the particular form, so several possible updates may be triggered:

  • Change the form owner
  • Change the form status
  • Trigger an offline form
  • Trigger an e-mail notification
  • Trigger a synchronous posting

Reminder E-mails

Normally this would be used in an approval scenario; if the form has been neither approved or rejected then a reminder is sent out.  The functionality is similar to the escalation functionality, since a ‘window’ of days is defined after which a reminder e-mail will be sent out.

If both an escalation window and a reminder window are defined for the same form and same status, then the reminder window will be set to be less than the escalation window.  For example, a submitted for that is waiting approval might trigger a reminder after 2 days, and then be escalated after 4 days.

Email reminders can be automatically sent to the relevant user if the form spends too long at their stage in the form routing. You can set which form statuses have automatic reminders associated with them, the number of days that are allowed to pass before a reminder is sent and whether a reminder will be resent if no action is taken.

This option allows you to create and modify email reminder settings for each form, identified by its customer code and form type. Reminders can be configured according to form status; e.g. different reminder settings can be made depending on whether the form is in initial or rejected status. Links can be made to the desired email title text and body text, and an automatic action should reminders be ignored (e.g. rejection) can be set up.

 

Standard texts for the e-mail subject and e-mail body are also derived from this table, and variable substitution is possible. A FLOE email may be sent as a reminder.

There is also a ‘Resend’ flag, which controls whether several e-mail reminders will be sent out for the same form/status.

The logic behind the selection of the form for a reminder e-mail is as follows:

[1] Is today the last day of the reminder window?

[2] Has the reminder window passed AND is the Resend flag set? 

If the answer to either of these is yes then a reminder e-mail is generated.

For example, if the reminder window was set to be 2 days and the resend flag was not set then the owner would receive a reminder on day 2 only.  However, if the reminder window was set to be 2 days and the resend flag was set, then the owner would receive a reminder on day 2 and on each subsequent day until he/she processed the form, or the form was escalated by FLM Routing Server. 

Variable Substitution in e-mails

SAP standard texts (maintained in transaction SO10, with a name beginning /FLM/, text ID ‘ST’) hold the text for the e-mail title and e-mail body. Variable substitution is allowed inside these texts as follows:

&FORMNAME& Description of form

&SYST-DATUM& Formatted System date

&SYST-UZEIT& Formatted System time

&<variable from syst>& Any variable from table SYST

&<variable from fpe>& Any variable from table /FLM/FPE

&<form field>& Any form field not a repeating subform

You must schedule report RSCONN01 in order to physically dispatch the emails at the frequency you require.

See:

Variable Substitution in Texts and Messages  for details of variable substitution.

FLOE variables for implementating FLOE emails and variables