Design the Approval Workflow
By the end of this lesson, you'll be able to:
- Design a Leave_Request__c object and its key fields
- Identify the core business rule this feature must enforce
- Recognize why "no overlapping leave requests" is a harder problem than Module 26's rollup
Prerequisites: Module 26: "Project: CRM Extension"
What we're building
Leave_Request__c
- Employee_Name__c (Text)
- Start_Date__c (Date)
- End_Date__c (Date)
- Status__c (Picklist: Pending, Approved, Rejected)The core requirement: an employee can never have two leave requests — new or existing — whose date ranges overlap. Simple to state, but genuinely harder to enforce correctly and bulk-safely than Module 26's revenue rollup.
Why this is a harder bulk-safety problem
Module 26's rollup only needed to compare each changed Opportunity against its own prior state (Trigger.oldMap). This feature needs to compare each new Leave_Request__c against every other request for the same employee — both other records in the same bulk insert, and records already saved in the database. Both comparisons need to happen without a query inside a loop.
What "overlap" actually means
Two date ranges [startA, endA] and [startB, endB] overlap exactly when startA <= endB AND startB <= endA — this is the standard interval-overlap check, worth stating precisely now so later lessons can implement it directly rather than reasoning it out mid-code.
Exercise
As a comment, apply the overlap formula to decide whether a request for Jan 10-15 overlaps with an existing approved request for Jan 14-20.
Show hint
startA <= endB AND startB <= endA
Design the Approval Workflow Quiz
My Notes
Log in to keep private notes on this lesson.
Questions about this lesson
No questions yet — be the first to ask.
Log in to ask a question about this lesson.
Summary
This module builds a leave-request system enforcing one genuinely tricky rule: an employee can never have two leave requests with overlapping dates — a harder bulk-safety problem than a simple field rollup.