What is Front Office? Features overview

Front Office is a functionally rich, flexible product. A wide variety of features are available which may be
controlled, enabled, and combined to give a variety of results. This document summarizes the key
features within Front Office and presents them within functional areas. Features are controlled by
license, so please contact info@biomni.com to request an upgrade or find out more information.
This document is intended for use by the project sponsor to inform on available features. The Front
Office Administration Guide contains instructions on the configuration of the required features.

Product Features

Considerable effort has been expended to make Front Office completely and easily configurable
through the user interface. Virtually all configurations can be completed by a non-technical user with no programming knowledge required.

The overall look and feel of Front Office can be changed by amending several display elements via the
configuration area. Service Catalog, Bundle, Request Field Description, Request Field help text, and
Request Forms can be configured from within Front Office using a rich text editor and themed via the
online theme editor.

There are many options for integrating Front Office with other systems, ranging from punching out to
Front Office, linking from an internal dashboard, or at a low level with a specific request form.
The site can be used in single-tenant or multi-tenant mode; the multi-tenant features are controlled via the site license. All features of single-tenant mode are available in multi-tenant mode, with some extra tenant-level features to exploit this experience. When operating in multi-tenant mode, no tenant can see it is aware of, any other tenant. 

This article includes the following Feature Overview:

• Home Page
• Security
• Categories, Suppliers, and Bundles 
• Requests
• Approval
• Internal Request Fulfilment
• Service Level Agreement 
• Receipting
• Data Integration
• Reporting
• Internationalization
• Multi-Tenant Mode

 

Home Page

Screens are split into two parts: the top section, which remains available throughout the system, and
the main content area.

The top section provides a placeholder for the logo, the screens that the user can access (including a
personal outstanding approval count), the logged-in user (name), the cart summary, 'My Account link', Help link and Logout. This section can be overridden with a custom menu and the menu hidden.
The main content area displays the Service Catalog, a user-friendly presentation of available items and services, packaged up appropriately by the organization, to aid user self-discovery. This can be in the form of an ‘App Store’, ‘Top 20’ (for example), or as a standard available services presentation. The catalog can contain both requestable and non-requestable services, as well as information from an external site, presented in a panel. Many theming options are available to ensure the presentation is aligned with the organization's style.

A ‘notice’ area can be utilized to inform end-users of important or interesting information. This is in the form of a ‘news ticker at the top of the page, with the option to drill into further detail or link to another resource.

The About page is displayed as a link at the base of the page, along with the ability to add up to three additional links, which can be named, and links targeted through System Configuration Settings. 

Security

Users

All users with access to Front Office are assigned a user ID and password, to be entered each time they visit the system. Passwords held by Front Office are salted and hashed (SHA-256), ensuring that passwords cannot be compromised even by database administrators who have direct access to the system’s database.

Where Windows and Microsoft Internet Explorer are the chosen client platform, the Windows Authentication protocol can be enabled to avoid the need for users to log into the system, and 
maintain separate passwords. Instead, authorized users will be automatically recognized each time they visit Front Office. Access via Single Sign-On (SSO) is also possible. Active Directory synchronization is available, as well as user import using a CSV file. Front Office also supports Federated Single Sign-On via the WS-Federation Passive Protocol.

A User Group is an administrative tool to allow several users to be easily associated with a range of functionality. A single user may be present in any number of user groups.

Password Policies

Once a user ID has been issued the user will be asked to create a password on the initial login. The password format and length can be enforced, as well as an expiration period (with advance warning) and the number of password histories retained to prevent re-use. The number of retries before account locking is also configurable. A Forgotten Password link on the Home Page allows a one-time use password to be emailed to the user.

Access Control

A variety of ‘access privileges’ are incorporated into Front Office, which controls a user’s access to particular areas of the system, and by extension, what data is presented to the user. These privileges are grouped together to form a set of ‘access profiles’ that can be defined specifically for each implementation, allowing an implementation to be tailored around the business processes of the organization concerned. Each user or group of users is assigned one of these ‘access profiles’. The editing of specific data items within the request type can also be controlled by user role type. For example, this could restrict budget control information to be editable only by financial approvers.

Using Front Office’s workflow facility, a user can submit a requisition for approval and order submission. The requisition will be routed to the appropriate authorized individual, and through any other further approvals, before the purchase order can be placed. The customer’s business rules can be reflected to prevent a single user from raising, approving, ordering, and receipting a product or service.

Communications 

Front Office can be configured to use HTTPS (SSL) to safeguard the transfer of information between the client and server. Additionally, public/private keys can be used to further enhance communications and messaging security between Front Office and third-party systems using X.509 certificates.

Multi-Tenant

If multi-tenant mode is enabled, the additional security challenge of ensuring tenant partitioning is met by an extension in the resource-based security controls, which ensures all published resources can be restricted to either one or more tenants. The option to include intermediate devolved administrative levels is also available. See section Multi-Tenant mode for more detail.

Catalogs, Suppliers & Bundles

The features within this section apply primarily to the item-based request process (i.e., purchasing a product or requesting a service) and not the creation of non-item-related business forms.

Service Catalog

A catalog can be presented to the end-user either via the Service Catalog or by viewing the full catalog, split by the supplier, bundles, and business forms. The Service Catalog has a number of ‘category types’ and can be configured with a combination of all three: App Store, ITIL v3-based presentation of goods and services, and externally sourced HTML panels.

A scrolling carousel can be utilized to display content attractively, with extensive opportunity for use of embedded images. Any number of business-appropriate offerings can be partitioned using the available category types, access to which can all be controlled by the user group.

A service menu allows traditional navigation of the service catalog. The optional service menu can be configured in layout mode by dragging categories to the menu area.

Apps within the App Store are displayed as tiles, which, on selection, might be available for immediate download or back-office fulfillment. Service-led categories allow the user to be offered goods and services in an easy-to-understand and visually appealing manner, using a combination of images, focused navigation links, and service information. Endpoints may be information-based, non-requestable services, or requestable items; i.e., bundles, parts, or business forms. An externally sourced HTML panel allows real-time links to e.g., the user’s open tickets or allows context-appropriate, pre-populated requests to be generated e.g., to restore a VM from a list of available backups. Where the user is only linked to one category, that category will be displayed fully expanded.

The Service Catalog forms the home page of Front Office. A link to the full catalog, controlled by an
access rights can also be displayed on this page.

Suppliers

Front Office supports two types of suppliers: those who are maintained locally by the customer and those whose site is available for PunchOut. Several attributes can be set at the supplier level, including categorization levels, ability to create off-catalog requests, and commodity-type assignments.

Supplier Catalogs

Background catalog maintenance is dependent on the type of supplier: if the supplier is locally maintained, the creation and updates to the catalog must be managed by the customer; if the supplier is defined as PunchOut, no catalog will be held within Front Office: the customer will link out to the supplier site and pull items back into the Front Office cart.

Products can support both short and more detailed descriptions, including an HTML description, and an image to provide information to the browsing user. All products are start and, optionally, end dated; they can be ‘replaced’ by another nominated product. Manufacturer information can be included as well as links to further information; for example, availability or the supplier website.

Skeleton PunchOut products (where only a description is set up) may be created within a PunchOut supplier. These products will be viewable only via the Service Catalog but can be searched upon. It is possible to hide the price for a specified item; for example, where a service cost needs to be calculated. Wherever the item is displayed to the end-user the price will be suppressed. The blank value may be replaced by a short customer-defined message if required. Alternatively, it is possible to hide all prices from a user by use of an access right. In this scenario, all price-related columns and totals will be hidden from display. Volume price rules can be configured which will be applied across all items in the cart.

Approved Lists

It is possible to restrict access to catalogs/catalog items by linking users (via user groups) to an Approved List. A user can belong to many Approved Lists. An Approved List contains a pre-defined list of catalog parts from which the user may select. Approved Lists restrict items available when catalog browsing and viewing bundles.

Browsing

The user can browse all aspects of the catalog from within one view (i.e., Full Catalog): bundles, supplier catalogs, and business forms. If there are many suppliers available, an A-Z filter may be enabled to make viewing by suppliers faster and more manageable.

A quick search facility allows searching across all elements of the catalog.

Bundles

Bundles are a collection of products or services that are grouped together to form logical order units; for example, a Laptop bundle might contain a laptop, a carry case, and an install service with optional items of a keyboard, monitor, and extra memory also available. Hence the user is prompted to purchase a useful set of associated items. Bundles can be configured to contain optional items or a mandatory, non-editable set, as required. It is also possible to create a drop-down box to provide a choice where more than one model is available. Access to an individual bundle may be controlled by the user group so that it is visible only to certain users.

The bundle identity can be held throughout the request process so that once the user has selected any optional items within the bundle and added it to the cart, the components cannot be amended. Alternatively, a bundle may be configured as merely a suggested set of products, where items may be deleted or amended at any stage.

Off Catalog

It is possible to request a product that is not in the catalog, either from an existing supplier or where the supplier is unknown. This would normally be routed through an intermediate stager within approval, either to agree the request or to append extra details.

Whether the user browses the catalog, selects a bundle, or searches for items; they can select the relevant item or bundle to be added to their cart. Several actions are possible from within the cart including deleting items, adding products, and amending quantities. Once the cart contents are correct the request can be generated.

Requests

Requests are highly configurable forms for placing both purchase requests and business transactions.
All the features below affect how the end-user will see and be able to use the request form. Individual requests may be restricted to specified users if required.

There are two types of requests: item requests and business forms. Only the default item request (Miscellaneous Request) is shipped with Front Office. Item requests are used when buying products or services and a PO can be sent to the supplier or for onward fulfillment. Typically, related items are presented in a bundle, sourced from the Service Catalog, and bundles may have their own request form; loose items will use the Miscellaneous Request Type. Item requests are partitioned into a maximum of three sections: header (i.e., overall request level), item, and supplier level. Business forms are created by an organization to reflect their request management requirements and are comprised of a single level.

Form Configuration

The form may be created by using the ‘drag and drop’ design features. Each property, i.e., table, heading, or field can be formatted extensively.

• Field & Field Types
  Some core request fields are available out-of-the-box, but any number of customer-specified fields can also be created. Customer-specified fields can be defined as a number of different types: text box, number, date, time, password, radio button, toggle switch, drop-down list, externally sourced list (single or multi-select), file, hyperlink, asset, email, checkbox, and switch; asset, panels, and externally sourced lists or tree views are complex fields delivering extensive integration possibilities. It is also possible to link to User, Cost Center, Division, or Address lists. Field defaults can be specified at the global level, or at a user level, using one of the many integration hooks, available at many points within the request creation process.
• Rules
  The form rules engine allows field values and request item commodities to affect the inclusion/exclusion of related request fields: a selection within a drop-down list may have another set of fields associated with it, which is hidden until an answer is selected; for example, the initial question might ask the user to specify the type of travel, which would be a drop-down list of: Air, Rail, or Coach. If Air is selected, the fields Flying From, Flying To, Departure Date, Departure Time, Return Date, and Return Time might be displayed. A different set of relevant fields would be available if Rail was selected. Commodity-based rules allow request fields to be included/excluded based on the presence of request items of a given commodity. Rules can be combined with logical operations.
• Field display & roles
  By default, fields are editable but may be set as mandatory, read-only, or hidden, dependent on the role of the editing user. When editing a request, the user is defined as either being the requestor or any one of the defined approval roles. Once submitted for approval, only one user/role can ‘own’ the request at a single point in time.
• Request Update Hooks
  This feature allows data from an external source to be incorporated into the request or validated at selected points throughout the request process, either by updating/resetting field information, or by adding items: on the initial creation of the request, on the update of a specific field value, or at any point through the subsequent pages or when returning to a request. This activity should not be obvious to the requestor: on clicking the navigation buttons through the request, data will be retrieved in the background, validated, and loaded to the request. Additionally, a call can be triggered by a user-activated Update button from within a request page.

Submitting a Request

Once a draft request has been created, the requestor can submit the request for approval immediately,or save the request for later submission.

If approval is required for the request type, on submitting the request all the approval parameters and rules are considered, and a list of relevant approvers is presented to the requestor. The list may be read- nly or partially selectable from a drop-down list. The list is determined by role and represents the order in which the approvers will be contacted, although steps can also be parallel. Once the requestor confirms the selection, the approval process is started, and the first email is issued. At this point, the list of approvers is set, and only in unusual circumstances will the routing change; for example, recalculation of the request approval route due to amended cart contents or manual re-routing required due to unexpected absence.

The approval stage for a request type can be conditionally bypassed if required.

Approval

The Front Office workflow engine, referred to as the Approval module, has an extensive range of rule- ased options which can be used in differing ways by request type. This ensures an organization can control requests for purchase or for activating business processes, tailored in a manner that supports their policies. Email notification is widely used both to update on progress and inform users of actions required by them, which helps to ensure a rapid turnaround of tasks.

Approval Features

All the features below may be used both for item requests and business forms.

• Role Types
  All approval is based on the concept of each user (or assigned group) performing a ‘role’. The three available role types are: staging, approval, and notification. A staging role is assigned if additional or specialist information is required to be added to the request or the requested information needs to be ratified; an approval role is one that explicitly approves or declines the request; a notification role is a reporting-only function.
  • Roles, with the appropriate role type, must be defined to identify each user’s responsibility within the approval process. The name can be used to also describe the capacity in which they are acting, as this information is presented on the email they will receive. There may be many individual roles involved in the approval of a single request.
• Approval Matrix
  The core functionality within approval is the Approval Matrix, which allows conditional rules to be created for a request type.
  • Diverse rules can be created at the following levels: Commodity Type, Division, Cost Center, Value, and Request Field value. Request Field Level Approval supports the use of text, number, and drop- own list request fields to drive the approval process. Specific operators are available, depending on the field type. Users can be named or, more flexibly, assigned a level, which is frequently linked to value bands; for example, a level D user may approve a request to the value of £2,000. User groups, line managers, or ‘Position Codes’ using the organization hierarchy, may also be specified, as well as an integration during request creation.
• Parallel Approval
  Parallel approval allows more than one approval stage to run in parallel. This is useful when different areas of the organization are responsible for different aspects of the request. Using parallel approval ensures approval is not delayed unnecessarily.
• Approval Recalculation
  A role within the approval route may be set to be a recalculation role. This allows the approval route to be reassessed mid-approval, to ensure that any request editing has not materially altered the approval route.
• Product Changes during Approval
  An approval stage can be flagged to check the catalog for the latest product availability and pricing, which ensures an approved request only reflects current information.
• Approval Hooks
  An external system can be designated as an approval stage. The external system can update the request, as well as performing any of the approval roles.
• Reminder and Reporting Escalation
  A reminder period can be set for a matrix row, where the approver will receive a reminder email if they have not approved the request within the designated period. An escalation group can also be nominated, to which outstanding requests will also be reported for follow-up.
• Auto Self Approval
  If the requestor appears as the first approver, it is possible for the stage to be automatically approved and the approval route progressed to the next stage.

Approving a Request

Once the approval process is underway, notification email(s) are sent to each approval stage as appropriate, either as a prompt to inform a user that action is required by them, or merely as a notification where no action is required. Core request information is available within the shipped email, but all approval emails can be configured using XSLT (Extensible Stylesheet Language Transformation) so that the email text is relevant to the organization’s requests and processes. When either a stager or approver is required to complete an action, a security-encoded URL can fast track them directly to the request requiring their attention. Optionally the link can be routed via the login page for additional security.

The approval process is progressed with each stage being approved. Declining or placing a request on hold will halt the progression and a reason must be entered; this will be reported back to the requestor. In the case of a declined request, the requestor may choose to edit the request as appropriate and resubmit or archive the request.
Once approval is complete the request might be automatically completed or submitted for fulfillment; for example, to the supplier or to an external workflow system.

• Substitute Approvers
  When an approver is planning to be out of the office, they can select an alternative user to stand as their substitute, for both approval and task assignment. This ensures that the workflow process continues to move swiftly.
• Workflow Audit
  The actions carried out by a user within the approval process are written to the Audit Trail, an approval-specific extract of which is available as a view within the summary of the request itself. This includes the date, time, and recipient of any emails sent; approval over-ride, and proxy approval when out of office.
• Re-routing Requests & Supervisor over-ride
  The ‘super user’ (aka. Supervisor) can either re-route ‘stuck’ requests to an alternative user/user group or authorize the request themselves. Any such actions are written to the Audit Trail.

Internal Request Fulfilment

Once approved (or past the approval stage if approval is skipped) requests can be fulfilled from within Front Office by defining a workflow, with many different types of activities possible.

Activities can run in sequence, parallel, or as part of a decision branch, and a range of activities are available to give extensive flexibility: Inbox (a manual task with email notification and displayed as an outstanding task list in the application), Email (notification), Adapter (external integration), Windows® PowerShell script, Delay (pause), If, While, and Do While activities, as well as Open / Close SLA. Email templates can be configured via the Admin menu. Progress of running processes can be viewed via the Request Summary and several access rights control both the content displayed and access to that content.

Other options for fulfillment are via a configured workflow solution with an external system.

Service Level Agreement

A Service Level Agreement (SLA) allows the measurement of specified time-based metrics in the lifetime of a request, typically run as part of the Fulfillment Workflow. Elapsed time is measured between defined request activities and nominated users are notified at pre-configured time periods within the request workflow, either as a warning(s) ahead or after expected completion, or as a notification of failure.
An SLA can be run as part of the Request Fulfillment Workflow or via the Front Office (Directa) API.

Email templates can be configured via the Admin menu.

Receipting

An optional step allows a user to manually receipt items from within a request, or nominated suppliers, commodity types, or a specified value can be configured so that the request is auto-receipted post Approval. Return Notes can be created, and asset information captured at the point of receipt. Receipts and Return Notes may be exported to an external system.

Data Integration

Multiple integration points and integration options are available in Front Office. A built-in module allows the integration of reference data information used by or created within the Front Office system, with the customer's back-office systems; for example, Financial or ERP systems. These data transactions (in CSV and Unicode text formats) are supported, either via manual import, or automated file pickup, including:

• Divisions & Cost Centers
• Addresses
• Users & User Groups
• Approval rules & Position Codes

Each file type can also be exported for editing offline or for populating a test system.

Import and export of configuration data is possible, which would typically be used to transfer data between Front Office systems. The following data types can be imported:

• Service Catalog (XML)
• Services (XML)
• Catalogs (CSV & Unicode text)
• Request Types (excluding Approval related data) (XML)
• Bundles (XML)

Many points of system integration, using a series of pre-built adapters, are available; for example, allowing request fields to be updated or validated. Developer documentation for the SDK is also available.

Reporting

Microsoft® Reporting Services delivered reports, via an embedded report viewer page, that can be configured (dependent on license). This powerful report generation tool supports wide-ranging report requirements, rendered in several output formats. Some sample reports are available, and the solution seamlessly supports the addition of customer-specific reports. Access can be controlled via user groups. Initially, three reports are available, although additional reports will be subsequently deployed.

Customers can also create their own reports.

Internationalization

Front Office has several features that assist working within an international arena.

Currency and Exchange Rates

The Biomni solution allows suppliers to publish a single currency catalog and Front Office will present the catalog, and hence request data, in a currency with which the user is familiar. This view is purely for display purposes as the original catalog currency will be sent to the supplier on the purchase order. A full list of currencies is available, and the organization may decide which currencies the user is able to select from. An exchange rate must be maintained for any currency to be used.

Language

Front Office is available in English (US & UK), French, German, Spanish, Portuguese (Portugal and Brazil), Italian, Danish, Finnish, Swedish, Norwegian, Dutch, Hungarian, Chinese (Simplified and Traditional), Korean, Malay, Russian, and Japanese.

Customers can also maintain local translations of the data that they have created; for example, service descriptions, catalog part descriptions, request fields, form names, bundle names, etc., and control which languages to make available within the organization.

Time Zones

Front Office supports accurate date/time capture when working across multiple time zones. This can be used when the database server is in a different location to the user base or when users are spread across many locations. Users may select a specific time zone to reflect their location when traveling.

Multi-Tenant Mode

If the site license permits, Front Office can be viewed in multi-tenant mode, with each tenant protected from other tenants’ data.

The Front Office Multi-Tenant solution allows a Service Provider to publish services and requests to users within multiple end-tenants, within a single Front Office application. Service catalogs and request forms can be tailored for individual tenants, with no impact on other tenants using the same system. When operating under the multi-tenant mode, in addition to Division and Cost Center, Front Office provides the additional organizational structure of Tenant. Users assigned to tenants are restricted from viewing any content not published to them or created by them. A tenant will not have any visibility, or even be aware, of any other tenants set up within the same Front Office multi-tenant system.

Service Provider users have a supervisory view over the system and can view all tenant-related data. When configuring the Service Catalog or viewing the catalog as an end-user, the Service Provider user can choose to view it as a nominated user.

Tenants are created via a single-entry point and are associated to a single division. Multiple users, cost centers, and addresses can be defined. There is a single Service Catalog across the solution but a tenant’s view of it can be adjusted in several ways. The request form that a tenant creates can also be varied, using the Request Type Variant feature. Key aspects of the tenant’s theme, including banner heading, logos, and site colors, can be edited.

Nominated tenant users can also be granted tenant-level administrative access to their organization’s user and address information, which is presented in a novice-friendly way. Ongoing tenant-specific administration can therefore be delegated to nominated users within a tenant organization.