A new way to design business process for everyone. It is simple to learn and excel yet powerful to cover complex scenarios. Best of all, Inistate converts this design into ready-to-use software and mobile apps instantly and automatically.

A business process is a collection of repetitive and predefined steps to be performed by various individuals or teams span across hours, days even months.

In an organization or business, these are typical tasks or operations that you managing or looking after day-to-day. With a proper design and optimization of these processes, anyone can scale and grow the business with ease.

Now, let's imagine we are designing a simple Leave Application process.

1. Start with first Activity

Let's design our first Activity. It is an action which a person can perform in a business process. For example, a person may contact a lead or quote a potential customer. A department manager may approve or reject a leave application.

Here, a process always starts with create, a standard activity.

2. Next with State

A State informs everyone of the current status and who should be doing something on particular entry (request) in a business process.

It is around us in our daily life. For example, your flight is departed, landed, or canceled. Your leave application is approved or rejected.

We now create the initial state, which is the key step of designing a business process. It is also the reason we are named Inistate. The inistate state is Draft because a requestor can draft their leave before applying. And, create points to our first state, Draft. It means that when a requestor creates an entry (request), the entry's state will be Draft.

3. Then, add in Information

Information is the data gathered or generated in an entry (request) from a business process. Like a spreadsheet, we can keep data like texts, numbers, dates, images, files, links to other entries, formulas, or even tables for a business process.

For now, these are examples of Information we need for our leave application:

• Employee for the employee name who makes the requests
• Leave Type for type of leave applied for example Annual Leave, Medical Leave or Unpaid Leave.
• Start Date for leave start date
• End Date for leave end date
• Reject Reason for reason for rejection

We can always add in more information as we go along.

4. Adding Information to Activity as Form

A Form is for inserting new or updating existing values into Information when a person performing for particular Activity. A Form is optional for Activity and not all the Information has to added.

Next, we select Information for the create. We excludes Reject Reason as it is not required when submitting leave request. With this, a person who perform create will fill up this Form.

5. Repeat the same process

Now, just repeat the same process. Adding more State and Activity and optionally Form.

User may submit their application for approval if entry's state is Draft. We add a new activity, Submit and it leads to newly created state, Pending Approval. There is no additional information required for Submit. Hence, user can perform Submit without a form and then entry's state will change to Pending Approval

From Pending Approval, manager can Approve this request and the state will be changed to Approved.

Also, from Pending Approval, manager can Reject this request. However, manager are required to enter Reject Reason when performing Reject.

Once Reject activity is done, the state of the request will change to Rejected

Lastly, requester will have the chance to Revise his request if it is Rejected. An activity Revise will start from Rejected and point to Draft

The cycle repeats.

6. Completing Flows

We just completed a leave application design. We can always add more Information, Activity, or State as we scale up our business process. Anyway, this design is all it takes for Inistate to take over and present you with software and apps that users can instantly use. You may register Inistate now to build your own or extend this leave application process and experience the magical moment of your design coming into life.

Note that we can also define roles' permissions or users' ability to perform certain activities. For example, only the requesters can submit their requests, whereas only managers can approve or reject submissions. Besides permissions, we will explore more topics like Notification, Automation, and Integrations in next episode.