Project — Leave Request System | Development Standards

WeWeb + Xano ~8 Hours Intermediate

What You Are Building

Build a leave request workflow where members can submit leave requests and admins/owners can approve or reject them.

This project teaches

Xano status workflow
Multi-step form in WeWeb
Approval flow
Role-based views
Date validation

Flow Design

Status Workflow

stateDiagram-v2
    [*] --> Draft
    Draft --> Submitted
    Submitted --> Approved
    Submitted --> Rejected
    Submitted --> Cancelled
    Approved --> Cancelled

Flow Design

Example Flow

flowchart TD
    Login[User logs in]
    Workspace[Selects workspace]
    LeaveArea[Opens Leave Request System]

    Login --> Workspace --> LeaveArea

    LeaveArea --> Member[Member Flow]
    LeaveArea --> Admin[Admin Flow]
    LeaveArea --> Owner[Owner Flow]

    Member --> MemberList[View own leave requests]
    MemberList --> MemberSearch[Search / filter / paginate own requests]
    MemberSearch --> MemberCreate[Create new leave request]
    MemberCreate --> MemberReview[Review dates and reason]
    MemberReview --> MemberSubmit[Submit request]
    MemberSubmit --> MemberTrack[Track status updates]
    MemberTrack -. cannot approve own request .-> MemberBlocked[Approval actions blocked]

    Admin --> AdminQueue[View workspace leave requests]
    AdminQueue --> AdminFilter[Search / filter / paginate by employee, status, date]
    AdminFilter --> AdminView[Open request detail]
    AdminView --> AdminDecision[Approve or reject with reason]
    AdminDecision -. cannot access other workspaces .-> AdminBlocked[Blocked by workspace permission rules]

    Owner --> OwnerOverview[View leave activity across owned workspaces]
    OwnerOverview --> OwnerFilter[Filter by workspace, employee, status, date]
    OwnerFilter --> OwnerView[Open request detail]
    OwnerView --> OwnerManage[Approve, reject, or audit workflow]

Required Screens

Member Leave Page

Should show:

My leave requests with request date, leave type, date range, duration, and status badge.
Search by leave type or reason.
Filters for status and date range.
Pagination if the member has many requests.
View button to open the full request summary.
Create new request button.
Cancel action only when workflow rules allow it.
Loading, empty, no-result, and error states.

Leave Request Form

Multi-step example:

Select leave type.
Select dates.
Add reason.
Review and submit.

Show validation at each step and do not allow invalid forward movement.
Calculated leave duration should be visible before submit.
Review step should clearly show what will be submitted.

Leave Request Detail View

Should show:

Full request summary with type, dates, total duration, reason, and current status.
Status timeline so the member can see whether it is draft, submitted, approved, rejected, or cancelled.
Admin decision details such as rejection reason where applicable.
Back button to the member list page.

Admin Approval Page

Should show:

Pending and processed requests with employee name, leave type, date range, and status.
Search by employee name.
Filters for status, leave type, and date range.
Pagination for larger teams.
View button to inspect the full request before decision.
Approve button and reject button.
Rejection reason field or modal required before reject completes.

Date Validation Rules

Start date is required.
End date is required.
End date cannot be before start date.
Start date cannot be earlier than today in the base project.
Overlapping leave requests for the same user must be blocked for draft, submitted, or approved requests that overlap the selected dates.
Leave duration should be calculated server-side.

Permission Rules

Actor	Allowed
Owner	View and manage all leave requests in owned workspaces.
Admin	Approve/reject requests in assigned workspace.
Member	Create and view own requests.
Non-member	No access.

Acceptance Checklist

Member can submit leave request.
Member cannot approve own request.
Admin can approve only workspace requests.
Admin cannot see requests from other workspaces.
Date validation works on frontend and backend.
Status transitions are controlled by backend.
Rejection requires a reason.
Loading, empty, and error states are implemented.