Best Practice for Application Forms

I currently have a process called “leave application”, it has an entry form, and a RG of the leave applications.
In the database, it’s actually saved in 2 parts:

  1. LeaveApplication (with the generic data of starting/ending date & time, leave type… etc.)
  2. ApprovalProcess (with user as an approver, approval status… etc.)
    ApprovalProcess is saved as an attribute in the correspondent LeaveApplication, and vice versa.

I find it extremely hard to filter in the RG even with ListShifter, I’ve tried setting the RG up with either LeaveApplication or ApprovalProcess as the main RG type, and when I try to sort with the sub/related data type’s attribute, the filtering never works perfectly.

For Example:
Using ApprovalProcess as the main RG type, and filter with LeaveType (attribute of LeaveApplication from an option set), some options behaves properly, and the others don’t (tried both “ignore empty constraints” on & off).

Anyways, my real question is:
What’s the best practice to manage the data of an approval process?
A) 2 linked/related data types like mine - Approval Proces vs. Leave Application
B) 1 data type - Leave Application that has approver & approval status fields

(I feel like A is still better becuase then if I decide to change approval process logic in the future it’s easier to manage.)
Any idea is welcomed!

Screenshots for reference:

What’s the best practice to manage the data of an approval process?

There really is no concrete best practice - these types of questions can be somewhat subjective and can often come down to personal preference - there are generally pros and cons to both, and its really about just making sure that the setup you have is scalable and works for your purposes.

In this specific situation, my personal preference would be a single data type. I think the fact that you are having to use list shifter to manage this type of feature is generally a good sign that your data structure is a bit overly complex.

I feel like A is still better because then if I decide to change approval process logic in the future it’s easier to manage.

In response to the above comment - I would argue that an approval process by nature can only get so complex, and therefore only have so many fields associated with it. The complexity of having to update two different data types to accommodate changes in logic vs. having to add / remove fields and update some data on a single data type in my mind is relatively equivalent. Personally, I find the latter solution easier on all fronts.

I hope this helps! Again, this is just my opinion - I don’t think there is a concrete “best practice” here.


I have a similar setup for my ERP’s approval processes, where an approval data type is linked to another data type for tracking approvals, and a filter setup like yours works with no issues.

I see that you have Search for Leave Application with the :random item operator as part of your constraints. Is there a particular reason you used that?

You should instead put that Leave Application Type constraint in an advanced filter operator since you are referring to a different data type from Approval.

Anyway my best practice is to always have the data types each contain a field that refer to each other. So Approval will have a field for Leave and vice versa.

Then I add fields to each data type that I expect to be used as a constraint. So Leave will contain the field “Approval Status” which you keep in sync with the “Approval Status” in Approval.

This makes setting up for filtering easier and reduces the pitfalls of slowdown from complex advanced filters.

I do use other methods (such as having elements using text to search different data types using Unique IDs) to sort and filter for some of my complex lists consisting of multiple data types but best practice is to keep things simple. Hence if you should try to anticipate how you want to filter and sort a data type and add appropriate fields so you don’t need to rely on advanced filters often.

PS: Since you use the ever omnipotent List Shifter, you should read up more, and watch @keith videos, on it. You’ll be surprised at the things it can do!

Hi, @ihsanzainal84
Yes, the two data types are linked by having each other as an attribute.
I don’t know how to bring up “all items that meets criteria” if not using “:random”, any suggestions on this?

Hi, @sam.morgan
Understood, thanks for the input.