Tenjin Icon


This article covers the following topics:

If the request needs approval prior to fulfillment or closure, an extensive variety of rules and options can be designed, which should allow an organization’s approval workflow process to be mapped and automated within the approval setup. Approvers can be allocated based on the requester’s business unit/cost center, contained commodities, or any field value. Where authorized users raise requests on behalf of others, approval routing can be determined on the Requested For user. Support for out-of- office (substitute approvers), organizational position hierarchies (e.g., route to line manager), and integration to user account directories ensure streamlined rule management and effective approval of all requests.

Note: a significantly more complex rules-based matrix evaluation is available (‘Advanced Approval Rules’) but this is primarily used in a legacy manner by long-running customers. The default Approval Matrix option should be adequate for even the most complex business scenarios. Please contact the support team via the Community at https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information.

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. When a request is submitted for approval, all matrix records are evaluated, and the matching records retrieved, and specific users or groups assigned. This filtered and updated list becomes the approval route for the specific instance of the request. Each record is known as an Approval Stage. Whenever a stage becomes active, a check is made to verify if the user an ‘out of office’ record applicable for today; if so, the substitute approver is swapped in instead of the original.

If the Remove Duplicate Approval Stages system setting is enabled, at point of the approval route being calculated at request submission, the approval route is calculated as normal. Next, the derived list is reviewed and if two or more consecutive stages are resolved to the same user, an assessment is made to determine which single stage to retain. The stage that is retained is the first approver, or, if no approvers are found, the first stager, or, finally, if no stagers are found, the first notifier. If there is more than one stage with the same stage type, e.g., multiple approvers, the priority is determined as follows, (1) being most important:

  1. Sequenc
  2. Role ID (alphabetical)
  3. Stage type (approver, stager, or notifier)
  4. List box number
  5. Default or advanced matrix

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.

Approval task notifications (either for those required to take action or for information only) are included in a set of approval-related emails which can be configured using XSLT (Extensible Stylesheet Language Transformation) so that the text in the emails is relevant to the customer’s requests and processes. In addition to the notification email, a full list of outstanding approval tasks is available via the Inbox menu > Approvals list.

The Approval Matrix can be created via the user interface or imported using a CSV or Unicode text file

A detailed guide to assist configuration of the approval process is available. Please contact the support team at https://frontofficehelp.biomni.com/hc/en-us/requests/new for further information.

System Configuration Settings:

  • Exclude Requested By/For from Approval List
  • Route user via login page on clicking hyperlink
  • Allow comments when approving
  • Display Approval Submit picklists by last name
  • Remove Duplicate approval stages
  • “From” Mail address
  • Allow Advanced approval rules

*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 Matrix *

The information contained with the Approval Matrix defines the approvers who are required for specific request types. When a request is submitted for Approval, the system references the matrix to determine the approvers needed to approve the request. The Approval Matrix can include Group,
Parallel, Position Code, Request Field and Approval Hook processing. The matrix is processed by searching for ALL matching rules to derive a list of approvers required to authorize the request. Using this type of matrix makes for easier understanding and repair if a stage is missing.

Configuring the Approval Matrix *

Approval Matrix records can be configured from within the Request Type (Approvals tab) screens or via the generic Matrix available at the top-level Administration home page. High volume changes can also be edited via CSV or Unicode text file import.

Core Settings

  • Request Type
    An Approval Matrix must be assigned to a Request Type.
  • Role
    The selected request type determines the contents of the Role picklist, as defined in the Request Type>Roles tab. The role is used to define the actions that the approver(s) is allowed/required to perform whilst authorizing a request. A meaningful name should be used, to assist the Requester and the Approver. Select from the available list or create a new role via the Request Type/ Roles tab.
  • Stage Type
    Defines the access level of the approval stage:
    • Approval - must approve or decline a request; can also add additional information to the request if required
    • Stager – reviews or edits specific information in the request; does not have the authority to approve or decline the request
    • Notification – receives an email as notification only; no action is required
  • Stage Sequence
    Selecting the stage type displays the Stage Sequence number, which determines where this record appears within the resolved approval route. This ensures the request passes through the approval process in an appropriate order.
  • Assigned Approver
    The assigned approver picklist lists the options for the type of resolver.
  • Approval Level
    Specify an approval level to enable users associated with this level to authorize the request. Approval levels should be alphabetical (A-Z), with A being the highest level.
    Related topics: 
  • Specific User/User Group
    Select a user if a specific user is to authorize the request. Select a user group for more flexibility: all members of the group will receive an approval email and any user can approve as appropriate.
    Alternatively, you can select the user who raised the request (Requested By) or the user for whom the request has been raised (Requested For).
    Related topics:
  • User from Field / User Group from Field
    Using User from Field or User Group from Field allows a request header field to be entered, of type List box, External List box (but not tree view), Text Box or Radio; and specifically for User from Field, type User List. This request field would be updated during request creation, either by the request creator or by an external system, and on request submission for approval, the entered value will be used as the assigned approver for that approval stage.
    Note: if using External List Box, the field must be configured in single selection mode.
  • Line Manager via User
    A user’s Line Manager can be specified against the user’s details (either via User Maintenance or Import Users facility) and at request submission stage, the Requested For user’s manager assigned the approval stage. This allows a simple, easy-to-maintain approval process.

    If using Position Codes, the following options can be used:

  • Approval Level via Position
    By selecting the Approval Level and Via Position checkbox, the approval route calculation process will locate the position code of the user on whose behalf the request is placed and ascend the organizational hierarchy from this point. The first position code reached, where the user has been allocated the required approval level or higher, will be chosen as the approver of the request.
  • Line Manager via Position
    By enabling the Line Manager checkbox, the approval route calculation process will locate the Position Code of the user for whom the request is placed and then ascend the organizational hierarchy to the user’s line manager. The line manager will be the sole approver of the request.
    Note: if a position is vacant the process will continue to search up the tree until a filled position is located; the user associated with that position will be the approver for the request.
  • Position Code
    A specific position may be selected, and the associated user included in the approval route calculation process. If the specified position code is vacant, the organizational hierarchy will be ascended until the next filled position code is reached and the request will be assigned to the associated user.
    Related topics: Approval Position Codes
  • Approval Hook
    An Approval Hook allows a link out to an external system, which may approve or decline a request, add items, and update field information on the request, or which may merely be passed the request details for notification purposes. It may be selected as a matrix action from a list of active Hooks set up via the Adapter area. An Approval Hook can work alongside standard approval matrix rows set up in Front Office.
    Note: if communication with the external system fails for a request, a supervisor may approve or decline the approval stage via the Approvals List.
  • Request Value
    By default, the Any Request Value checkbox is enabled, which means that the matrix record will be applied, regardless of the value of the request. If specific value bands are required, uncheck the box and Minimum and Maximum request values can be entered.

More Settings

  • Approve in Parallel
    By default, the approval route operates in a series of sequential stages: each approval stage must be complete before the next stage is activated. If you wish for more than one stage in the matrix to be started simultaneously (i.e., in parallel), then each relevant matrix record should be checked. The parallel group will consist of consecutive parallel records; a ‘sequential’ (i.e., nonparallel) record will end the grouping. An approval flow can have several groups of matrix rows set to parallel approval.
    Note: it is inadvisable to use Approval Recalculation in association with Parallel approval.
  • Approval Recalculation
    If the approval route needs to be verified during the approval process, perhaps for example the model/price of the requested items is amended or a cost center is changed, enable the ‘Recalculate’ checkbox. The comparison of the current route and the new route checks that the number of stages, the Role ID, and the resolved user type (e.g., user group for both current and new) are all unchanged. Also, the designated user is still valid. Where multiple users are potential approvers (i.e., a drop-down list), a check will ensure that the current user can still be an approver in the new route; if so, that user is retained. If any of the above does not match, the route is designated as changed and the approver will be presented with the recalculated list of approvers; the current approver needs to accept the page. If no differences to the approval route are determined, then the approval process carries on uninterrupted, transparent to the ‘recalculating’ approver. If the approver verifies the recalculation, the approval route is reset, and the approval process restarted. An audit record is created to denote the recalculation and the original approval route effectively ‘archived’ for support purposes only.
  • Remove Expired Products and Update Pricing
    If only the most up-to-date catalog data can be submitted, enable the ‘Remove Expired Products’ and/or ‘Update Pricing’ checkboxes. Prior to an approver with these options enabled being presented with the request, the catalog will have been checked for updates and the request changed accordingly, i.e., items deleted, end-dated products removed and prices amended. The approver is informed of the details of the changes (and a tooltip specifying the affected products displayed) and given the choice to proceed (i.e., approve the request), or ignore the changes (i.e., decline the request). Assuming the approver has the rights to edit the contents of the request, as per the role rights, they will be advised to replace removed products, if required. Any changes applied take effect prior to approval recalculation logic being called. If the item is marked as ‘price editable’ then no price changes will be assessed; PunchOut products will also be excluded. This check cannot be implemented for notification role types or for Approval Hooks matrix rows. If the request is declined, no changes are applied. An audit record reflects the changes made.
  • Skip stage if no approvers found
    This feature allows a matrix row to be skipped if there is no user or approval hook available. If all stages for the request type are skipped in this manner, no approval will be required, and an appropriate audit comment logged. It also needs the "Request Requires Approval" field (found on the Approval list) to be set to either "Yes" or "Only if approvers found". If "Request Requires Approval" is set to "Yes", at least one approver must be found for the request; if set to "Only if approvers found", then the whole approval stage may be bypassed if all stages are optional and approvers are not found. If the matrix row is flagged as optional for an Approval Level, and no Approval Level user can be found, the stage will be skipped rather than be set to the Cost Center Owner. Dormant or Deactivated Users will be skipped. Deactivated adapters or adapters of the wrong type will also be skipped. If the ‘optional’ stage resolves to an invalid user, then the request will error, regardless.

Matching Criteria

  • Fields
    Request fields can be used to determine whether a matrix is matched to a request. Any number of text, number, list box, or radio button request fields may be specified including the same field with many matching values, with the option to match ‘any’ or ‘all’ fields. A value must be entered against field selected, with the choice of the following operators, dependent on field type:
    • Text: equals, contains, or does not contain
    • Number: equals, not equals, less than or greater than
    • List box: equals or not equals
    • Radio button: equals or not equals
    • External List box: equals, contains, or does not contain
      Note: Tree view fields are not supported.
      Related topics: Creating a new request field
  • Commodity Type, Division, Cost Center selection criteria
    A Commodity Type, Division and/or Cost Center can be used to determine whether a matrix is matched to a request using the specific filter. No selection results in all records being included. Related topics:
  • Reminders & Escalation
    Approval Reminder and Escalation periods can be set, using the specified number of days, hours or minutes after the original approval email was sent to the approver; ‘Business Time’, as configured at system level, will be applied to the calculation. Both fields are optional but if completed, can trigger a reminder email only, an escalation email only or both.
  • Reminder Email
    An email reminder is sent to an approver who has yet to action an approval request.
  • Escalation
    An email is sent to an ‘escalation’ user group when a stage has been open beyond a designated period. The email includes details of the assigned approver or group, with group members listed. The Escalation Group is specified against the Request Type or, if a global value is acceptable, as a System Configuration setting).
    The main body of both emails contains the same request level information as the original approval
    emails. The emails can be configured using XSLT (Extensible Stylesheet Language Transformation).
    System Configuration Settings: Default Approval Escalation User Group
    Related topics:
  • Grouping & Sequence
    Lastly, sequencing can optionally be set:
    • List box Number
      If it is required that more than one approver should approve a certain criterion of request, then a Listbox Number should be specified. The List-box Number defines whether Approval is required from any of the people (across matching matrix records) or all of them. If any single user can approve, then the List-box Numbers should be the same across all records and those approvers will appear in a drop-down list from which the submitter can select the desired user. If the List box Numbers are different for otherwise matching records, multiple approval stages will be created.
    • Priority within List box
      If there is a certain preference required for the order in which the approvers appear in the list-box, this can also be specified using this numeric value (1 = first in the list)

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

Editing an Approval Matrix *

Approval matrix lines can be edited to change the criteria either via CSV or Unicode text file import or via the user interface.

Approval Level for Users *

Approval Levels that exist within the Approval Matrix must be associated with one or more Approvers
so that when the matrix matches a line that incorporates a level, it can then reference the cost center
of the request (via the Requested For user) and locate the relevant level of user who is specifically
associated to that cost center for this purpose. If it cannot find an exact match, it will look for any
appropriate users of a higher Approval Level.

A user is assigned a level within User Maintenance > Settings tab. The list of available Approval Levels
reflects what has been created in the Approval Matrix.

Related topics:

Auto Self Approval * 

Once the approval route has been calculated on request submission, this feature allows the first
approval stage of the request to be automatically approved if the Requested By user is included in that
first stage.

System Configuration Settings: Allow Auto Self-Approval

Cost Center Approvers *

When using Approval Levels within the Approval Matrix (independent of Position Code resolution), you
will need to associate the users who can be approvers with the Cost Centers. Cost Center approvers are
maintained via a CSV or Unicode text file import.

Related topic: Data Import

Approval Position Codes *

Your organizational hierarchy can be represented within the system using Position Codes. Each Position Code is unique and is used to classify the relative position of a user within your organizational hierarchy. Position codes can be utilized in the approval process to route approval to:

  • A specific employee identified by a position code
  • A line manager (without having to identify the user id or position of that line manager)
  • An employee of specific level of authority where that employee is determined from the organizational hierarchy OR the designated cost center approvers.

Every user within the system is required to have a position code assigned, with the relevant hierarchical
code stipulated. The hierarchy is usually stable, with only the users potentially moving as career progression / organizational changes require. Position Codes can only be created via a CSV or Unicode
text file import.

A dummy position code to sit above the top user (e.g., CEO) in an organization is required to be specified in a system configuration setting; an additional setting specifies the user ID of the approver of requests raised by the top user.

System Configuration Settings:

  • Resolve Request Approver(s) via Position Codes
  • Highest Position Code User ID
  • Highest User’s Parent Position Code 

Related topics:



Share this article



Article is closed for comments.