Tenjin Icon

Request Type*

This article covers the following topics:

Request Types are designed to enable the capture of the information necessary for you to fulfill a user’s request for services. Request Types can contain line items either from a pre-determined bundle/group of items or individual items selected by the user from the available catalogs, although this setting must be specified on the initial creation of the form. Designing a request type enables you to:

  • Ensure that the right information is gathered on the request form within fields created from a wide range of field types.
  • Control how these fields are displayed to the user using form sections and column layouts, as well as many other options to present a visually pleasing form.
  • Determine approval routing dependent on who is raising the request and the contents of the request
  • Determining workflow options for fulfillment and configuring rules for internal fulfillment
  • Setting Service Level Agreement measurements
  • Control who can see and/or edit parts of the requests throughout its lifecycle

Any number of request types can be designed, created, and linked to actionable services, dependent on your license.

The baked-in Miscellaneous Request type is the default system form used when ad-hoc items are selected directly from the Catalog. This form can be amended by adding, removing, and filtering the Request Fields that appear within the form. This form is currently a legacy form.

Front Office request types are defined as either having request Items or not. Item request types can be associated to one or more bundles. Request types with no Items are referred to as business forms and are made up of a Header form and optional, Confirm form.

Any Item request type is comprised of up to four forms, each containing a configured set of fields: Header, Supplier, Item and Confirm. The Header form is always displayed, the Supplier form is hidden automatically where not required, and the Item and Confirm forms can be optionally configured as hidden.

Some Item request types can also be automatically displayed with only a Header form. This occurs where only a single item is being requested and there are no supplier or item request fields configured. In this scenario the description of the item being requested is displayed in the space normally used to show the request form title.

A request type can also be categorized as “sensitive” if access to a completed request needs to be controlled.

Access to specific request types can be controlled by utilizing User Groups.

Many elements of the request type can be imported to or exported from another Front Office system. Data includes Request Type Details, Request Fields, Rules, Role permissions, Fulfillment, SLA, and Request List Columns. The Approval Matrix is a separate import process, which must take place after the initial Request Type import. Ensure all the required approval roles have been created prior to the Approval Matrix import. Any associated Adapters or Bundles (for Item Requests) must exist prior to the import or the association with be ignored as part of the import: a warning will be shown first. A Request Type is imported as ‘deactivated’.

Several system configuration settings are related to the end-user requesting process and the display of the Request Summary:

System Configuration Settings:

  • Empty Cart on Log on
  • Populate ‘Requested For’ field with ‘Created By’ user’s name
  • Refresh defaulted fields when Request For user is changed
  • Display the Supplier page before the Item page
  • Only allow one Supplier per order
  • Give Request Number more prominence in the Request area
  • Allow Request Summary to be emailed
  • Display Request Price on Request Summary
  • View Requested For user’s catalog
  • Warn Before Clearing Cart on New Request

Related Topics:

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Creating a Request Form *

A request form provides a list of request fields for satisfying an associated specific bundle of products and/or services. They can also reflect internal business use and non-catalog-related services.

Select Request Type > Add from within the Request & Approval Category.

Each request type is given a unique code, a name and a description. Enter the required information against the main details of the new request type. If this request type is flagged to ‘include items’, i.e., to be linked to one or more bundles, you are then able to link to existing or create new bundles from within the Bundle tab (‘include items’ must be flagged prior to first save and cannot be subsequently changed). A flag on the Bundle tab allows a restriction to be set, so that for any of the bundles associated with the request type, only a single instance and single quantity of the bundle may be present in the cart. This allow the form and fulfillment configuration to be simpler. A checkbox controls whether the end-user can copy an existing request from within the Request List. Another checkbox determines whether the ‘Requested For’ field can be associated with a request. This would typically be used when the request must only be used by the logged-in user.

A checkbox determines whether a request type is deemed sensitive and hence access to the created request should be restricted. If checked, only the Requested By and Requested For users will see the request in the Request List or Inbox. Additionally, any user named in the approval route can perform a Request List advanced search, and by selecting themselves in the Approved By or Currently Being Approved By fields, to view the request. No other user, either one with administrative rights or a user with view all requests access right, can view the request. Additionally, individual request fields can be marked as “encrypt in database”, which allows the data to be encrypted at rest.

Note(s):

  1.  (user) group approval is not recommended when using sensitive requests, as only the approving individual user will be able to access the request once that approval stage is completed.
  2. It is important to edit notification email XSLT so that sensitive content is hidden, otherwise, the full detail will be accessible in the Email section in the Admin menu.
  3. A ‘sensitive’ flag is included in all request-related API data, so the receiving system can be adjusted, as appropriate.

A checkbox controls whether a Closure ‘milestone’ will be created. This stage is activated once the request, approval or fulfillment milestones have completed, whichever is last. The process and content
of the page are populated using a DAPI call.

Information on Legacy Forms can be found at the end of this section. Legacy form functionality can be enabled via a system setting.

Integration via Request Update hook functionality can be configured to run at a number of points: on request creation, on change of ‘Requested For’ user, as a requester switches between each level of the request form, when the requester moves to the approval page, when a user initiates a call via the Update button or each time the request is loaded post initial creation. Others event milestones are on start of the overall approval process, on specific stage start and on approval completion.

Note: when creating a copy of the request, ‘Requested For’ hook is not fired. Auto population of the form with specific user-related data is achieved via the ‘on request creation hook’.

Continue to work through the tabs to build the fields that will appear on the request form when presented to the user and the format in which these fields are displayed within sections and columns; the rules for roles, i.e., which fields are mandatory, hidden, or read-only, at each role stage throughout the request workflow; the approval resolution rules and the fields that are seen on the Request List-display as column headings.

Additional usage statistics can be captured against a request type and referenced in reports, in the form of a monthly estimated volume sheet to allow tracking of estimated versus actual demand for a specific request type. A specific report is required to access this information; please contact the support team at  https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information. 

Individual Request Types can be copied. The details copied are the same as for Request Type Import / Export: Request Details (excluding hook settings), Request Fields, Rules, Roles and permissions, Fulfillment, SLA, Request List columns; local language data is also included. The associated bundle for an Item Request Type must be manually configured post copy, as well as Approval Matrix. A copied request type is set to ‘deactivated’.

Note: The system setting (Allow ad hoc Items mixed with Bundle-associated Request Types) allows/disallows ad-hoc items being added into the cart with a bundle that is associated to a specific request form type.

System Configuration Settings:

  • Allow Advanced Layout options in the Request
  • Allow Request Attachment
  • Maximum File Attachment Size (Kb)
  • Maximum Image Upload Size (Kb)
  • Commodity Type Resolution
  • Default Off Catalog Request Commodity Type
  • Auto Generated Order Number – Length / Prefix
  • Order Label auto set to Order Number
  • Order No Auto Generate when
  • Order No Generation Method
  • Supplier PO Number Generation method
  • Enable Legacy Forms functionality

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Designing a Form*

A request type is entirely independent from any other request type, removing any of the Legacy Form limitations of shared request fields and non-editable system fields. This decoupling also removes the need for a Request Field library.

All elements of a request type form can be copied into a clipboard, which is displayed in the Toolbox. Pasting is achieved by dragging it from the clipboard onto the design area. The clipboard contents are maintained until Request Type Maintenance is exited, allowing tables and fields to be copied from one request type to another.

If using the site in ‘multi-language’ mode, a language picker at the top of the page allows all data to be switched to the relevant language. If no translated data exists, fields will be displayed in the base language.

The shipped ‘Miscellaneous’ request, the default for cart-related requests, is available as a Legacy Form, as field filtering by commodity, supplier or item, is not yet available. Only Legacy Forms can currently be sent to ConnectaTM or Supplier Gateway. Both ConnectaTM and Supplier Gateway are now depriciated.

Creating a form layout

A form is created by dragging a table, heading or field from the toolbox and dropping it onto the design area. A single column form can be created simply by just dragging the relevant field on, however using tables should be considered where side-by-side field layout is required or conditional rules are needed to display the fields: if all the relevant fields are encapsulated within a table, the rule definition, as well as formatting, is much simpler. Once in the design area, all elements can be moved by dragging to the desired location; this includes moving items in and out of tables.

Dragging an element from the toolbox automatically opens the property window at the base of the page. The property window contains three tabs: Visual, Configuration and Help, defaulted to the ‘Visual’ tab. The auto-open process can be suppressed at any time; this will persist until the property window is manually re-opened.

The Visual tab contains many formatting options, including:

  • Position of label (alignment)
  • • Width of label (in relation to available row space)
  • • Width of control/height (data entry box; certain field types only)
  • • Top/bottom margin settings

Tables and headings additionally support:

  • Drop shadow
    • Border radius
    • Border color
    • Background color

The Configuration tab covers:

  • Field Code
    This is auto-generated but editable; field codes are unique within request location, i.e., header, supplier, or item, but the same code can be used across locations, and in different request types. A field code can be amended by entering a brief label, which is particularly useful for easy identification of tables or headings when configuring Rules & Roles. If a field code is amended once established, all related rule, approval or workflow associations will be updated also. 
  • Field length (certain fields only)
  • Default value (certain fields only)
  • Adapter configuration
  • Ability to encrypt field data at rest in database

The Help tab supports rich text Help, displayed adjacent to the field to assist the requester.

If one or more bundles are associated to the request form, fields can be added at either item or supplier level by selecting from the location drop-list at the top of the page.

A toggle to full-screen mode is available for the design area, via an icon at the top right of the page. This can be useful when viewing the impact of a form.

Request fields are grouped into three general categories:

Standard Fields:

  • Checkbox
  • Toggle switch
  • Single Line Text Box
  • Multi-line text box
  • Number
    An allowed minimum and/or maximum range can be specified including the maximum number of decimal places.
  • Email
    A text box that includes a simple formatting check to validate for either a single email address or list of email addresses.
  • Hyperlink
    The field can be presented as a read-only clickable link, using a Default value and standard field protection via ‘Roles’ tab, or as a requester-entered value. Basic hyperlink validation is carried out; relative URIs are supported so a website address should be prefixed as ‘https://’ or ‘http://’. Once selected in a request, the site is displayed in a separate window.
  • File
    Maximum file size is stipulated as a System Configuration Setting; attachments of the following file extensions are not permitted: VBS, WSF, EXE, COM, BAT, BAS, SYS, DLL, HTM, HTML and MHT.
  • Date
    The default value is not set as an absolute value but in relation to Today’s date, e.g., four days after today: +4; four days ago: -4; today: 0. If only business days to be included: append ‘w’ e.g., +4w.
  • Time
  • Radio button
    Useful where there is only a short list of options; an existing field can easily be swapped to list box mode. The Import function offers pre-defined values for rapid configuration; these can be edited once selected. Alternatively, the Import pane allows copy/paste from a spreadsheet and allows quick manual entry of multiple values. The Import function is currently only for base language values.
  • List Box
    Useful where there is a longer list of options; an existing field can easily be swapped to radio button mode. A System Configuration Setting determines how many items must be in the list before a popup picker, with quick search option, is presented, rather than a drop-list. The Import function offers pre-defined values for rapid configuration; these can be edited once selected. Alternatively, the Import pane allows copy/paste from a spreadsheet and allows quick manual entry or editing of multiple values. An Advanced checkbox on the base language Import page displays XML for all languages.
  • Password
    This field is for use when interfacing with an external site. The field value is stored in the database encrypted and will not be displayed on the request summary. It is passed out in the API encrypted and there is a separate method to manage encryption/decryption.
    The field value is never written to the audit or other logs and is cleared from the database on request moving to status ‘complete’.

Section

  • Heading
    Includes a rich text editor panel, allowing extensive display options. When editing the heading display in the property window, the panel can be expanded to full screen via a toggle facility.

1, 2, 3 or 4 column tables provide several presentation styles and allow ease of formatting, as well as rapid management of rules and roles. Tables can be multi-row.

  • 1 column table
  • 2 column table
  • 3 column table
  • 4 column table

Advanced fields

  • Requested For
    A shipped (‘system’) field which can only be used once within a request form. This field is available for use on any form.
  • Request Number
    A shipped (‘system’) field which can only be used once within a request form. This field is available for use on any form.
  • Request Label
    A shipped (‘system’) field which can only be used once within a request form. This field is available for use on any form.
  • Division List
    Displays all Divisions
  • Cost Center List
    Displays all active cost centers
  • Approval Cost Center
    A shipped (‘system’) field which can only be used once within a request form. This field allows the update of the cost center which can be utilized as an approval matrix parameter.
  • User List
    Displays all active users.
  • Address List
    Displays both Delivery and Invoice pre-configured addresses
  • Asset
    An asset field retrieves assets from a source external to Front Office, using an Adapter. The assets retrieved are typically laptops, desktops, servers, mobile phones etc. The field will automatically select the asset if only one is returned, rather than displaying the search and selection screens. First configure the External System in Admin > Settings > External System, then link it to the request field. Configure the following options as appropriate to the adapter: - Filter By User: determines whether the User ID of the Requested For user should be sent to the external system. Filter 1/Filter 2: string data sent out to the external system. Usage depends upon individual implementation. Maximum Asset Selections: used as part of request validation to control the number of assets selected.
  • External List box
    An external list box retrieves data from a source external to Front Office, using an adapter. Any number of text and image columns can be displayed, depending upon the implementation of the adapter.
    • First configure the adapter in Admin > Settings > Adapter, then link it to the request field. Configure the following options as appropriate to the adapter: - Parameters: text data sent to the external system; usage depends upon the individual implementation.
    • Multi-Select: determines whether multiple items can be selected from the data.
      Once these have been set the field can be saved. This will contact the external system and return the definition of the columns that will be displayed in the external list box, as well as the features that are enabled. The potential features available are Paging, Searching and User Filtering (i.e., one or more drop-lists for user selection).
    • Note 1: if Multi-select, Paging, Searching or User Filtering are enabled, the data will be displayed in the request as a pop-up, otherwise, it will display in a list box.
    • Note 2: additional data is sent to the external system so that localized data can be returned, or other data specific to the current user, and specific to the location of the field in the request, e.g., for a specific supplier, item or bundle. An information message may also be returned. Where a pop-up box is displayed, request field help text is also shown here, as well as on the form, allowing the requester easier access to help relating to the pop-up.
  • Tree View
    A ‘tree view’ control is based on the same principles as an external list box, with a different display. It retrieves data from a source external to Front Office, using an adapter. Any tree depth can be supported, depending upon the implementation of the adapter.
    • First configure the adapter in Admin > Settings > Adapter, then link it to the request field. Configure the following options as appropriate to the adapter: -
      Parameters: text data sent to the external system; usage depends upon the individual implementation.
    • Multi-Select: determines whether multiple items can be selected from the data.
      Cascade Selection: controls whether the selection of a particular node automatically selects every element below.
    • Popup Width (pixels): allows the default width of the tree view selector popup box to be
      controlled, as per the known data to be returned.
      Once these have been set the field can be saved. This will contact the external system and return the definition of the columns that will be displayed in the external list box.
      User details, including culture, are sent to the adapter, allowing user-targeted information to be returned, including localized data, as well as the location of the field in the request, e.g., for a specific supplier, item, or bundle. Images, referencing either relative or absolute URLs, may be specified in the adapter. An information message may also be returned.
      Request field help text is also shown on the pop-up box, allowing the requester easier access to help relating to the pop-up.
  • Panel
    Like the Panel category type in the Service catalog, a panel field can be used to insert real-time HTML content from an external source, such as a report or website page, into the request. When this feature is used for request form completion purposes, it is advised that the field is hidden for the request summary, otherwise, real-time information will be used, which may be misleading or inappropriate.
  • Cart
    Displays the contents of the cart (items) associated with the request. This displays best in a single-column layout.
  • Approval
    Displays the approval routing associated with the request. This displays best in a single-column layout. It is recommended that this section is hidden for the ‘read-only’ role (i.e., viewing the Request Summary) and approval roles, as the information will also be available as a separate milestone. Note: this may change subject to how approval is configured to vary with request contents.

When trying to delete a request field, it will not be allowed if used in approval or workflow, with the message informing of specifics. If the field is used in a rule, a warning will be displayed, indicating that the whole rule will be deleted if the deletion is completed.

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Rules *

By default, all fields configured will be included/displayed on the request. Creating a rule allows a field to be conditionally included/excluded or shown/hidden. ‘Include’ / ‘exclude’ determines whether the nominated field it will form part of the request or not; this option should be used by default.
Exceptionally, where, for example, a back-end process updates a field that is not relevant/appropriate to the end-user, ‘show’ / ‘hide’ can be used. However, on raising a request form, if the field value has already been set and the user edits the form to invoke a change of condition which results in that field no longer being relevant, the previously entered field value will not be reset.

Display rules can be created for checkbox, toggle, radio button or list box field types, i.e., rules are evaluated when values of these field types change. Available comparators are ‘is/is not’.

For Item request types, rules can also be based on the commodities of the items present. For the Item level form an ‘is/is not’ comparator is available for the specific Item associated with the form. For all other form types (Header, Supplier, Confirm), commodity rules are evaluated based on the presence of any Item with the stated commodity.

Multiple conditions can be joined by either AND or OR, but not both. Selecting the ‘action’ field is achieved via a picker, which presents the form: tables, headings or fields can be selected/deselected by clicking on the cell. The selected ‘condition’ is displayed with a green-bordered hatched selection in the form picker and any ‘actions’ with a blue-bordered hatched selection.

Rules can be set at table, heading or field level. Where tables are used, all descendants will also be affected by the rule. The request displayed to the requester will be adjusted to compensate for any conditional exclusions.

Tip: Once all rules have been added, it is helpful to re-sequence them to follow a logical order. This helps review and problem diagnosis.

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Roles *

Roles are used to determine what users can see and do at different stages of the request lifecycle, i.e., creation, approval, fulfillment tasks and viewing the Request Summary. A role must be created with a minimum of (role name and role type. The list of all available roles can be selected from within the Approval Matrix or Fulfillment tabs.

Within this tab, request editing permissions can also be associated, i.e., which fields on the request type are mandatory, hidden, or read-only at each role step. This allows the view for users with different responsibilities to be controlled, e.g., when the request is raised the Requester may be required to complete certain mandatory information but when the request is submitted to the first approver, those fields may be read-only for that approver although there may be additional fields that the approver needs to complete that were hidden to the Requester. Similarly, certain fields may be inappropriate for all users to view. The whole Supplier, Item, and Confirm forms can also be shown/hidden for specific roles.

Two non-editable roles are available out of the box: the Requester role, which will always be used for request creation and editing prior to submission, and Request Summary – Read-Only, which is used to control which request fields are displayed on the Request Summary, when accessing from the Request List. This is also the default role assigned when creating Inbox Tasks within Fulfillment. Request Field visibility, as defined in the relevant Approval or Inbox Task role, is also applied to the Request Summary when that assigned user is accessing the request via the Inbox or notification email.

Adding and managing a Role

A new role can be created by clicking the buttons Edit Roles > New. Here only a role name is set, along with two flags: the ability to edit items and edit price in the cart.

Once created, each role can have field-level permissions of mandatory, hidden, and read-only set as required. Tables are also available for quick selection; if a table is specified, any heading or request field contained within it will have the same permissions applied (this is not available for Legacy Forms).

A role is required when creating an approval matrix stage and an Internal Fulfillment Task.

Note: Roles do not determine the access profile of a user within other areas of the system. These roles are only applicable to the action required/permitted during the approval and fulfillment process.

A role may be deleted which is not linked to the approval matrix or internal fulfillment. This deletion will archive the role so it can be used when accessing historical requests. This role ID cannot be used again.

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Approval *

Once the requester submits the request, the approval process, if configured, will be activated. A request can be set to never require approval, always require approval, or conditionally require approval, depending on the rules defined in the individual matrix records.

Where approval is a simple process, the option to create approval records in the background but not require the requester to click through the page is available. If the approval route needs attention, e.g., a picklist is generated as part of the route, the approval page will always be displayed for the requester to action.

An escalation group can also be specified; this allows approval stages awaiting action for more than the time specified in the matrix record to be emailed with the details.

See the Approval article for further information.

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Fulfillment *

There are three types of fulfillment available via this tab: ConnectaTM  (now deprecated)and External Workflow, which are described in the Adapter section, and Internal Fulfillment, which is described below. Internal fulfillment allows for a process to be defined that will be executed after the request has completed approval. This process can involve user interaction or integration with other systems. A process consists of several activities that will be executed dependent on the structure of the process. You drag and drop activities on the design surface to add new activities or to re-position existing activities.

The activities below are available.

Sequence

A sequence activity executes all its children in order one after the other. It waits for each activity to complete before starting the next one. The activity does not complete until the last child activity has completed. The initial workflow process is a sequence activity.

Parallel

A parallel activity starts to execute all its children at the same time. The activity does not complete until all its children have completed.

Flowchart

6.1.6.3 Flowchart
A ‘Flowchart’ activity allows for more complex orchestration models to be embedded within a Front Office fulfillment process. Made up of standard action activity types, the flowchart activity removes the need for flow control activities and follows a traditional flowchart execution path.

If

An ‘if’ activity provides the ability to decide which of its possible two children is run dependent on a set of conditions. If the request matches the conditions specified then any child in the “Then” branch of the activity will be run, otherwise any child in the “Else” branch of the activity will be run. If multiple conditions are added to the activity, the configurator decides whether the result should be dependent on any or all of the conditions passing. The ‘If’ activity completes when the relevant child activity has completed.

While

A ‘While’ activity runs its children repeatedly while the request matches the condition specified. If the request does not match the condition when the activity starts, no children will run. If multiple conditions are added to the activity, the configurator decides whether the result should be dependent on any or all of the conditions passing. The ‘While’ activity completes when the condition is met.

Do While

A ‘Do While’ activity runs its children repeatedly while the request matches the condition specified. If the request does not match the condition when the activity starts, the children will be run once. If multiple conditions are added to the activity, the configurator decides whether the result should be dependent on any or all the conditions passing. The ‘Do While’ activity completes when the condition is met.

Delay

A delay activity waits for the time specified and then completes.

Inbox

An inbox activity provides the ability to create an Inbox Task that requires user action. An inbox activity requires a specified User, User Group, ‘Requested By’ user, ‘Requested For’ user or User from a nominated request field, to carry out the task, along with a Role. The role determines what Request fields are visible and whether the user can (or indeed must) edit the request. Also specified is the allowed duration of the task, entered in days, hours or minutes and calculated using the system level configured ‘Business Time’.

Alternatively, the activity can be assigned at run time, by referencing a specific request field (code), which can be a user list, list box, external list box, text, or email field. The requester completes the designated field on request creation and the value is used when determining the fulfillment route.

When the activity runs the required user or group is emailed the Action as well as the Instructions, who must then complete the task using the Inbox Task list. The action and instructions fields support template properties and XSLTs that will be replaced at run time (see Template). An inbox activity completes when the inbox task that is created is completed or cancelled.

Email

An email activity provides the ability to email one or more recipient’s information about a request; recipients supported are User, User Group, ‘Requested By’ user, ‘Requested For’ user, ‘user from field’ or email address(s). The subject and message fields support template properties and XSLTs that will be replaced at run time (see Template). An email activity completes as soon as the email has been queued for sending.

Web Service

A web service activity provides the ability to call a web service on a remote system to enable system integration. The web service call is a Request Fulfillment message. If “Wait for response” is not checked, a web service activity completes as soon as the web service call has been made successfully. If “Wait for response” is checked a web service activity will wait until the Front Office (Directa) API has received a CompleteRequestFulfilmentActivity message for this activity.

PowerShell

A PowerShell activity will allow a specified Windows PowerShell script to be executed directly from Front Office. An account and password, with the appropriate rights, must be specified under which it will run. If “Wait for response” is not checked, the PowerShell activity completes as soon as the script has started. If “Wait for response” is checked, a PowerShell activity will wait until the Front Office (Directa) API has received a CompleteRequestFulfilmentActivity message for this activity.

Open SLA

An open SLA activity provides the ability to open an SLA defined against this Request Type. The SLA is specified by name, and if the SLA is already open the activity will do nothing. An Open SLA activity completes as soon as the attempt to open the SLA has completed.

Close SLA

A close SLA activity provides the ability to close an open SLA defined against this Request Type. The SLA is specified by name. If the SLA is already closed the activity will do nothing. A Close SLA activity completes as soon as the attempt to close the SLA has completed.

SLA

A Service Level Agreement (SLA) allows measurement of key time-based metrics in the lifetime of a request. An SLA has a duration entered in days, hours, or minutes, calculated using the system level configured ‘Business Time’, and can optionally notify one or more recipients (a single user, a user group, or an email address) if the SLA fails to complete within this specified duration. The subject and message fields support template properties and XSLTs that will be replaced at run time (see Template).

All SLAs associated with the Request Type will be created along with the Request. Initially they will all be pending. An SLA can be opened and closed either via the Internal Fulfillment process or via calls to the Front Office (Directa) API, i.e., via approval hook functionality during the approval process. All measurements are relative to the date and time the SLA is opened. If the SLA has not been closed after the specified duration it will automatically move to ‘Failed’, however if it closes before the duration specified it will move to ‘Passed’.

Additional notifications can also be created for an SLA. These notifications have a duration period of days, hours or minutes, calculated using the system level configured ‘Business Time, and will fire while the SLA is open either before or after SLA failure. These notifications can notify one or more recipients (a single user, user group or email address) of impending (or past) failure and can also optionally set the SLA to a ‘Warn’ status to show it is likely to fail soon.

Related topics: Business Time

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Request List *

A ‘Restrict Visibility’ checkbox allows orchestration-style requests to be hidden from the Request List. This works in conjunction with the access right View Restricted Requests.

Column Configuration – Request List display

It is possible to configure the columns that will be displayed in the Request List for the Request Type. Within the Request List tab, a list of available fields may be selected and an option to specify the display sequence is available; the available list is restricted to only those field types that are viable. If no columns are selected within this area, a set of 10 columns will by default be displayed in the Request List.

Searching Request Fields on the Request List

It is possible to set request fields as searchable on the Request List Advanced Search. Within the Request List tab, a list of available fields may be selected for searching; these include supplier and item fields, in addition to header fields. The following field types are not available: separator, hyperlink, file attachment and asset fields. This feature is available for Legacy Forms only.

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Custom JavaScript

This allows the creation of custom JavaScript specifically for the selected Request Type. Field values for all request field types are accessible via the JavaScript API. This custom JavaScript is outputted to the page after the global custom JavaScript.

Creating a Legacy Form*

Enabling Legacy form support is via a system setting and a checkbox in the Request Type Details tab. Legacy forms can be used where:

  • Request fields are required to be filtered dependent on catalog items, i.e., using a supplier, commodity code or item filter
  • Request Field defaulting dependent on the requesting user is required, and the request update hook functionality is not appropriate

System Configuration Settings: Enable Legacy Forms Functionality

*Feature not fully available to unlicensed customers. Please email info@biomni.com to find out more information or to enquire about upgrading your license.

Creating a New Request Field ** Legacy Forms Only **

Within the Fields tab, select Create Field to add a new field to your Request Form or use Link Field associate previously created fields to this request type. Listed below are all available field types. Configuration supports a rich text ‘Help’ field displayed as a tooltip to the end-user and, for most field types, a ‘Default’ field value to be pre-populated, which can be overridden at user level. ‘Short Name’ is used as a Request List column and depending on field type, a field length must be specified. ‘Export’ defaults to enabled but can be unset if the field should not be available outside of the system, e.g., request hooks, workflow or ConnectaTM  (Depreciated).‘Category’ helps to organize fields when configuring and make them easier to retrieve. The ‘Associated With’ link adjacent to the ‘Request Field Code’ lists any Request Types with which the field is associated.

  • Address List
    Displays both ‘Delivery’ and ‘Invoice’ addresses. Requester-editable addresses are only supported via the Delivery Address system field.
  • Check Box
  • Cost Center List
    Displays all active cost centers.
  • Date
    The default value is not set as an absolute value but in relation to Today’s date, e.g., four days after today: +4; four days ago: -4; today: 0. If only business days to be included: append ‘w’, e.g., +4w.
  • Division List
    Displays all Divisions.
  • Email
    A text box but includes a simple formatting check: must include @ sign and at least one full stop within the domain name area.
  • File
    Maximum file size is stipulated as a System Configuration Setting; attachments of the following file extensions are not permitted: VBS, WSF, EXE, COM, BAT, BAS, SYS, DLL, HTM, HTML and MHT.
  • Hyperlink
    The default hyperlink can be presented with a friendly name using the ‘Hyperlink Text’ field. Once selected, the hyperlinked site appears in a separate window.
  • List Box
    A System Configuration Setting determines how many items must be in the list before a popup picker, with quick search option, is presented, rather than a drop-list. List box items can be re- equenced. List box items can be entered via the UI or imported in the Data Import facility, using a CSV or Unicode text file.
  • Number
  • Separator Text
    A non-textual separator bar is displayed in the request unless Default text is entered. Alternatively, separator sections can be created as part of ‘Advance Form’ configuration.
  • Text Box
    Depending on the field length entered, the field will display as a multi-line entry box. Specifying the ‘Number of Rows’ allows control of the display.
  • Time
  • User List
    Displays all active users.

More complex field types are Asset and External List box:

  • Asset
    An asset field retrieves assets from a source external to Front Office, using an Adapter. The assets retrieved are typically laptops, desktops, servers, mobile phones etc. First configure the External System in Admin > Settings > External System, then link it to the request field. Configure the following options as appropriate to the adapter: -
    Filter By User: determines whether the User ID of the Requested For user should be sent to the external system.
    Allow Fast Select: if set, the field will automatically select the asset if only one is returned, rather than displaying the search and selection screens, e.g., if Filter By User is selected and the user only has one computer.
    Filter 1/Filter 2: string data sent out to the external system. Usage depends upon individual implementation.
    Maximum Asset Selections: used as part of request validation to control the number of assets selected.
    • External List box
    An external list box retrieves data from a source external to Front Office, using an adapter. Any number of text and image columns can be displayed, depending upon the implementation of the adapter.
    First configure the adapter in Admin > Settings > Adapter, then link it to the request field. Configure the following options as appropriate to the adapter: - Parameters: text data sent to the external system; usage depends upon the individual implementation.
    Multi-Select: determines whether multiple items can be selected from the data. Once these have been set the field can be saved. This will contact the external system and return the definition of the columns that will be displayed in the external list box, as well as the features that are enabled. The potential features available are Paging, Searching, and User Filtering (i.e., one or more drop-lists for user selection).
    Note 1: if Multi-select, Paging, Searching or User Filtering are enabled, the data will be displayed in the request as a pop-up, otherwise, it will display in a list box.
    Note 2: additional data is sent to the external system so that localized data can be returned, or other data specific to the current user, and specific to the location of the field in the request, e.g., for a specific supplier, item, or, bundle.

Once fields are created, they can be used across multiple request types if required. The full available Request Fields list is available directly from the Administration home page.

Each field type will prompt entry of the relevant information. Once created or associated, the Form tab can be used to control the display of the fields to users based on sections and column layouts. Advanced

Note 1: If Advanced Form is active (as per the checkbox at the top of the tab) then every field associated with the request must be selected within the advanced form definition or it will not be seen by users. 

Note 2: It is more efficient to create new Request Fields from within the Request Type, as the new field is automatically associated with the Request Type.

Selecting a Shipped (system) Field

Several shipped request fields are available. These include ‘Requested For’ user, Cost Center, Request Number, Request Label, Delivery address (including support for requester-editable address), Invoice Address, Request Value, Required By date and Request Notes. The Request Field Name may be edited, and a default specified but otherwise, the properties are fixed. Only one instance of a system field can be associated with a specific request type.

Request Field Dependencies

Dependent fields ensure only relevant subsequent fields are displayed, depending on the selection made in the parent field. Dependent fields can only be assigned to a parent field that is a list box type.

  • E.g., a field labeled ‘Type of Travel’ has a choice of ‘Rail’ and ‘Air’. By selecting ‘Rail’ fields such as Departure Station, Arrival Station and Departure Time will be displayed. However, if ‘Air’ is selected the fields will relate to ‘Departure Airport’, ‘Destination Airport’ etc.

Request Nested Dependent fields can be set up with many levels in a tree-type structure.

Note: Ensure all the relevant fields are available prior to creating the dependencies. Each field that is used as a dependent field cannot be used again at any other dependency level so all dependent field trees should be created from the ‘top down’.

Adding a Dependent Field to a Higher-Level Field

Select the ‘Add’ link in the Dependent Fields column of the higher-level field required. Select the Parent value to be configured. Select the required dependent (or child) fields by checking the box against the field name and then clicking on the ‘add’ link at the top of the check box column (the added fields then move to the top section of the screen). Once dependencies are added they can be re-sequenced using the drag and drop icon against each field. Defaults can also be added or edited if required. Continue to add dependencies for each of the list box descriptions as required until complete.

To continue building your nested dependent field structure repeat the above process by selecting the ‘Add’ link beside each of the fields that require further dependent fields below them.

Note: There are no restrictions in the depth of the dependent fields’ tree.

Filtering Request Fields

It is possible for certain fields to appear within a request according to the type of product being purchased, e.g., when ordering IT equipment, certain IT fields may be relevant which would not be for a stationery purchase.

Fields can be filtered on criteria dependent upon the level of the request that the fields appear:

  • Header level – commodity type filter
  • Supplier level – supplier or commodity type filter
  • Item level – commodity type, supplier, or item number filter.

Select the Fields tab within Request Type Maintenance and then select the Add link which appears in the Commodity Type/Supplier or Item filter column of the field to be filtered. Select whether this field is to be ‘included’ or ‘excluded’ when any of the specified commodity types/supplier or items form part of the request raised:

  • Include = ANY field present
  • Exclude = ALL fields present

Add the commodity types/supplier or items from the list by checking the associated box(es) and clicking on the Add link at the top of the check box column. The selected items will now be moved in the top of the screen.

Any commodity type, suppliers or catalog items required as filters must be created prior to carrying out the filter set up within the Request type.

Advanced Form ** Legacy Forms Only **

Within any request type you can activate an ‘Advanced Form’ option which enhances the presentation to user’s raising a request: this provides one or two-column layout, sectional formatting, and color themed display. The Advanced Form tab is visible when the system setting is enabled. The Advanced Form can be designed and then activated for specific requests.

Note: Any requests using the Advanced Form option that are passed to Connecta™ will sequence the fields as they appear in the request within a single column format; the two-column layout is not passed to, or displayed in, Connecta™.

Configuring an Advanced Form

The advanced form functionality allows the arrangement of fields into a single or two-column format section. Each request type can contain many sections of differing formats.

Using the Edit link within each section you can assign a Title (and determine if a title is displayed) and Description bar which can be color-coded using a standard set of colors provided. These colors can be overwritten using the style sheets; please contact the support team at  https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information.

It is also possible to insert sections within sections, although this is only suitable for short label/short response fields, as the layout for lower resolution browsers, may be adversely impacted.

Adding a Section

One section is provided within the Advanced Form tab to get you started. To add further sections, click the Add Section button.

A new section is added in a single column layout; to edit the section layout select the Edit link within the section. To add a section within an existing section, select the Add (request field) link and click the Add Section link, displayed at the top right corner of the popup.

Note: Help is provided (?) against the Title bar and Description to assist you

Re-Sequencing Sections

To re-sequence, a Section select the cube with an arrow icon and drag and drop the section from and to the desired
position. Top-level Sections only can be re-sequenced. A section within a section cannot be re-sequenced.

Adding Fields to Sections

Within the appropriate section, select the Add link where you want the field to appear. Select the field to be added within this section; care should be taken to insert the field in the correct position. Continue to add fields as required within your sections. All fields required to be displayed must be included in the layout.

Note: Separator Fields, if associated within the Advanced Form, will be displayed as ‘read-only field’ on the request. Text box type fields will change to a Text Area if above 50 characters in length and associated within a two-column layout; the number of rows displayed can be controlled within request field set up.

Adding Rows to Sections

Rows can be added above or below existing rows within sections at any time using the table + icon.

Deleting Sections and Fields

Sections can be deleted, and request fields removed by selecting the trash can icon to the right of the Section Title bar or the field.

Share this article

Related articles

Comments

0 comments

Article is closed for comments.