FLM Object Model


Customer Code

The customer code identifies the FLM forms globally in the system.  It contains system-wide settings that are applicable for all form processes. There should only be one customer code defined in any SAP client. 

The settings that can be controlled based on the customer code are:

Customer Details

Default Customer

FLM can manage multiple customers for system design only.  At runtime only 1 customer code can be the default. Typically customer installations of FLM have only one customer code and this is set to default.

Master Language

The master language defines which language the form data schema must initially be defined in.   All other languages at the same version will then share the same data schema, which cannot be altered.

The master language also determines the template used for the ABAP user-exits, and also the language of various drop-downs in the system.

Once the language is set and a form defined, this should not be changed.

Solution Manager Active

Check this box if SAP Solution Manager is active in your landscape. This sole effect of this to stop the FLM Form Wizard from generating its own transports.

In this case you must use Solution Manager to generate the transports, and then pick these up manually in the Form Transport Wizard run.

If you wish the Form Transport Wizard to pick up the correct transports automatically, the request headers (workbench and customizing) must be given the Attribute 'SAPCOMPONENT' with the value 'FLM:Cust = XXX , Form = YYYY', where XXX is your 3-letter FLM customer code and YYYY is your 4-letter FLM Form Type Code.

Default Factory Calendar

FLM uses the Factory Calendar to calculate intervals for sending out reminders.  Here you maintain the global factory calendar, but you can also assign the calendar at the form level if required.  In addition there is a user exit for calculating the calendar to use programmatically if required.


Render Engine Settings

Activate HDS Trace

This flag controls the HTML Document Services (HDS) trace function; set the flag if you wish the system to record trace information whilst rendering HTML forms.  This can be very useful for debugging form issues.   The system only records the trace of the most recently rendered HTML form.

The trace can be viewed in the IMG Activity 'HDS Render Trace' in the FLM -> Tools IMG menu.

Note: Do not activate this in productive systems if possible, as it reduces system performance.

ADS Trace Level

Sets the level of tracing information recorded by ADS during form rendering.  At the highest level ADS generates certain attachments inside each PDF which can be used for troubleshooting purposes.  Never leave this set high in a productive system as it considerably slows down the processing of forms and increases the size of the database.

Metadata On

If ticked, FLM installs some metadata into every generated PDf that can be read through the Adobe Reader menu /file/properties.



Authorisation Object

Here you maintain the name of the SAP authorization object upon which you wish to base all of your FLM Profiles. This object is set up as part of the FLM installation.

Usergroup Functionality Active

This switch enables you to use standard SAP usergroups for group access to forms.

Usergroups are maintained and assigned to users in transaction SUGR.

If this scenario is enabled then forms are routed to either individual users or to single usergroups.  If forms are assigned to individual users then they are still only available to that one user in the FLM Inbox.  If they are assigned to usergroups then anyone in that usergroup can process those forms.

You must also switch on 'Group Access to Forms' for every form type if you wish to use this scenario, as it is a global setting.  You can do this under the FLM IMG activity 'Form Types Configuration'.

If you have also maintained a remote system for your FLM user management under the FLM IMG activity 'System specific settings', then the user groups are read from the remote system and not the local one.

Perform an auth check on every FPE record in Foreground mode

If this flag is checked, when the "Forms Posting Engine" is run in "Foreground Mode" an authorization check will be performed on every form before the available list of forms is displayed. Forms which fail the authorization will be excluded from the list. By default, in order to improve performance, no authorization check is performed before the list is displayed. If a specific form is selected to be posted or viewed however, an authorization check on that form will be performed.


FLM Portal Settings

No Logo Section

If this checkbox is marked the FLM logo within the FLM Portal is removed.

No Logout Button

If this checkbox is marked, the logout button from the FLM Portal is removed.   These last two settings are typically used only when the FLM Portal is embedded within the SAP Enterprise Portal.


Offline Settings

Encryption Key

The encryption key is used in the case of reminder emails. If, in an online scenario, a user for example fails to approve a form within a given time frame, a reminder email will be sent out containing a URL link to the form. For security reasons, this URL is encrypted according to the encryption key entered with each customer code. The encryption key can be any 14-letter combination that does not include the same letter twice.

File Type

In the offline scenario Forms can be returned to FLM as either PDF format (entire form) or Data-Only Format. PDF format contains both the form data and signatures/attachment/annotations and so the file attachment size can be very large. Data-Only format sends only the form field information contained within the form, which means that the size of the attachment can be minimized.

Default Sender Email Address

Enter the email address of this FLM system, as defined by your local SMTP server.  This is where, in the offline scenario, forms will be returned to.

This can be overridden System Specific Settings.

Offline User

Whenever a form is sent offline to a user (that is, by email) then FLM assigns this user as the 'Form Owner' as we no longer have a real SAP named user as the form owner.  FLM also uses this field when running certain programs in order to pass the built-in FLM authorization checks.  This user should generally not be a dialog user and should be given sufficient FLM authorisations to process all forms.

Rejection texts

When an off-line e-mail is received back into the FLM system it may have certain fields validated before it is received fully into the system. If the form fails validation, an e-mail may also be sent back to the sender to explain why it could not be received.  The content of that email is derived from these two text objects, one for the title and one for the body text.

Text Object for Formatting Portal Exit Page

This text object is used to create the HTML exit page from the new FLM MultiUI portal.  This text should be edited as HTML.

This text should be created in transaction SO10 with a 'Text ID' of 'ST'.  The text's language will be determined at runtime from the default language of the logged in user.  If the text in this language is not available, then the FLM master language will be substituted.

This portal exit page will be sent when a user launches a form from a URL hyperlink and then completes the form submission process.

It is optional to specify this text object.  If you do not specify a text object here, a standard object will be used.

If you do specify a text object here, you may use any form field in the text in the same way as for Notification texts; in addition, the special symbol & URL& contains the portal exit URL as specified in FLM customizing (in 'System Specific Settings').


<body bgcolor="#F6F6FA">

Your form has been submitted with form ID &ID&

Please either close the tab or click the Exit button.

Click <a href="http://& URL&">here</a> to exit.


HR Admin


Form Category

A Form Category is a logical grouping of Form Types that is used as a part of the user authorisation concept in FLM. You must define your form categories before you can begin creating logical forms via the FLM Form Wizard, as each form must be assigned to a form category.

The groupings shown in the demo below are examples of typical form categories: ‘Purchasing’ ‘Human Resources’ and ‘Accounting’.

To create a new form category, go to ‘New Entries’ and define a  form category code with an associated description for each form category required. Form Category codes are only applicable for the customer code within which they are defined.

Form Status

Form statuses refer to the logical stage of the form routing. Each status must be assigned a 'status category' of either Initial, Intermediate or Final depending on where in the routing the status will occur. Each Customer code must have only one Initial Status defined, but you can have multiple final statuses.  For example:

  • "Initial" might be an initial status; defined as the status at the start of the routing in which the form instance is created.
  • "Submitted" might be an intermediate status because the form has already been initiated in a previous stage of the routing but may still not be ready for posting until approved. All intermediate statuses have routing stages both before and after them.
  • "Approved" might be a final status because all information required has been gathered and validated and the information is ready to be posed into SAP. In a final status, the form is at the end of its routing.
Status names and codes are completely configurable according to your routing requirements.  There are a few statuses that are reserved by the system:- 'D' and 'L'.

As of 295sp2 the status category of 'All Statuses' is deprecated.  It was previously provided to reduce the number of configuration entries that were necessary but is no longer supported.

Any form that reaches one of the final status is referred to as 'terminated'.
Note: If you add a new status and you wish to include the status in an existing form process, click the 'propagate new status' button after you have saved your new entry.  This status will then be available in the form routing and template look-and-feel transactions.

Form Action

Form Actions list the options available to select the next position in the form routing, e.g. submit, approve, post etc. You can enter a new action by using ‘new entries’ and entering a customer code, action code and description for each new action. Actions C, D , G, L, Y and Z pre-defined and reserved by the system.  These cannot be reassigned. All other letters of the alphabet are available to assign to different stages of a workflow as you wish. The action descriptions are only suggestions and are completely customisable.

Action codes that are reserved by the system: 'C', 'D', 'G', 'L', 'Y' and 'Z'.

‘C’ is used on the check cycle to re-render the form.

‘L’ and ‘D’ are the actions available for forms at initial status, for Cancel/Delete and Save as Draft respectively.

‘Y’ and ‘Z’ are the actions available in the Dashboard for changing the Status and Owner.

'G' - is not longer used.

Form Type

A form type is a 4-character code that defines the form process.  New form types are created using the Form Wizard.

Several customizing options can be controlled by form type on the intial screen:

Form Category

The form category is a grouping of form types used for navigation in the FLM Portal and used for authorisation checking.

Default Form Type

By indicating that the form type is the default form type, this will pre-fill various FLM navigation and configuration screens at design-time with that form type.

This accelerates the FLM configuration process.  Only one form type can be identified as the default.

Form Name

This is the name of the form that will appear in FLM Portal.


Setup Form Options

Additional fields can be customized using the "Setup Form Options" button.

Form Block

This control will stop a form from being available through FLM Portal.

Read Only

This control will ensure that the form is rendered as an output form instead of an interactive form.

Number Range

This control links a form type to a particular number range, defined in number range object /FLM/nnn, where nnn is the FLM Customer Code.

Transport Mechanism

This control defines the possible transport mechanisms for the start of a new form process.

Offline Return via Submit

This checkbox controls whether offline forms will submit data back to FLM by e-mail or by an 'http/https submit' submission to the delivered FLM Business Server Page application.

Group Access

This controls whether each owner of the form type must be an SAP user, or whether other grouping objects are permitted.

Factory Calendar

A factory calendar can be set for a particular form type.  This is used when determining dates for the purpose of escalations and reminders. This field over-rides the setting on the customer code.

Return File Type

This setting controls whether the entire PDF is returned or just the form data when an offline form is submitted to FLM by e-mail.