Abstract

This article will guide you through the process of implementing an approval app with Simplifier.

Based on an example app, we will present a step-by-step procedure which can be generalized and adapted to any other approval process.

Step 1 – Specify Process Workflow

Specify your approval process using (pseudo) workflow notification:

Step 2 – Use Simplifier Features

In general, the approval app is built on four stacks:

1. User Interface: How should the user interface of the app should look like? Which actions should be possible? What are the user stories?
2. Process Logic: What is the process logic? How does the workflow look like?
3. Data: Which data is required for implementing the workflow? Are there connections to other data systems?
4. User: Who will use the app? Which user groups have to be considered?

Each of those four stacks is represented in Simplifier by a corresponding feature:

1. UI Designer: The UI can be built in a “no-code” way using predefined widget groups, and a WYSIWYG live preview.
2. Process Designer: Business logic is modelled using drag-and-drop components which implements the user stories.
3. Database Designer: Database schemes can be visualized and managed without a line of code.
4. User Management: The build-in user management allows secure role and group assignments.

Accordingly, it is no problem to derive a ready-to-use specification from the workflow from Step 1, so that the team can easily start implementing the approval app.

In the following, we will go through this process of realizing an approval workflow with Simplifier based on the example app (see Abstract).

Nevertheless, this procedure of mapping an approval workflow to the Simplifier components is applicable to any other process.

Step 3 – Create Request

To start with, think about which information is required to start the approval process (e.g., in case you want to pass through the information to another system like the ERP system, which input data would be necessary). Based on this consideration you can start building the UI and data components using the database designer and connectors:

1. User Interface: design your request form for creating a request using the widget groups and the WYSIWYG in the Simplifier UI Designer.
2. Database Designer: use the database designer to manage business and process data.
3. Business Logic: build connector calls for CRUD operations and use them in the stories.

3.1.User Interface

You can use Simple Form widget (group) for the request form:

3.2. Database Designer:

Depending on your set up, your business and process data can be hold in one single database table (like in our running example), or you have several database tables which are related using foreign keys. In addition, you can also add a changelog database table which tracks the process history.

3.3. Business Logic:

The CRUD (Create-Read-Update-Delete) operations are implemented as Connector calls using SQL statements:

The Connector calls can be used in Process Designer by adding drag-and-drop shapes to the map. The Business Logic is modelled by connecting the story elements in the correct order.

Step 4 – Inform Responsible Person

Next, think about who should be informed about this new request (e.g., the manager). Based on this consideration you can specify business roles, and develop further your business logic:

1. User Management: specify groups in the Simplifier User Management to model the business roles for your use case.
2. Business Logic: prepare email templates and define Conditions in the Stories for sending those emails to corresponding person.

4.1.User Management:

You can define User Groups (like ‘SF_Approval_App_Manager’) and assign users. This makes it easy to handle different features for different business roles within the app (e.g., manager, sales, etc.).

4.2. Business Logic:

Email templates can easily created using HTML-format. In addition, you can use mustache notation for including variable holders (e.g., for salutation, etc.), which are filled at runtime.

For implementing logic formulas of the process workflow (if X then Y else Z), you can simply add logic elements in the Process Designer. Condition elements can then be configured using variable values from the data workbench, input values from the UI, auto fields, or explicity entered constant values.

Step 5 – Check Request

As next step, you should think about what the responsible person does with the request (e.g., the manager approve/reject the request, or in case of a multi-step approval process he forwards it, and adds or edits information, if necessary). Based on this consideration you can develop further your UI and business logic:

1. User Interface: design a clear list view with filter and search functionality which allows the user to have its requests, their status, and required actions at a glance.
2. Business Logic: configure further Conditions and connect them with corresponding CRUD operations in the stories.

5.1.User Interface:

You can use:

• a table for listing all requests
• search field(s) and/or multi-combo boxe(s) for filter and search functionalities, and
• buttons for user actions

5.2. Business Logic:

Step 6 – Process Decision

Finally, you should think about what are the consequences of the decision (e.g., emails have to be sent to inform the person involved). Based on this consideration you can finalize your business logic and user management:

1. Business Logic: add email templates and define further Conditions in the stories to send email messages.
2. User Management: use the group assignments of the Simplifier User Management to identify person involved.

Summary:

As you have seen, it is no problem to digitalize your approval process with a Simplifier App.

The presented procedure – starting with a workflow notation, using Simplifier Features, and develop the app step-by-step – can easily be adapted for any other approval process.

With this general approach, you can even cover quite customized processes, which normally is not feasible with out-of-the-box business process modelling tools.