FLM Form Wizard

The Wizard is used to define the logical definition of a new business process, including the field names and field types.

The Wizard performs 6 tasks:

  1. Creates the data schema
  2. Creates the blank templates as required XDP and/or HTML files and saves to the local machine, for Stelo apps this step is managed by the additional Stelo Wizard
  3. Configures FLM configuration tables for the definition
  4. Reserves a class for the process business logic
  5. Generates user-exit methods for the assigned class
  6. Generates a customising request and a workbench request and reserves them for the new process  


On the welcome page, click ‘Continue’ to begin creating your form

Choose Form/App Code

Form/App type code

Invent a form/app type code here. This is a 4-digit code for a form type, which must start with an alpha character and may not contain special characters). The the first two letters can be used to define the application area while the second two can denote the function. For example, a sales order form may have the code SAOR. It is a good idea to decide and agree on a universal naming system so that each code accurately describes the application area and function. This will be helpful, for example when managing routings.


One of the features of FLM is the support of concurrent form versions. So it is possible to create a form/app with the same function and 4-character code, but with a different version number. This facilitates forms management, because the 4-digit character code can be fixed for a specified form type and application, and does not need to be altered with successive versions of the schema.  Use this field to enter the version number of the form. The first form/app always has a version of 00.

Template Option

Each form must be generated in the master template option before a copy can be made in another language. Once a form has been designed in the master template option though, any language can be selected for a successive version of the form. Note that in a new language version, the data designer cannot be edited and is a read-only version of that created for the master template option form.

Form/App Description

Enter a description of the form/app to easily identify it in the list.

Design Form/App Data

Launch the Data Designer


Begin the new schema creation by creating a Subform. This is a logical or physical grouping of fields that defines their characteristics on the form/app. The schema can support the concept of a header/items relationship I.e. a row of fields may be repeated according to how many times it is required. For example, on a sales order, where multiple items are to be ordered, the item number, description and quantity field may be included in a repeating row for each  number of discrete items to be ordered.

Some fields, for example ‘name’ and ‘address’ of a customer,  should appear only once on the form. MaxOccurs allows you to set the maximum number of times a subform field may occur . Following the same example, it would be advisable to set Header fields as MaxOccurs: 1, and Item fields (repeating) as Maxoccurs: 10. Once the fields have been generated, they can then be assigned to the relevant subform group to maximize the functionality of the fields according to requirements .

Note the ROOT subform which is created and must be retained as the default subform, with a MaxOccurs of 0.

Where a similar subform exists on another form/app schema, the Copy Fields and Subforms menu on the right can be used to select and copy Subforms and associated fields.


To create a field, begin by entering the field name in the ‘Field Detail’ section of the page. The Field Type can be assigned as character, numeric, date etc. The field can then be assigned to one of the subforms you have created under ‘Parent’. Please note that the field name must consist of alphanumeric characters only; underscores are allowed but spaces are not. Though the field names should resemble their content, they need not be the label of the field as it will appear on the form. Labels can be added in the Field Caption and where necessary extended later on the UI template.

Field Detail

Enter the Field Name, the Field Type and the Subform that is the logical 'parent' node for the field. The Access option will be the default behaviour at EVERY status and must be updated at ANY status that should behave differently. Most business processes modelled within FLM have an imitator, who needs the access to be Open, and several approvers who do not update data and need non-interactive access. You can choose to set all fields in the wizard to Non-Interactive and set only the fields that need to be completed as open for status Initial (and Rejected) using Subform and Field control. Alternatively you can set fields as Open in the wizard and set them as Non-Interactive for all other statuses (excluding Initial and Rejected). If more than 2 non-interactive statuses exist then use the first approach.

The 'hold' checkbox is for use at design-time only, and stops the refresh of the data when the Add button is selected. This makes data entry quicker where common attributes are shared across many fields.

Read Routines

Read Routines will apply to the field in any reading instance of the form.

A Prepopulation Routine will cause the field to be prepopulated and could be used, for example, for the Form ID field.

An F4 Values Routine limits the field input to options selected from a drop-down menu. This could be used in the case of there being a limited number of field options to select from, such as Country of Residence.

A Sticky dropdown will retain the values populated into it at the first render throughout its routing. From FLM300 sticky dropdowns will be refreshed when opening from draft.

If the Sticky function is not enabled, the form will re-render using live data at a later stage of the routing, which may mean that an approver may not have access to the same dropdown data as the initiator who accessed the form, say, a couple of days previously. If live data is always required, DO NOT enable a sticky dropdown. From FLM300 for performance reasons the sticky option will be set by default for new fields so if live data is always required you must DISABLE the option.

When sticky is enabled all the possible selections are retained even after a final status has been reached. From FLM300 a call to class method /FLM/USER=>CONDENSE_STICKY_DD can be made within the routing user exit or posting adaptors. This call will check which entries are in use across the life of the active ID and clear down the previously retained values not used.

Post Routines

Post routines apply to the transfer of data back into SAP via the Posting Engine.

  • A Derivation Routine allows the data on the form/app to be used create a new field before the data is input to SAP.
  • A Validation Routine checks the data in the field for validity before the form/app can be submitted. For example, a user-entered code might be checked against the codes in the database to see whether it is in fact valid.
  • A Substitution Routine substitutes the data input to the field for another value. For example, an item option featured as full text in the form might be substituted for an item code as the data is input to SAP.

Field Catalogue

To edit or cut a field after it has been entered, first select the action you wish to perform (e.g. update field), then select its row in the Field Name table. Re-click on the desired action to make changes.

Once all the fields have been entered, click on ‘Return to FLM Form Wizard’ and proceed to the next step.

Specify File Locations

The form data definitions you have just created can be stored as an XML and/or HTML file during the generation of the FLM interface. Here you can specify the location in which to store the files. You must store it to an accessible location such that it required it can be imported into the relevant editor. Click ‘Set Directory’ and select a new location if the one displayed is not suitable. Note that subdirectories are created to store any XDP/XSD and  HTML templates separately.


Alternate Template

For non Stelo developments you can choose to use:

  • the FLM master template, which is uploaded on install
  • a user-specified template, selected as an .xdp/.html file from your local machine
  • a previously uploaded template (for example, if you are using the wizard to modify a schema after the template has been configured and re-uploaded into the system)

If the Inject Schema box is checked, the .XDP will have the binding already created when the form template is opened in Adobe Livecycle Designer.

The Generate HTML Template will generate the HTML template if required.


 Choose Options

Transport Options

With Offline Transport the form can be sent via email as an attachment.

With Online Transport the form is available via the online form portal.

Runtime Options

‘No attachments’ will disenable the ability for form users to add attachments to the form.

Blocking the form will prevent it from appearing in the portal, useful if you would like to prevent others from accessing it in a development environment before it is ready.

Form Category

Here, select the form category under which you would like the form to be stored. You can use different form categories to control user access to forms in the portal, or just to provide logical groupings of forms with a similar function or target area. 

Security Level

One of 4 security levels can be selected:

Open: any user with a 'Display' activity (for this form type)  may view the form.

- Restricted: Users with the 'Administrator' activity, the form initiator and the current form owner may view all 'restricted' forms.  This is the default setting.

- Confidential: Users may only view forms they are the owner of and forms that they started.

- Private: Forms can only be viewed by their owner.

Allocate Schema Definition to Transports

The wizard will now create and propose a customizing request and a workbench request.


You can now click on ‘complete’ to generate your schema and configuration, or ‘back’ to make any amendments. On clicking ‘complete’ the relevant components of the schema will automatically be saved in the system.

Once the wizard has been closed, you can still make amendments by initiating the wizard for the same form/app code and version.

During the completion process, several warning and questions are presented. These confirm if existing templates should be overwritten.