Help finishing a simple Leave Request app (Employee/Manager): approve/reject flow, XPath filters & security

Hi everyone,

I’m building a small Leave Request app in Mendix Studio Pro 11.x and I’d love a sanity check / best-practice advice for the last pieces.

What I have so far

• Domain model: LeaveRequest with StartDate (DateTime), EndDate (DateTime), Justification (String), Status (Enumeration: Requested, Approved, Rejected).System members enabled: owner, createdDate, changedDate.

• Roles: Employee, Manager, Admin.

• Employee overview: a Data Grid showing only the current user’s requests.XPath: [System.owner = '[%CurrentUser%]']

• Create form: a modal popup with a Data View over LeaveRequest.Fields: StartDate, EndDate, Justification.Status has default value Requested.Buttons: Save (commit) / Cancel.

• Manager overview: a Data Grid showing only items with Status = 'Requested'.XPath: [Status = 'Requested']I can also show the owner’s name via System.owner/Name.

What I want help with

1. Approve / Reject patternFor each row in the Manager grid I want two actions: Approve (set Status = Approved) and Reject (set Status = Rejected).Is the recommended approach to use a Nanoflow per action with: Change object → Commit (Refresh in client = Yes)?Or is there a better micro/nanoflow pattern you use in production (e.g., confirm dialog, validation, rollback patterns)?

2. Popup vs full page for editingFor creating a new request I’m using a modal popup. Is that fine for web apps, or would you recommend a normal page (for accessibility, navigation, etc.)?

3. Security / access rules

   • Employee: may create and edit their own requests while Status = Requested, and read only once it’s Approved/Rejected.

   • Manager: can read all, and only change the Status.Do you have a concise set of Access Rules on the LeaveRequest entity that you usually apply to achieve this? (Owner-only constraints + attribute-level rights for Status?)

4. Best way to show the requester nameI’m currently using System.owner/Name in the grid for the Manager. Is that the typical approach, or would you model a dedicated association to Account and display from there?

5. Refresh behaviorAfter Approve/Reject I want the Manager grid to update immediately (so the row disappears if I filter to Requested). Is Commit → Refresh in client = Yes on the nanoflow enough, or do you recommend an explicit datasource refresh?

If it helps, I can share screenshots of the overview grids and the popup.Thanks a lot for any pointers or examples!

Version: Mendix Studio Pro 11.xModules used: Standard System / Atlas