• Version 2020.1.3.355
  • Download 17
  • File Size 1.86 MB
  • Create Date May 29, 2020



Regardless of the job, everyone needs a short break to regenerate and eat a tasty meal. As many studies indicate, this allows the employees to return to their duties with doubled force, minimize the number of mistakes they make and improve results.

On the other hand, order management requires a certain amount of time and organizational skills. Finding a group of people willing to order food together, and then keeping them informed about the status of their delivery are some problems people might encounter when organizing meals in a larger group.

The WEBCON BPS system allows you to control any workflow including those indirectly related to the office work. To efficiently order meals, you can prepare a simple Lunchtime application.

The application consists of one main process and three dictionary processes:

  • Lunchtime – the main process allows to create new orders and manage a new set of orders
  • [LT] Food Suppliers – a dictionary that stores a list of suppliers
  • [LT] Menu Items – a dictionary that stores the items available in the given supplier’s menu
  • [LT] Places of Delivery – a dictionary that stores the possible delivery locations

Two roles can distinguished within the application:

  • Person collecting orders – a person responsible for starting the new “Lunchtime” process and placing an order with a supplier outside the system. In addition, they have the possibility of completing the dictionaries with missing suppliers, menu items and delivery locations. In the “Lunchtime” application this person is saved in the “Registrant” field.
  • Purchaser – a person placing an order. They are informed about the start of the process and its next stages by e-mail notifications.

Application page

The application page consists of two dashboards:

  • Lunchtime
  • Lunchtime administration

The “Lunchtime” dashboard is intended for starting the new instances. Additionally, it contains the “Orders” report related to the ordering process.

Fig. 1. The main page of the application


The report gives the ability to switch between the available views:

  • Current – the current orders in the intermediate steps
  • My orders – all “Lunchtime” instances in which the user has participated
  • All – all “Lunchtime” instances

The second dashboard is used to manage the dictionaries. It contains a report dedicated to each of them, divided into “Active” and “Inactive” views.

Fig. 2. The Lunchtime administration


The dictionaries reports allow you to export the values from one environment (e.g. test) and then, import them to another (e.g. production).

By using the GUID as a key connecting the “Food Suppliers” and “Menu items” instances, the dictionaries will not lose their relationship even after importing them. From this level there is the ability of creating new values in the “Food Suppliers” and “Places of Delivery” dictionaries by using the “New” button.


Within the “Lunchtime” process there is a workflow with the same name. Below is a diagram of the workflow:

Fig. 3. The “Lunchtime” workflow


The steps of the workflow are described below.

a) Registration

The task of the user collecting the orders is to fill in the form and register the instance.

Fig. 4. The form on the “Registration” step.


The form consists of the following sections:

  • System data – the system section is automatically filled in based on the current date and user
  • Food supplier – the section in which the user indicates the place in the “Name” field where the meals will be ordered. Other fields are automatically filled in according to the dictionary (thanks to the form fields mapping).

Fig. 5. The mapping of the form fields


The GUID is saved to the technical field which allows for narrowing down the menu to the selected supplier.

  • Order’s data – the section where the user in the “Places of Delivery” field indicates one of the places of delivery registered in the dictionary. With each place the group of users is related, saved in the technical field. Thank this, the e-mail notifications are sent only to the potentially interested people. A user has the ability of entering additional information in the “Additional order information” field and to complete the “Order deadline” field.

b) Food choices and Final call

These steps have identical mechanics of action and the reason for their separation is to inform employees about the approaching end of collecting the orders. This is done by changing the step by the order collector which additionally results in sending the e-mail notification.

Fig. 6. The form with the user privileges on the “Food Choices” step.


In the “Food Suppliers” section, a new “Current Order Value” field and “Today’s Order” will appear. The ordering person sees only one “Add Order/Save” path and has the ability of editing/deleting the order and adding a new one. In addition, there is no option to edit the “Paid up” column indicating payment of the order.

Fig. 7. The form with the user privileges on the “Food Choices” field.


The person collecting the orders has the ability of editing any rows and moving to the next step and canceling the instance. Restriction of editing the individual rows is the result of using the combination, technical column, default values and acceptance mechanics in the item list configuration.

The “Today’s Order” item list has a hidden “T: Row Edition” technical column on which the ordering person and collecting person is entered.

Fig. 8. The fragment of the “Today’s Order” item list in the administration view


In the “Food Choices” and “Final call” steps configuration, in the “Forms” tab the configuration of process settings for this item list has been broken.

Fig. 9. The “Forms” tab on the “Food Choices” step


Clicking on the tools icon (marked above) opens the setting of the item list at a given step. Inside, there is the ability of indicating the users who have the privileges to edit a given row. For the process being configured, this will be a dynamic setting based on the “T: Row Edition” technical column.

Fig. 10. The “Acceptance” tab


The “Today’s Order” item list consists of the following columns:

  • Ordered – this column is automatically completed with the login if the ordering person
  • Menu Item – the choice field from the “Menu Item” dictionary narrowed down to the selected supplier based on the GUID

Fig. 11. The data source configuration


  • Comment – the optional comment
  • Details – additional information about the element taken from the “Menu Items” dictionary
  • Price – the price of the element taken from the “Menu Items” list
  • Number – the number of elements which the user wants to order
  • Value – the automatically calculated product of “Price” and “Number” columns. The sum of values is copied to the “Current Order Value” field.
  • For the Customer – information that the meal is being placed for the client
  • Paid Up – information about paying the order. This field can only be edited by the ordering person

Fig. 12. The configuration of the “Paid Up” column


The last value is the change in the font color of the “Current Order Value” field depending on their value relative to the “Minimum Order Value” field.

Fig. 13. The “Color: Current Order Value” business rule


c) Ordering

After the user collecting orders decides to finish this stage, following the “Final call” and “Finish Collecting Orders” paths they will be in the “Ordering” step.

Fig. 14. The fragment of the form at the “Ordering” step


Their task is to place an order (outside the WEBCON BPS system) with the supplier. Next, they should complete the information about order time and proceed to the next step. The user does not lose the ability to mark which orders have been paid.

d) Awaiting delivery

At this step the user is waiting for delivery and after it arrives, proceed to the next step – this sends an e-mail to the users who have placed orders.

e) Are all orders paid up?

The workflow control step depends on the payment of all orders. If in the “Paid Up” column on the item list all fields have been checked - the instance goes to the positive “Finalized” final step. Otherwise, to the additional “Delivered” step.

Fig. 15. The workflow control in the “Are all orders paid up? step.


f) Delivered

A step where the user collects meals for people who have ordered and have not yet paid the fee. Then, they move the instance to the positive final step.

g) Finalized

The positive final step without further editing.

h) Canceled

The negative step with canceled orders. The following users are informed about entering this step via e-mail notification:

  • All potential ordering person – if the instance was canceled at the “Food Choices” or “Final call” step
  • Only the person who placed an order – if the instance was canceled at the “Ordering” or “Awaiting Delivery” step

Dictionary processes

The application consists of three dictionary processes. First is “Places of Delivery”. The dictionary items can be created from the main page level or from the dictionary dashboard.

Fig. 16. Example value in the “Places of Delivery” dictionary


To register the dictionary, fill in the form and go through the “Save” path. The following fields are available:

  • Name – a delivery name (required field)
  • Description – an additional description (optional field)
  • Recipients – people, who will receive the e-mail notification of the created “Lunchtime” application and will be able to add the order to the list
  • Active – field decides whether the dictionary value is selectable

The second “Food Suppliers” dictionary stores information about the suppliers and starting a new instance is similar to the one described in the dictionary above.

Fig. 17. Example value in the “Food Suppliers” dictionary


In this dictionary the following fields are available:

  • Name – a supplier name (required field)
  • Webpage – a hyperlink field consisting of two parts: name displayed and URL address
  • Phone number – a supplier’s number
  • Address – a supplier’s address
  • Additional information – additional information about the supplier
  • Minimum Order Value – a minimum order value for a given supplier
  • Active – a field informs whether the dictionary values are selectable
  • Menu Items – a SQL data table showing related items in the “Menu Items” dictionary

The “Food Supplier” allows you to also create a new instance in the “Menu Items” dictionary by using the button on the upper bar – this is a global hyperlink action.

Fig. 18. The configuration of the “Add menu item” button


The only parameter passed is the GUID which is saved in the technical field.

Fig. 19. The configuration of the hyperlink using to start an instance


This configuration allows you to export multilevel dictionaries between different environments.

The last dictionary is “Menu Items” – it contains the elements from the specified suppliers menu, so creating a new one is possible only from its level.

Fig. 20. Example value in the “Menu Items” dictionary


The following fields are available:

  • Food Supplier – a SQL row with the name and link to the supplier’s dictionary, it is displayed based on the GUID number
  • Name – a name of the instance (required field)
  • Description – an additional description (optional field)
  • Price – a value of one instance/element
  • Active – a field informing whether the dictionary value is selectable
  • T: Parent GUID – a technical field visible only in the administration mode, it contains the GUID of the related supplier

The last thing is to provide the dictionaries as a data source. When you create a dictionary process, the source related to it is automatically created.

Fig. 21. The Dictionaries source type


Linking is ensured by creating the “BPS internal view” source.

Fig. 22. The configuration of the “Food Supplier” data row in the “Menu Items” process


In the process configuration the column with the supplier GUID is required – a column calculated on the BPS source was used. It has been configured as follows:

Fig. 23. The configuration of the calculated column with the supplier GUID



Examples of privilege configuration were described in the following articles:

Because each company has unique groups with different names, contents and business entities, there is no possible to directly indicate the universal configuration. Instead, use the following tips.

Fig. 24. The configuration of privileges on the application level


It is worth giving the group containing all employees “Read-only” privileges at the application level, which allow for trouble-free access to the Portal.

Fig. 25. The configuration of the privileges at the “Lunchtime” process level


In the “Launch new workflow instances” at the “Lunchtime” level there is a group whose members will collect the orders.

Fig. 26. The configuration of privileges at the dictionary processes level


The privileges at the dictionary process levels (for each of them independently) should be more different:

  • Access and edit all workflow – indicate the group which can edit the delivery places and positions in the menu. This will be the group with people collecting the orders
  • Access all workflow instances and attachments – the group having the privileges to read any dictionary instance.
  • Launch new workflow instances – the group that can create new values in the dictionaries. This will be the group with people collecting the orders, similarly to the “Access and edit all workflow” privilege.


Applications created in WEBCON BPS can facilitate the functioning of the company in many ways. They do not have to be related only to the organization’s business activities such as contract processing or invoice settlement. They are also great to support the internal activities in the company, even in ordering meals for the employees and also for clients who came for training.

Leave a Reply

Your email address will not be published. Required fields are marked *